Visiting a heading within a page can have a large layout shift

[lfdebrux]

Description of the issue

When visiting a heading within a page on the Design System website, there can be a large layout shift that causes the browser viewport to end up showing the wrong part of the page.

For example, loading the URL for the 'Start by asking one question per page' section of the question pages pattern page in Chrome 92 can sometime result in the browser showing the 'Back links' section:

https://user-images.githubusercontent.com/503614/127671243-273b39e8-c271-4c37-ac54-9c090a678009.mp4

This behaviour is unpredictable; sometimes the browser will produce the [expected behaviour].

I have also seen this happen when visiting a page that is linked from another page within the Design System website, for instance, the guidance on when not to use a 'none' checkbox links to the 'start by asking one question per page' guidance.

Recording of Safari showing unexpected behaviour when following a link

https://user-images.githubusercontent.com/503614/127672657-48644cb4-fe9d-428e-b726-4297a598971d.mp4

Steps to reproduce the issue

1. Open a new browser tab
2. Visit the URL https://design-system.service.gov.uk/patterns/question-pages/#start-by-asking-one-question-per-page

Note that this will not always produce the behaviour recorded above, sometimes it will produce the expected behaviour. However, on this page the browser fairly reliably jumps back to the same place within the page, when it does jump.

Actual vs expected behaviour

I expect that when the page has finished loading the heading 'Start by asking one question per page' is at the top of the browser window.

Recording of the expected behaviour in Chrome

https://user-images.githubusercontent.com/503614/127672361-df87da15-a685-4334-b715-4d166ae4a700.mp4

Environment (where applicable)

I've tested locally with the URL https://design-system.service.gov.uk/patterns/question-pages/#start-by-asking-one-question-per-page and the following browsers:

• Operating system: MacOS Catalina 10.15.7
• Browser: Chrome 92.0.4515.107 (Official Build) (x86_64), Safari 14.1.2 (15611.3.10.1.5, 15611), Firefox 90.0.2 (64-bit)

I've also tested this in IE11 on Windows 7 using BrowserStack.

All browsers tested show similar behaviour; when loading the page for the first time it will "jump back" from the correct heading to the 'Back links' heading, but subsequent loads the browser will end up at the correct heading.

I've also tried different pages on the Design System website, with similar (if less dramatic) results.

Notes

I'm not sure what is causing this, or if it is a problem that is affecting users, but thought I'd create an issue about it so we could discuss.

[lfdebrux]

I've tried looking at this with the performance tab of the Chrome DevTools; it's hard to reproduce because the jump doesn't seem to happen if you just reload the page, although if you do there are some large content shifts that I wouldn't necessarily expect.

I've had more success recording the jump in Safari (I can reproduce the issue more reliably in Safari, but I suspect that is just because of caching rather than a difference in the browsers); here's an export of the timeline: design-system.service.gov.uk-recording.json.zip

[edwardhorsford]

I'm experiencing this the majority of the time - it's near impossible to use an anchor to go to the right part of the page.

[querkmachine]

I would assume this is caused by the examples hosted in iframes. We include a piece of JavaScript that watches the iframe's contents and resizes the iframe to fit, so that we don't get the 'double scrollbar' effect.

This requires the iframe contents to be loaded and for any JS within them to initialised first, however, so it's very common for them to only resize after a short delay.

I'm not really sure of how that could be resolved. Whilst we could write JS to hijack and defer the jump to anchor, all but the first iframe on the page is lazyloaded, so it's quite likely that jumpiness will still happen if the heading being navigated to is below two or more iframes.