cc @TheDJ and @Tbayer for current line in thinking...

Sounds related to what I was suggesting at: T124168#1952372

This kind of functionality can be supported quite efficiently with a matcher like https://github.com/wikimedia/elematch. Processing (replacing or matching) specific elements by attribute in [[Barack Obama]] takes only about 2ms. The main requirements for this is content in valid HTML5 or XML, serialized according to the respective specs.

The issue brought up by @MZMcBride in T124168#2295956 is definitely something we'll need to consider when using user-controlled identifiers for major skin changes. At the very least, we'd need to set very clear expectations around how those specific classes would be used. Namespacing them with a prefix like mwc-* & setting up a policy for that namespace could help set the right expectations, and avoid unintended sharing as illustrated in @MZMcBride's example.

In some ways, targeting the expansions of specific templates like navboxes would be easier and less likely to lead to conflicts. However, it is also less flexible than classes, and basically requires using Parsoid content.

@Jdlrobson wrote

On HTML heavy elements this can improve first paint and fully loaded time.

It will probably reduce fully loaded time. However please understand that is unrelated to first paint time. These boxes tend to be toward the bottom of the payload, and all our skins output article content high up in the HTML stream (before the sidebar and skin header). Browsers are very good at parsing and rendering HTML progressively as it comes in. As such, first paint is unlikely to be affected in any meaningful way (if at all) by this change.

While bandwidth savings are worth pursuing, impact on UX and JavaScript complexity are important too. As well as how it affects the ability for search engines to index content in the proper context. Removing navigational content from the page could have a negative impact that should not to be underestimated.

It may also make sense to re-implement these templates in a more lightweight way in the first place. They don't need to be as heavy as they are. Coordinating with community directly (or via community tech) would be worthwhile imho.

I do agree that these navigational elements shouldn't be stored as part of the wikitext blob. Just like how categories and other meta data would be better stored as actual metadata. Making infoboxes and navigation boxes become native component via a MediaWiki extension would allow these to be more efficiently stored, made easier to edit, and served to users in a more performant way. And we can incrementally improve these extensions for all wikis at once.

However, I don't think lazy-loading is an appropriate solution for this. Similar to the problems with lazy-loading references lists (see T125329 for details), this significantly complicates backend storage and caching of HTML and makings our overall front-end quite fragile in my opinion.

Html is prioritised over css in many situations e.g. spdy so this does impact first paint on a slower connection and consistent with what we are seeing in EventLogging but yes the main benefit is reducing fully loaded time and bytes saved.

In T132560#2313552, @Jdlrobson wrote:

Html is prioritised over css in many situations e.g. SPDY so this does impact first paint on a slower connection

Yep. That's an important issue with larger articles and one of the few remaining regressions we identified after enabling SPDY (and later HTTP2).

See T125208, T124966. The main issue there is Nginx's seemingly primitive handling of HTTP2 stream priorities. Various things are being done about that:

• Figuring out how we can improve the priority handling to be more balanced in sharing the bandwidth between streams (E.g. instead of focussing 100% on HTML, and then focussing on CSS; send in parallel with only a more nuanced preference for HTML).
• And/or use HTTP2 server-push for the CSS.
• Inlining critical css within the HTML stream and deferring the rest.

Either way, this is imho not a bug that justifies trimming down HTML.

Making parts of the content lazy loaded wouldn't affect negatively the people who can't or who doesn't want to navigate with JavaScript enabled? What kind of fallback would have the lazy loaded elements in this context?

If I recall correctly at this moment even if editors decided to hide part of the content collapsing them if I see the page with JavaScript disabled the contents that with JavaScript enabled are collapsed by default can be read without problems.

For these people there would be suitable fallbacks. Their experience for reading would be improved as they would be downloading less data.

The existing collapsing results in a flash of unstyled content and loads content that the reader may never see.

I'm all for proper meta data as an alternative solution!