3 ms·
Also, inlining CSS prevents its caching, so the first page load may be faster but subsequent ones will suffer from that if the amount of code is fairly large.
by blauditore 9y ago
Also, inlining CSS prevents its caching, so the first page load may be faster but subsequent ones will suffer from that if the amount of code is fairly large.
- abritinthebay 9y agoYup. I work with a very large site and our entire CSS is about 25kb after gzip. It’s a pointless micro-optimization.
- ShirsenduK 9y agoGoogle Chrome Developers/Google Developers Youtube channel has great content on Frontend optimisations by Paul Irish and others. They teach you what to measure and how. You might want to check that if you are interested in Frontend Engineering. When your site has a large audience, every microsecond counts. Especially when you don't have someone bankrolling for your traffic. Speed plays an important part for SEO and UX.
- abritinthebay 9y agoI’m quite familiar with Paul’s work. He’s not really saying anything new in those talks either. It’s good technical info but again - a pointless micro-optimization in most cases. There are so many other, bigger, better, wins to focus on first. Considering anything Google does as useful for the average developer - even at a reasonably large company - is like thinking pizza delivery guys should emulate UPS: it’s a misunderstanding of context.
- warrenm 9y ago25kb of CSS after compression? That's a damn lot of CSS
- abritinthebay 9y agoThat’s all possible css across the site. Average is much lower. Our global css is 3kb for example.
- ShirsenduK 9y agoCritical Path CSS is not fairly large, its fairly small in most cases.
- artursapek 9y agoWhen you say "critical path" you just mean above-the-fold stuff?
- ShirsenduK 9y agoMostly yes. This has more information https://developers.google.com/web/fundamentals/performance/critical-rendering-path/ https://developers.google.com/web/fundamentals/performance/c....