Page MenuHomePhabricator

[Epic] Determine the optimum Vector DOM structure for a11y and performance
Open, HighPublicSpike

Description

Problem statement

In order to accommodate all users (GUI+pointer users, keyboard users, assistive technology users, non-JS users and related search robots) the Vector theme should provide a performant, interaction-mode independent and accessible DOM structure.

Current DOM structure (Vector)

  1. MW Head Base & Page Base (not sure what possible contents are there in our projects) div#mw-page-base & div#mw-head-base
  2. div#content.mw-body[role=main] Content
    1. a#top – any other way around this?
    2. div#siteNotice > div#centralNotice, SiteNotice & CentralNotice
    3. div.mw-indicators, MW indicators – problematic that high up in DOM, should be underneath title aka firstHeading
  3. h1#firstHeading, first heading
  4. div#bodyContent.mw-body-content, Body content
    1. div#siteSub, “From Wikipedia, the free encyclopedia”
    2. div#contentSub, example “Redirect page”
    3. div#jump-to-nav empty currently
    4. a.mw-jump-link -> #mw-head
    5. a.mw-jump-link -> #p-search
    6. div#mw-content-text, Content & parser output
    7. div.printfooter

Order of elements on page should accommodate users of assistive technology as well as visual users. The importance of DOM elements would be represented in following sequence:

  1. site logo/branding for identification
  2. content
  3. navigation

and provide skip-links to content, navigation and possibly search.

Collection

.mw-indicators#contentSub

Related Objects

StatusSubtypeAssignedTask
ResolvedGoalovasileva
OpenNone
Resolvedovasileva
ResolvedSpikeovasileva
ResolvedSpikephuedx
Resolvedovasileva
OpenSpikeNone
OpenSpikeNone
OpenBUG REPORTNone
ResolvedVolker_E
Resolvedovasileva
Resolvedsgrabarczuk
ResolvedBUG REPORTovasileva
OpenNone
OpenBUG REPORTBkudiess-msft
Resolvedovasileva
OpenDemian
ResolvedJdrewniak
OpenSpikeJdrewniak
Resolvednray
OpenNone
ResolvedSpikeovasileva
Resolvedovasileva
ResolvedBUG REPORTmatmarex
Resolvedovasileva
ResolvedJdlrobson
Resolvedphuedx
Resolvednray
ResolvedMayakp.wiki
ResolvedMayakp.wiki
Stalledovasileva
OpenNone
ResolvedEdtadros
OpenNone
OpenNone

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

I think @TheDJ's summary of Vector/Monobook's design goals with respect to DOM order is excellent. It's a content-first page structure, which has it's benefits, and has arguably stood the test of time. The task here is to re-evaluate that structure and see if it can't be improved on, or if some of those underlying assumptions have changed.

Performance-wise, the characteristics of the content-first layout are interesting, because on one hand yes -- the most valuable thing on the page, content -- is loaded first. On the other hand, the actual load times suffer because the browser has to wait for the entire content to load before rendering the header/sidebar/logo. This negatively impacts certain performance metrics like "First Meaningful Paint" or "Visual complete time", which primary measure when the above-the-fold page content stops changing. Currently, it stops changing when the navigation, some of the last HTML on the page, gets loaded.

Based on T231168 (Fit above-the-fold layout and first paragraph HTML in 14 KB) It seems like from a performance perspective, it would be desirable to have the header, which includes the logo, search & personal menu, be placed before the content so that the page rendering more closely matches it's visual appearance.

That being said, loading the content first has it's benefits. Mainly, it allows people to get to the content of the page much faster. However, it can be argued that this DOM structure is very unique, and such, it might be more confusing than helpful for screen-reader users. At least, that's what the WebAIM article mentioned above implies:

Some developers place the main content first in the reading order and the navigation last - generally using CSS to maintain the navigation first in the page visually. This method makes "skip navigation" links unnecessary, but it raises another question. Should such sites provide "skip to navigation" links? This is a tricky question. Links taking users to the navigation are unexpected, and can lead to some confusion.

This approach also causes a reading and navigation order that is very atypical - and that can be very confusing, particularly for sighted users who are visually tracking the navigation focus that seemingly jumps around the page rather than starting at the beginning.
Verdict: The concept can be useful, but users can become disoriented with an atypical reading and navigation order.

