Proposal - Improving the Interactivity of primary content

[vigneshshanmugam]

Since tailor downloads all the scripts from the fragments asynchronously(Not in order) and all these scripts are loaded as AMD modules by require.js, The order of the script execution is not guaranteed since they are async. This introduces problems in some cases

Problem

• If the primary fragment script size is too big, Sometimes this does happen in real life and you could see others fragments racing with the primary and getting interactive (scripts being executed) even before primary.

Ideal workaround

• primary fragments can send a initial code chunk and can do code splitting to lazy load their assets to make it interactive ASAP.

Even though its the recommended way of improving the performance of the page, It does need lots of iteration and identify the critical JS parts that are needed by the page.

Preload to the rescue

We could solve this issue by prioritising resources using Preloading techniques.

Tailor does wait for the primary fragment on any given page since the primary fragment decides the Status Code of the Page, We could preload the available assets(JS and CSS) from the fragments before writing the Response Headers of the page.

Working on the Implementation, Will update the metrics here

[addityasingh]

@vigneshshanmugam Do you mean to preload only primary fragment's assets? And load the rest fragment's assets using AMD?

[vigneshshanmugam]

Preload assets till primary fragment is what I was thinking of, But need to test it under different scenarios and find out though.

[mo-gr]

Maybe I have a bit of a misunderstanding here... But how do you make the browser preload anything while waiting for the response of the primary fragment? While waiting for the primary, you can't send any headers to the browser because we have to wait for the status code, right?

[vigneshshanmugam]

@mo-gr Yes we do need to wait, But we can use the Link headers and make the assets discoverable..

Link: "<assets.js>"; rel="preload", "<assets.css>";  rel="preload"

By this way the resources would be early discoverable and when the require.js kicks in and request's for the primary fragment JS asset, The resource would be available immediately which helps in interacting with the page quicker than before

Savings == Download + parsing time to fragment.js

should have explained a bit more in the proposal :)

[mo-gr]

Got it. That sounds like free lunch. It costs us virtually nothing to implement this feature, older browsers will just ignore it and newer ones will have improved performance. I love it!

[vigneshshanmugam]

@mo-gr :D ofcourse thats the beauty

[addityasingh]

@vigneshshanmugam This is really great and elegant solution 👍

[vigneshshanmugam]

Tested the MVP internally on our existing Product pages with a local proxy to Skipper.

Scenario

• Average of 4 runs
• Nexus emulation mode
• Network Throttling - 150ms RTT

Metric	First Meaningful Paint	Mosaic Interactive(Custom)
Without Preload	1107	4137
With Preload	1098	3184

Result seems promising,Pretty clear that Primary fragments are given priority. Going ahead with the addition /cc @dazld @grassator @mo-gr

[sylvesteraswin]

@vigneshshanmugam since the feature is supported only available in chrome 50+ how will this help in almost the other 50% of the devices? https://en.wikipedia.org/wiki/Usage_share_of_web_browsers

Keeping future proofing out of the way.

[addityasingh]

@sylvesteraswin But I think this still is a lot of gain for very small effort. For rest of the devices there could be another approach, but will definitely not be this concise and easy to implement.

Additionally for most of the applications, the percentage of the browser share will probably be not same as https://en.wikipedia.org/wiki/Usage_share_of_web_browsers. So this seems a quick win. Thoughts?

[vigneshshanmugam]

@sylvesteraswin Yes for now the preloading is only available in Chrome and Safari tech preview.. Other browsers are also implementing this feature and its totally future proof.

We are also thinking of how to support the same technique for older browsers though.. Will come up with a plan and discuss link here.

[sylvesteraswin]

@addityasingh If most of the customers are not on latest version of chrome(which is mostly the case for mobile users) then this would become irrelevant and only be helpful to users who are on the latest platform. 🗡

But as @vigneshshanmugam pointed out, if we can figure out a way for this to be backward compatible then we can huge impact on users.

But all-in-all our future is secure 💃