Proposal - Improving the Interactivity of primary content about tailor HOT 12 CLOSED

@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 :)

from tailor.

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

from tailor.

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

from tailor.

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?

from tailor.

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!

from tailor.

@mo-gr :D ofcourse thats the beauty

from tailor.

@vigneshshanmugam This is really great and elegant solution 👍

from tailor.

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

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

from tailor.

@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.

from tailor.

@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?

from tailor.

@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.

from tailor.

@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 💃

from tailor.