ARIA landmarks
These attributes are much more useful than skip-links for accessibility, so I did a quick look through the source of a Random article on enwiki to see how they're being applied currently. This is what I found:

  • ⚠️ banner - Currently role="banner” is only applied to the logo. If we redesign the header, it should be applied to the entire "header" element. The current “header” (personal navigation) is labeled as a navigation element.
  • contentinfo - role="contentinfo” Is correctly applied to the footer element.
  • main - role="main” is applied to the article content
  • navigation - role="navigation” - Is being applied to every navigational section in the sidebar and header. Each navigation section like "Tools" or "Interaction" is labelled accordingly.
  • search - role="search” - is applied to the <div> container around the search form.

@Volker_E I heard you mention screen-reader users having issuing navigating the... navigation. Could you expand on that? Is that due to the sheer number of links?

MBinder_WMF changed the subtype of this task from "Task" to "Spike".Mar 3 2020, 6:13 PM
TheDJ added a comment.EditedMar 4 2020, 1:19 PM

"These attributes are much more useful than skip-links for accessibility,"

I'm not sure if it is still the case, but many screenreader users still don't actually use landmark navigation. Mostly because on many websites, it's a complete, unusable mess. Most people at least until a couple years back used the ToC and 'familiarity/consistency' with the site to get around, together with skip links if available. The landmarks they used more to 'enrich' their own contextual concept of their position on the site (aka its more useful to know you are inside the navigation section). Additionally, landmarks help screenreader users, but if you don't need a screenreader, but do use keyboardnavigation (because you can't use a mouse), then skip links are still highly useful for your.

I know Graham, basically punches in a set of key combos that he knows will land him on the lead of almost any wiki article. I doubt he even thinks about 'navigation' :)

I think the problem with navigating our navigation landmark use was primarily with the fact that we blotted our navigational sections all around the page, sometimes without a (clear) label. For instance these are the landmarks I see on Voiceover for one of our pages. 11 navigation sections to navigate to.. what does 'more' apply to ?

Ps. that screenshot is from the 'rotor'. Which in VO is ctrl-alt-U. arrow-left and arrow-right will then allow you to quickly choose between navigating using: landmarks, links, ToC/headings, forms actions, tables and webspots (self defined hotlinks). All these also have key combo accessors to do next/prev heading/table/link etc without even opening the rotor

TheDJ added a comment.EditedMar 4 2020, 1:50 PM

I think @TheDJ's summary of Vector/Monobook's design goals with respect to DOM order is excellent. It's a content-first page structure, which has it's benefits, and has arguably stood the test of time. The task here is to re-evaluate that structure and see if it can't be improved on, or if some of those underlying assumptions have changed.

Just to note. I'm only mentioning these points to make people aware of the historical context of some of this. What should be used now is up to those working on it, but I care to provide people with the relevant context to make sure we don't go with current standards/advice just because some website or metric says it is better, but because with careful evaluation from multiple perspectives, we make validated choices for our very complex website and complex audience.

This thing (vector/monobook, itself derived from the skin in plone) is from a time, when some users still disabled CSS because their connection was too slow.. But it was deliberately designed with that in mind, not tossed together because no one knew any better.

Oh and some of the original design discussions still exist: https://meta.wikimedia.org/wiki/Layout_design_document
And here is the design contest for thumbnails: https://meta.wikimedia.org/wiki/Thumbnailed_images ah so sweet and innocent those days...

Demian added a comment.Mar 4 2020, 6:17 PM

Just to note. I'm only mentioning these points to make people aware of the historical context of some of this.

Thank you for this information, I'm very much interested in it.

Volker_E updated the task description. (Show Details)Mar 9 2020, 7:52 PM

@Volker_E Thank you for the "Current DOM structure" in the task description.

@TheDJ @Jdrewniak which screen readers do you use for testing?

TheDJ added a comment.EditedMar 14 2020, 10:41 AM

@Demian I primarily use VoiceOver Safari for MacOS and iOS to test, and I know a bit about where and how that differs from JAWS for instance. I also test keyboard (tab) navigation when looking at things like this.

Content sub is used for things like ’redirected from’, parent links on subpages etc. See
https://codesearch.wmflabs.org/core/?q=addSubtitle&i=nope&files=&repos=

This comment was removed by Demian.

