As a user I want larger chunks of hidden HTML to not be loaded at all so that I can save bandwidth.
(Feel free to split this into subtasks during sprint)
We would like to get a sense of how reducing HTML size impacts first paint.
We have identified navboxes as representing 10% of the HTML. Although this is minimal compared to reference HTML (see T123328) it may provide us a cheap way to verify if reducing HTML does indeed impact the first paint for our users significantly (with whatever instrumentation is at our disposal), and the implicit benefit of ensuring we can do a good job of measuring and showing said impact.
- A patch should be prepared that for MobileFrontend (beta only) strips navboxes from the HTML. It should be configurable so we can turn it on and off.
- This should be first deployed on beta cluster in the beta mode channel and we should verify and record there how we expect this to impact first paint, HTML size and server response time in a controlled fashion.
Specifically:
- How does this impact TTFB for the Barack Obama article (expressed in relative terms e.g. first paint halved)
- How does this impact First paint for the Barack Obama article (expressed in relative terms e.g. first paint halved)
- How does this impact fully load time for the Barack Obama article (expressed in relative terms e.g. first paint halved)
- How does this impact HTML bytes for the Barack Obama article (expressed in relative terms e.g. first paint halved)
- Now enable on the beta cluster in mobile web stable and measure the impact on the above as before.
- Patch should now be deployed to the production cluster on enwiki (beta only)
- We should verify and record the degree to which result in mobile web beta matches our expectations on the beta cluster (it is understood there are some differences in cache hits; cachebusting parameters may be one way to reduce such confounding variables, even if imperfectly)
- Send a report to team detailing lessons learned and how we can improve this implement/measure process in future and what next steps should be (configure off/continue experimentation in this field)
Next:
- Pushing to stable. If the impact is not generally harmful on cached pages, it should likely be promoted to production on the mobile web. A cache purge is not necessary as the change can fade in. However, this does raise the point of how our instrumentation can know when the page has navboxes and when they're hidden.
- In future we may aim to lazy load the navbox content. However, this is out of scope at the moment as the content is already CSS hidden and this would be a new feature.
