Lazy load BCD table about yari HOT 6 CLOSED

I made a rough branch that started implementing this. First, the cli needs to break the packaged JSON apart into index.json and bcd.json. How I did that wasn't particularly important but now some important changes took place:

1. The rendered HTML file didn't have the full BCD table. It just has this: https://gist.github.com/peterbe/900567790e7025181e2c811fc0c111f4

2. The serialized state, instead of {"type":"browser_compatibility","value":{"__compat":{ ... it now had {"type":"browser_compatibility","value":{"uri":"bcd.json"}}

3. Once the browser React mounts the <BrowserCompatibilityTable/> component, instead of displaying the provided data from a prop, it used that provided uri as a prop and did fetch(uri) to get the "meat".

4. The final HTML file rendered by the cli has less HTML and less serialized JSON.

5. The same amount of data needs to travel from the server to the client. Instead of one big index.html (or index.json) it now has a note and a separate bcd.json file. So, less data up-front but a necessary XHR request.

You can see the result here: https://stumptown-peterbe-lazy-load-bcd-tables.s3-us-west-1.amazonaws.com/en-US/docs/Web/HTML/Element/video/index.html
(compare to this which might change by the time you read this)

That index.html size difference was as follows:

• Before: 140K (19K gzip)
• After: 70K (15K gzip) + bcd.json 15K (1.0K gzip)

So, before the browser had to download 19K, now it has to download 15K + 1K = 16K.

If this wasn't a direct hit but that the user client-side navigated to the page, the index.json size difference was as follows:

• Before: 60K (9.0K gzip)
• After: 40K (8.0K gzip) + bcd.json 15K (1.0K gzip)

So, before the browser had to download 9K, now it has to download 8K + 1K = 9K.

Basically, there's a small win here in terms of amount of data that needs to be shipped from the CDN to the client. But the browser's JS now has to do more, which is to start an XHR request and once that comes back execute the React component and update the DOM. That's potentially additional load on the main thread but in principle it's work that can start after the page has been fully rendered and considered complete.

Smaller data up-front means the browser can get started displaying useful above-the-fold content sooner. But more CPU work is needed by the browser, although it's reasonably nicely staggered.

from yari.

The next step is to not just lazy-load the data but also fully lazy load the JavaScript and maybe also the CSS. That follows the same principle as above but just more extreme. The initial doc's CSS and JS will be smaller but that JS and CSS still needs to be transmitted from the server to the browser.

from yari.

Perhaps the next step now is to wrap the browser BrowserCompatibilityTable in an IntersectionObserver so that only when you actually scroll down does the extra XHR needs to be downloaded and processed.

This feels somewhat orthogonal to the idea of code splitting but perhaps safest to do one thing at a time.

from yari.

I just wanted to drop a note so I don't lose the research.
See this page:
https://d24on6m5y27ek3.cloudfront.net/en-us/docs/web/html/element/canvas/index.html
It contains all the data you need, serialized as JSON, in the HTML document.
If you look careful enough you'll notice a LOT of that data comes from the browser-compat-data which exists there to help the browser-compatability-table ingredient be able to build the table.

If you remove that data, from the serialized JSON, how does that affect the HTML? Here's the answer:

▶ ls -ltrh index.html*
-rw-r--r--  1 peterbe  staff   234K Jun  5 15:17 index.html
-rw-r--r--  1 peterbe  staff    37K Jun  5 15:17 index.html.gz
-rw-r--r--  1 peterbe  staff    26K Jun  5 15:24 index.html.nobcd.gz
-rw-r--r--  1 peterbe  staff   126K Jun  5 15:24 index.html.nobcd

Basically, we can make the document 11KB smaller by not having the BCD table server-side rendered in the document.

from yari.

#187 is now rotten. Also that PR solved it by creating one bcd.json table per occurence of a BCD table in the page. And if a page had 3 BCD tables, it would have created bcd.json, bcd-2.json, and bcd-3.json. That sucked. It should have just created a bcds.json file that is key'ed by the query ID instead.

from yari.

Important note-to-self; a great test page is this one: http://localhost:5000/en-US/docs/Mozilla/Add-ons/WebExtensions/Browser_support_for_JavaScript_APIs/

from yari.