Reduce time to render pages with thousands of code blocks

[wilhelmer]

Contribution guidelines

• I've read the contribution guidelines and wholeheartedly agree

I've found a bug and checked that ...

• ... the problem doesn't occur with the mkdocs or readthedocs themes
• ... the problem persists when all overrides are removed, i.e. custom_dir, extra_javascript and extra_css
• ... the documentation does not mention anything about my problem
• ... there are no open or closed issues that are related to my problem

Description

As outlined and demoed here, large topics can take a long time to render, up to 30 seconds, which makes them unusable. This only occurs when using the Material template.

@squidfunk has already looked at it, and it is most probably caused by the large amount of code blocks used in the sample topic. Other templates have less sophisticated handling of code blocks, which is why the issue doesn't occur when using other templates.

Expected behaviour

Pages should render fast in all browsers, regardless of the template used.

Actual behaviour

See description.

Steps to reproduce

See sample project linked in the description.

Package versions

• Python: 3.9.10
• MkDocs: 1.2.3
• Material: 8.2.3+insiders.4.10.0

Configuration

See sample project linked in the description.

System information

• Operating system: macOS
• Browser: Firefox, Chrome, Safari

[squidfunk]

Thanks for reporting. Just for anyone else coming here – the problem is observed on a page with over 1.7k code blocks, so very likely nothing to worry about for the average project. It applies to Insiders, as well as the community edition.

[squidfunk]

This was an interesting problem to solve. The problem stems from excessive reading of the Element.offset* and Element.scroll* properties in order to determine whether a code block overflows or not, which is necessary to make it focusable via keyboard to allow for better accessibility, as requested in #1514. Since all code blocks are mounted on load, and the page in question has more than 1.700 of them, this process took forever to complete:

While the initial layout takes the browser 1.4s, the user had to wait for another 35s until the browser becomes responsive again. Oops. Even worse: most of the work done is probably unnecessary, because the page is so long and most of the code blocks will probably never be interacted with.

This is now fixed in e71891f, as code blocks will now only be mounted when they are visible. The initial layout still takes around 1.4s, but the application will now mount in less than 500ms! I think that's a pretty good result:

[squidfunk]

Released as part of 8.2.5.