bedrock
bedrock copied to clipboard
mozilla
Improve firefox/all/ page performance
Description
See: https://bugzilla.mozilla.org/show_bug.cgi?id=1683671
TL:DR: The HTML payload for the /firefox/all/ page is 1.5MB, which can be a performance issue. The time it takes for the back-end to return the document also seems higher than other pages, likely because of all the links it needs to render in the hidden tables. We often see test failures on this page because the page was too slow to render.
We should try and improve both the front-end and back-end performance of this page. Hopefully there's a way without requiring a significant redesign / rebuild.
This issue could be another candidate where a front-end framework makes sense to try and lighten the DOM. We could move to a JS reliant page (using JSON/APIs to request the build info), whilst maintaining a separate HTML table based page as a fallback for older browsers?
Just one option though, there might be something simpler we could do.
One idea I had was that we could pre-generate JSON files based on product-details data at docker image build time that could be hosted as static files. These files could be loaded by the page as needed to build the lists and URLs needed for the page to work. Thoughts?
One idea I had was that we could pre-generate JSON files based on product-details data at docker image build time that could be hosted as static files. These files could be loaded by the page as needed to build the lists and URLs needed for the page to work. Thoughts?
Yeah, I think something like that could work. We'd still need a plain HTML fallback of some sorts, but that could be a separate page perhaps that we link to if the browser is old / JS is disabled.
We could also keep it mostly like it is now but pre-generate the bulk of the HTML as a file and include that in the main template.
We could also keep it mostly like it is now but pre-generate the bulk of the HTML as a file and include that in the main template.
This sounds like a great easy-ish win to at least lower the load on the back-end 👍
I wonder if we could simplify and use Django's Filesystem Cache backend for that view and it'll just cache the output on each pod. Could make the cache timeout 24 hours or so.
I like the idea of pre-generating the HTML that the page uses at build time, and then just loading it as a fragment into the page - like an extra-eager SSR page.
If we use the filesystem cache (or even the DB) as a regular, unwarmed read-through cache, we'll still get a risk of timeouts if the chosen pod hasn't had a chance to cache it before. Howeverrrrr I wonder if there's a sneaky way to run Django just for that view at build time, populating the filesystem cache as part of building the Bedrock image, so that it's ready and waiting when the container starts. We could then have something else that updates the cache fragment in the background/out of the request-response cycle, so that the cache is always current.
I'll think more, but I'm 100% for pre-generating as much as we can as poss, yeah
Just circling back here - I think any back-end performance tweaks we can do here will be good, especially in the short term. However I think reworking this page a bit might be the best overall solution, since the HTML payload itself is ~1.5MB already, and that's before we add images, CSS, JS etc. The experience older browsers get is also not that great - just one huge list of links for every product / os / language that's difficult to navigate.
I do wonder if we should consider splitting up the "plain HTML" experience into separate pages per product again, and keep this page as a more fancy "all products" page for modern browsers. We could then link to these separate pages as a fallback experience. That would require making some pre-generated JSON files from product details that the front-end could use.
The "modern for most, and separate pages for the rest" approach sounds great to me Alex. Let's do it. Happy to help provide any data you need from the backend.
@pmac I might add this issue as a personal goal (still thinking through options). If I do, then some backend data help would be appreciated. Thanks!
Edit: update - I'm not taking this one right now, so anyone else if free to work on it.