@dan_abramov @samccone But seriously, if you break down that process and realize, oh shit, if the root cause is a bunch of tiny things, then what does that say about the process, or when people are informed about these things.
@dan_abramov @samccone Actually since all the likes on your tweet are irritating for some reason now, I'll maybe show you there is less nuance then you are trying to make it.
For example heres a thread of some of the apps people who liked this tweet, work on. 1/x
For example heres a thread of some of the apps people who liked this tweet, work on. 1/x
@dan_abramov @samccone For example: The Under Armour page is shipping a lot of assets, and 61% of it is unused.
That is the lowest hanging fruit and most generalized here.
It appears they are going through a re-arch but original scripts (global.js) are the biggest pain.
No overnight solve though.
That is the lowest hanging fruit and most generalized here.
It appears they are going through a re-arch but original scripts (global.js) are the biggest pain.
No overnight solve though.
@dan_abramov @samccone Updater, is suffering from a similar problem. In this situation, again total initial JS/CSS sizes crush load times. (3.5MB uncompressed). However opportunity is great here because they are using webpack and could leverage code-splitting!
And not so ironically 76% dead code.
And not so ironically 76% dead code.
@dan_abramov @samccone For Floryda here reach.tech has done a great job being responsible in the overall size of the bundles. He has even greater opportunity though to remove his overall bundle sizses and do some more code splitting.
Tools make it hard toknow 100% (mebe glamor,libs,etc)
Tools make it hard toknow 100% (mebe glamor,libs,etc)
@dan_abramov @samccone For Vintage Software here, it looks like they are taking the OG approach to just shipping individual JavaScript files.
This actually is an okay approach and usually ensures you don't ship dead code. In this case this page cost includes 70-82% of unused code on each page.
This actually is an okay approach and usually ensures you don't ship dead code. In this case this page cost includes 70-82% of unused code on each page.
@dan_abramov @samccone Webflow, (It doesn't appear to use webpack on this homepage though) is on the smaller side at 2.5MB uncompressed JS/CSS. Once again we see about 60% of the JS unused (not bundling tho), and 95% of CSS unused. Cost here's JS, second is CSS. Not bundling and using unpkg !help also.
@dan_abramov @samccone Google Flights does a great job masking the overall cost of 3.5MB of JS/CSS by using some clever defer and async loading of all (4.4MB total sizes after) of their ad, authentication and maps api scripts until after the page loads. However still 50% unused on the page for initial.
@dan_abramov @samccone Here's the Microsoft Store. Although the team (have worked with personally) has tried to keep overall asset sizes down (2.0 MB) there is HUGE, and cost saving impact to reducing their initial renders not including 60% dead code. Could be saving 2-5 seconds on mobile. ++Conversion
@dan_abramov @samccone Here is stichfix's "Mens clothing" page!
Overall 4.0MB is a painful cost for desktop/mobile sites. Interesting enough the main bulk of assets wasted (93.8%) comes from inlined script and styles. 🙀🙀🙀
They use webpack but not sure why so much code is in their html and unused.
Overall 4.0MB is a painful cost for desktop/mobile sites. Interesting enough the main bulk of assets wasted (93.8%) comes from inlined script and styles. 🙀🙀🙀
They use webpack but not sure why so much code is in their html and unused.
@dan_abramov @samccone Facebook dot com here does a total run of 23/27MB. Memory pressure may be more of a perf concern then actual load times. However this site could load instantly if dead code amounts are 80% etc.
React.lazy will help solve both. Code splitting could have monumentus impacts here.
React.lazy will help solve both. Code splitting could have monumentus impacts here.
@dan_abramov @samccone Alright, heres MindMeMobile. For a landing page, I was surprised to notice a loading indicator for this page. But usually indicative of what I found.
4MB JS/CSS totals, 82% unused. You could drop the spinner by lazyload. This is a Wordpress site though and not sure if bundling.
4MB JS/CSS totals, 82% unused. You could drop the spinner by lazyload. This is a Wordpress site though and not sure if bundling.
@dan_abramov @samccone Here's Boeing's website. A smaller, amount of JS then the last few, but since over 63% of it is not even needed to load this page, you could consider it a waste and should be much smaller.
It looks like in this case a bunch of static assets and not bundling hurt the most here
It looks like in this case a bunch of static assets and not bundling hurt the most here
@dan_abramov @samccone Side not on this eval is that FB infra team also uses some clever async loading of scripts so that there is some loaded interactivity at about 6/7MB, however it sometimes stalls thread until 9-11MB. On desktop it's only noticable if you want to jump to something else right away.