Related: https://webaim.org/projects/screenreadersurvey8/ (August - September 2019)
Also ran, unfortunately:

IE1110.9%
IE9-101.5%
IE6-82.1%

Combinations:

Screen Reader & Browser# of Respondents% of Respondents
JAWS with Chrome25921.4%
NVDA with Firefox23719.6%
NVDA with Chrome21818.0%
JAWS with Internet Explorer13911.5%
VoiceOver with Safari1109.1%
JAWS with Firefox715.9%
VoiceOver with Chrome363.0%
NVDA with Internet Explorer141.2%
Other combinations12610.4%

(Was a bit weird having a spike in needs analysis - I think this can either be in todo or doing depending on whether @Volker_E is actually looking at it.

ovasileva renamed this task from [SPIKE] Determine the optimum Vector DOM structure for a11y and performance to [SPIKE 8hrs] Determine the optimum Vector DOM structure for a11y and performance.Mar 18 2020, 5:25 PM
Volker_E updated the task description. (Show Details)Mar 28 2020, 12:41 AM
Volker_E updated the task description. (Show Details)Mar 28 2020, 1:22 AM
Volker_E added a subscriber: alexhollender.

@alexhollender Are there any foreseeable design plans on indicators, like barnstars?

Volker_E added a comment.EditedMar 28 2020, 1:25 AM

It seems reasonable and sensible to move indicators underneath headings, I think that would also be a logical step for screenreader users. I'd be interested to hear, after navigating to a featured article's heading, that it's actually a featured article. For other users there shouldn't be a visible change.

@alexhollender Are there any foreseeable design plans on indicators, like barnstars?

Yes:

...as part of Desktop Improvements we've identified that in order to put the language switcher in the desired location we'd have to move these article indicators below the border:

Per kickoff discussion earlier today, I promised that I would link T246419 to this task.

T246419 briefly explored adding a skip link or accesskey to the sidebar given the new mechanic of the collapse / hide button and the DOM distance from the sidebar's contents. @nray @Volker_E @Jdlrobson, and I decided against it (with a lot of help from @Volker_E especially--thank you!). Here's the minutes as I understand them:

  • Keyboard and accessibility concerns are related but not necessarily overlapping.
  • macOS has a pretty good accessibility wheel for jumping to different parts of the page without skip links. That means the main use case is for keyboard users only.
  • Sidebar is important but its purpose is ambiguous, currently unique to MediaWiki, and may be changing in the scope of Desktop Improvements Project.
  • Adding accesskeys requires broader coordination.

Consensus: abandon now. Change by request or as needed later. /cc @Jdrewniak

With regards to the sidebar, I think that in order to best accommodate the collapsible sidebar, we might have to place the sidebar (and by sidebar I mean all of #mw-panel) inside the header, right next to the hamburger icon, as per mocks in T246419. This is what the Minerva skin does, and it facilitates a css-only collapsible menu that's keyboard accessible.

Demian added a comment.EditedApr 24 2020, 8:33 AM

With regards to the sidebar, I think that in order to best accommodate the collapsible sidebar, we might have to place the sidebar (and by sidebar I mean all of #mw-panel) inside the header, right next to the hamburger icon, as per mocks in T246419. This is what the Minerva skin does, and it facilitates a css-only collapsible menu that's keyboard accessible.

That's not necessary. The Sidebar can be anywhere in the DOM after the header, only the icon has to be right after the checkbox in the focus order to behave as expected.

Sidebar after SearchBox: DEMO of patch 592328 (see index.mustache) based on @Niedzielski's sidebar implementation in T246419.
Also note: the state of the sidebar is saved between page loads.

Although placing the sidebar right after the toggle icon would put the sidebar links right after the sidebar icon in the tab order...

we might have to place the sidebar (and by sidebar I mean all of #mw-panel) inside the header, right next to the hamburger icon

Sidebar right after menu icon: DEMO of patch 592395.
Very good navigation compared to previous demo: after opening the sidebar 1 TAB key already steps into the sidebar (the logo in this case, which will be gone).

Quick update here, with T246420 on the horizon to be merged, we have a tab order behaviour in modern Vector of “menu button > sidebar links (when open) > logo”. I'm not convinced this is the right order. It should probably be menu button > logo > sidebar links.

Demian added a comment.Jul 7 2020, 9:53 PM

The logo as a link is redundant with the "Main Page" sidebar link. Navigates to the main page when clicked is ok, but IMO it should not be part of the TAB sequence at all. Pressing TAB twice will bring you to: -> sidebar button -> "Main Page". That's sufficient.

This comment was removed by HonestCandidate.
nray added a comment.Jul 21 2020, 10:07 PM

Now that the max-width ticket has been resolved (T246420, T257518), I think we should make this ticket a very high priority and do a thorough cost-benefit analysis of Vector's "content-first" DOM order status quo as there were many challenges I encountered during this work (e.g. T257518) that made me question its value, and I think the pitfalls associated with this DOM order will continue to pop up as we progress with the Desktop Improvements Project. Additionally, the further we progress through Desktop Improvements and the more hoops we have to jump through to make this DOM order work, the more costly it will be to change later.

My concerns with this approach:

  • It pretty much forces us to use absolute positioning for the header, sidebar, and article toolbar and take these elements out of the normal document flow which has ironically lead to other accessibility issues/bugs such as the sidebar overlapping the footer (mitigated in T257518 by making the footer width match the content width giving the sidebar its own "lane" of space ) or the sidebar popping out of the page container (still an issue but mitigated by applying a min-height to the page container). Future tasks such as T249363 where the personal menu links wrap at small viewport widths and are supposed to push the content down may face similar challenges with the absolute positioning/DOM order.
  • Closely related, making these elements absolutely positioned offloads a significant burden of work that the browser could be responsible for and places it on the developer/code instead which increases complexity/maintainability costs. For example, we need to calculate the height of the header to determine how to position the sidebar and article toolbar and need to calculate the height of the header plus the height of the article toolbar in order to position the top of the content.

I'm sure there are benefits associated with the DOM order we have as well, but the more I try to research what these benefits are, the more discouraged I become:

  • Accessibility: This is probably the most influential reason given for our DOM order. However, as @Jdrewniak mentioned previously, WebAIM (an organization that is arguably one the worldwide leaders in accessibility) gives a very mixed review of this approach stating:

The concept can be useful, but users can becomes disoriented with an atypical reading and navigation order [1]

It is also worth noting that WebAIM itself does not place their content first in the DOM. Instead, they follow the more conventional approach of header, content, sidebar, footer. Are there any other major websites that order their DOM like we currently do?

  • SEO: This is another reason I've heard for the purported benefits of our DOM order, but I have not been able to find any evidence supporting this claim. A quick google search for "dom order and seo" did not lead me to any satisfactory evidence. On the contrary, it lead me to this thread posted in 2011 with the opinion: I don't think code order matters that much anymore (in relation to SEO) [2]. FWIW, Moz an arguable leader in this space and a site that ranks #1 in Google for the term "SEO", does not place their content first in the DOM. Instead, similar to WebAIM they have: header, content, footer.
  • Performance: It is true that by ordering the content before the header and sidebar users will see the content first and this is the most important element on the page. However, it also has drawbacks because the header and sidebar are "above-the-fold" and their rendering will be last which can also be unexpected for the user/increase the perceived loading time of the page. Furthermore, since the size of the content's HTML is significantly larger than the size of the header/sidebar HTML in the majority of pages, the delay caused by ordering the content before the header/sidebar is most likely much more significant than the delay that would occur by ordering the header/sidebar before the content. It seems that the performance team also shares this hypothesis [3][4].

In summary, I strongly believe we should reevaluate the pros/cons of our current DOM order and its purported value as the costs are concretely high and the benefits are increasingly nebulous to me.

[1] https://webaim.org/techniques/skipnav/#altorders
[2] https://moz.com/community/q/does-code-order-matter
[3] https://phabricator.wikimedia.org/T237636#5699004
[4] https://phabricator.wikimedia.org/T231168

nray added a comment.Jul 21 2020, 10:10 PM

@ovasileva I think this ticket is pretty important for future DIP work (it certainly played a large role in T246420) and IMO should be prioritized. I'm moving to the upcoming column as I did some analysis of it today.

@nray Thanks for this inputs. A few quick thoughts:

  • Accessibility Tagged here to make sure assistive technology users can work with the page (HTML structure) in a logical, way. It's the least important of all three, as we can and have to assure that it works no matter which DOM structure we choose. An advantage of the current structure is, that it is learnt territory, it has been the same way for a long time and has been undisputed by AT users for most parts. Any change for this is a risk where we need to aim to come up with a similar or better experience for our users. That would translate to intensive testing with a group of AT users before/after and possible even A/B between different paths.
  • SEO That's a bit black magic. Content first is and has always been a great way to make sites shine in most search engines ranking algorithms. Does other factors like our popularity might help us with changes – probably!? Do we have the capacity to fully conduct such a change and address issues with it, like ranking results changes?
  • Performance From my POV the biggest impact area: Perceived speed is, as you mention, very important for user satisfaction and retention. Hypothesis: As user I don't care if all sidebar links are ready as I want to start (passively) interacting with the content. As soon as the content is available I'm able to start reading and scrolling. My comment in T237636#5697840 stands true. Also, having header underneath content loading late is the case in legacy Vector and users seem satisfied with it. In an alternative hypothesis users would wait for the logo and the (invisible) sidebar to kick in before reading. I don't buy into that in our case, but we should consider test it. A third alternative hypothesis were that personal tools and search are gaining importance, are crucial for achieving the success critieria for this project and therefore all of the header should be come first. All possible risks above are true for this, and it would mean to reconsider many of the current structure givens in legacy Vector, that we only prolonged in order to speed up development.

Additionally on layout:

  • Your point about wrapping of the personal tools menu is valid! We will run into multiple wrapped lines with absolute positioning on smaller screens. It's an edge case though that we are planning to tackle differently (personal dropdown menu) further down the project roadmap as well and in the mean time fix temporarily.
  • Flexbox could also help us achieving a different order without the absolute positioning dependency (or just as fallback).

Whichever solution we decide on, it has to fulfill all needs above and be approachable in code and usability terms. It will certainly be complex one way or the other, just the risk (cost) seems different to me.

SEO

Regarding general data order, there is some related discourse in T254631.

nray added a comment.EditedJul 29 2020, 4:37 AM

Thanks @Volker_E and @Niedzielski . I dug into the performance aspects of a content-first vs header-first (plus sidebar, article toolbar, personal tools) DOM order more since that was identified by @Volker_E as potentially having the biggest impact:

Comparing content-first vs. header-first DOM order and its impact on the 14KB target budget

Why is this important?

Because Vector's DOM order currently positions the content before the header, sidebar, article toolbar and personal menu, the browser renders the content first. If we move Vector's header, sidebar, article toolbar, and personal menu above the content there might be a concern that the user would see these navigational items first instead of the content at first paint and users would need to wait longer to see the content. Since the content is the most important item on the page, it is a valid concern, but also one I am skeptical of.

In T231168, the performance team stated a desire for fitting our "above-the-fold" layout and content in the first 14KB of the response of the page in order to optimize the constraints of TCP slow start algorithms in which a maximum of 10 TCP packets (~14KB) can be sent before the client must send acknowledgment of its receipt. Although this number is not an exact science [1], it is a recommended practice to include above-the-fold content within this budget so that if the browser performs a first paint with this payload, it is meaningful to the user.

Therefore, I took the same steps @Krinkle did in T231168#5436324 to see what effect moving the header, sidebar, personal toolbar, and article toolbar above the content would have on this 14KB budget. Note that my test differed from @Krinkle's in the fact that I measured the end of the first paragraph on the Stockholm page because I wanted to see if we could fit this (including the infobox) within that budget so users would have content to read:

Steps performed
Size of HTTP headers:

  • curl -i https://en.wikipedia.org/wiki/Stockholm > http-head
  • trim until line above <!DOCTYPE html>.
  • measure with wc -c.

Size of HTML until end of first paragraph (includes infobox as well):

  • curl -i https://en.wikipedia.org/wiki/Stockholm > html
  • keep only until before <a href="/wiki/Stockholm_County" title="Stockholm County"> …
  • measure with cat | gzip -7 -c | wc -c
Results
Size of HTTP headers (uncompressed)1,060 bytes
Size of HTML until end of first paragraph with content-first DOM order (gzipped)7,442 bytes
Size of HTML until end of first paragraph with header-first (and sidebar including language links) DOM order (gzipped)20,179 bytes
Size of HTML until end of first paragraph with header-first (and sidebar without language links) DOM order (gzipped)9,911 bytes
Total transfer size (gzipped) until end of first paragraph with content-first DOM order8.3 KB
Total transfer size (gzipped) of until end of first paragraph with header-first (and sidebar without language links) DOM order10.71 KB
First Conclusion

The sidebar's language links comprise the bulk of the above-the-fold HTML bytes (not including content) and moving the header, sidebar, personal toolbar, and article toolbar with the language links included in the sidebar exceeded the 14 KB budget. However, as part of the Desktop Improvements project, we plan to move these links out of the sidebar so we need to factor this into the calculation. With this factored in, the total cost comes out to be 10.71 KB and easily meets the 14KB budget recommended by the performance team. In all likelihood, the browser would probably be able to render much more than this on first paint because:

  1. We are well under the 14KB budget
  2. The browser is blocked from performing first paint until the two stylesheets in the <head> are loaded and parsed which allows the browser additional time to download more HTML.
Using WebPageTest to Determine Total Bytes Loaded At First Paint

As noted in my first conclusion above, my guess is that in the vast majority of cases and pages, the browser will be able to render all of the above-the-fold HTML and content at first-paint (and likely much more) if we switched to a header-first DOM order. However, I wanted to see more hints that this would be the case in the wild so I turned to WebPageTest. I performed 26 tests total all over the globe and with network connections ranging from 3G Slow to FIOS to Native and mostly using the Barack Obama page.

Steps performed
Using a combination of WebPageTest's "Waterfall" view and "Raw Details" view to identify where first paint occurred and the bytes download before first paint, I was able to approximately determine the percentage of the page's HTML rendered downloaded (downloaded is the most accurate term here as the browser also has to parse and perform rendering steps) before first paint.


Results

24 tests showing bytes downloaded before start render (first paint) from the Barack Obama page (265,480 total bytes)

Test location - browser - connectionBytes downloaded Before First PaintApproximate Percentage of HTML downloaded Before First Paint
Ireland - EC2 Windows - Chrome - Native240,09290%
Amsterdam, NL - IISpeed - Chrome - Native174,55966%
Zurich, Switzerland - Chrome - Native174,56066%
South Africa - Chrome - Native265,480100%
Virginia USA - EC2 - Chrome - Native207,32478%
Nottingham, East Midlands, UK - Chrome - LTE265,480100%
Nottingham, East Midlands, UK - Chrome - Native162,64261%
Brussels, BE - Chrome - Native218,67782%
Sydney, Australia (Bulletproof Networks) Chrome FIOS265,480100%
Mumbai, India - EC2 - Chrome - Native162,64061%
Mumbai, India - EC2 - Chrome - Cable249,25394%
Istanbul, Turkey - Cloudeos - Opera - LTE265,480100%
South Africa - Chrome - 4G265,480100%
Stockholm, Sweden - Firefox - Native265,480100%
Stockholm, Sweden - Firefox - 3GSlow265,480100%
Prague, Czech Republic - Chrome - 3GFast265,480100%
Frankfurt, Germany - Dynatrace - Chrome - Cable265,480100%
Paris - EC2 - Chrome - 4G265,480100%
Dallas, TX - Chrome - 4G265,480100%
Dulles, VA - Firefox - 4G265,480100%
California - ScientiaMobile - Chrome - DSL265,480100%
Denver, Colorado USA - Chrome - Cable265,480100%
Virginia USA - EC2 - Chrome - DSL265,480100%
Virginia USA - EC2 - Chrome - 4G265,480100%

1 test showing bytes downloaded before start render (first paint) from B8_polytope page (95,375 total bytes)

Ireland - EC2 Windows - Chrome - Native48,43750%

1 test showing bytes downloaded before start render (first paint) from Tree page (122,687 total bytes)

Lincoln, Nebraska USA - Chrome Native122,687100%
Second Conclusion (and closing)

All of the WebPageTests I performed downloaded at least half of the page's response payload before first paint occurs (50% being the lowest percentage completed before first paint) which suggests that if we move the header, sidebar, article toolbar, and personal menu above the content, first paint would most likely include all of these above-the-fold elements, but also include a lot of the content below-the-fold. Furthermore, from my tests, there is no evidence to suggest that users seeing the header first and having to wait to see the content would be a likely scenario that would occur. If performance is the primary reason we are maintaining the status quo of Vector's content-first DOM order, I recommend we rethink this.

[1] https://www.tunetheweb.com/blog/critical-resources-and-the-first-14kb/

Thanks @nray for this in-depth researched comment. It seems helpful to have Performance-Team's inputs in response to verify. cc: @Krinkle

Thank you @nray for this very thorough performance analysis. I agree with your conclusions. Beyond the the theoretical initial 14kb window, we know that browsers use some heuristics to avoid having too many paints early on, and can intentionally delay first paint.

We are very lean in terms of critical path before the main content compared to other websites and our observation is that most of the time the majority of the above-the-fold content (minus "large" images) appears at once on first paint. I doubt that moving this UI chrome content back to its semantically correct position at the top of the HTML will have any measurable impact on our time to first paint, nor on the amount of content rendered during that first paint event.

If despite all these observations, you're worried about a potential impact on when the first paragraph is displayed to the user, you can now track this using Element Timing, which is available on Chrome since 77. I had a hacky patch for that which didn't go beyond code review. I abandoned it for the reasons I've just described, it's highly likely to be the same as first contentful paint 99% of the time.

nray added a comment.Sep 1 2020, 3:53 PM

Thank you for the feedback @Gilles !

Comparing content-first vs. header-first DOM order and its impact […]

Results
Size of HTTP headers (uncompressed)1,060 bytes
Size of HTML until end of first paragraph with content-first DOM order (gzipped)7,442 bytes
Size of HTML until end of first paragraph with header-first (and sidebar including language links) DOM order (gzipped)20,179 bytes
Size of HTML until end of first paragraph with header-first (and sidebar without language links) DOM order (gzipped)9,911 bytes
Total transfer size (gzipped) until end of first paragraph with content-first DOM order8.3 KB
Total transfer size (gzipped) of until end of first paragraph with header-first (and sidebar without language links) DOM order10.71 KB

First Conclusion: […] Second Conclusion […]

Awesome. This is some research here. Thanks @nray!

I agree with @Gilles that "time to first paint" and "time to above-the-fold article text" painting would likely not be negatively affected.

However, I do expect visual progression to improve significantly. That is, "the time until visually settled", or more specifically the time of the last last visual change above-the-fold. As the header, sidebar and logo instructions would no longer be transmitted after the below-the-fold HTML payload.

Right now, even on a moderately fast connection when navigating between articles you will (briefly) first see the article appear without skin header and then the header appears briefly later. This doesn't cause any layout churn as we do reserve that space. But it is a visual change nonetheless.

Browsers optimise for this by showing the old page until the next navigation has some content painted. In our case that currently means content without the skin header. This change would improve that and thus likely eliminate one of the rendering stages!

Browsers optimise for this by showing the old page until the next navigation has some content painted. In our case that currently means content without the skin header. This change would improve that and thus likely eliminate one of the rendering stages!

Do you have some further reading on this optimisation? Is it default in all major rendering engines now?

Jdrewniak added a comment.EditedWed, Oct 14, 8:59 AM

Just to recap the work done in this task: In accordance with the arguments presented above, the DOM order in modern Vector has been changed to reflect the visual flow of the page.
These changes will let us: shed a significant portion of the legacy CSS, improve the presentation on smaller screens, improve the loading experience, and bring Vector in line with more common accessibility patterns on the web.

The "jump to navigation" link has been replaced with a more common "jump to content" link.
The new DOM order is now:

  1. Jump to content link
  2. Header
    1. Sidebar button (with option to open sidebar menu)
    2. Search
    3. Personal menu
  3. Tabs
  4. Content
  5. Footer

There is still some followup work to do regarding the tab-order of the sidebar button and sidebar menu, but that has been captured in T262872. We also plan on conducting an accessibility audit of these changes. T263834.

Volker_E added a comment.EditedTue, Oct 20, 11:10 AM

In accordance with @ovasileva we'll move this to backlog and declare following tasks as sub-tasks

  • The indicators are still to be resolved one way or the other (already sub-task)
  • The tab order of sidebar buttons T262872
  • And the follow-ups from AFB testing would make good sub-tasks too
Volker_E renamed this task from [SPIKE 8hrs] Determine the optimum Vector DOM structure for a11y and performance to [Epic] Determine the optimum Vector DOM structure for a11y and performance.Tue, Oct 20, 11:11 AM
Volker_E removed Volker_E as the assignee of this task.