CSS Performance Tuning - Velocity 2015

Transcript

1. CSS Performance Tuning @JakubPawlowicz Velocity conference October 29th 2015 1
2. Web Developer since 2003 @Altmetric Open Source contributor author of clean-css 2
3. Agenda 1. Where are we? 2. Build time optimizations 3. Delivery optimizations 4. Parsing & rendering optimizations 5. Emerging angles 3
4. Where are we? 4
6. http://www.soasta.com/wp-content/uploads/2015/06/page-bloat-May15-page-composition.png 6
7. Both CSS & JavaScript block render flow so optimizing both is essential 7
8. Build time 8
9. BEM: block, element, modifier → first step in optimizing is writing good CSS → based around the idea semantic rules for styling → reduces coupling and improves code maintainability, which makes removing dead CSS code a reality 9
10. clean-css CSS minifier - removes what's unnecessary started in 2011 as side project of GoalSmashers.com open source, written in node.js 2M+ downloads from npm every month 10
13. additionally → @import inlining → supports source maps → supports WebComponents → 2x-10x faster than comparable tools → test coverage with over ~ 3k tests → compatibility modes (IE7, IE8, granular level) 13
17. Take aways ✔ Write CSS using frameworks like BEM to optimize the code for maintainability ✔ Optimize CSS files to reduce network & memory footprint 17
18. Delivery 18
19. HTTP/1 → It's 18 years old → Abused by modern web apps - asset concatenation, domain sharding → Performs redundant operations - opens multiple connections, all headers sent with every request 19
20. HTTP/2 → Connection multiplexing = no asset concatenation → Header compression → Request prioritization → Server push = no asset inlining 20
22. Important: in HTTP/2 we trust both client and server to optimize content delivery, however not all them implement HTTP/2 fully, and some of them do it differently Take Firefox vs Chrome and HTTP/2 request prioritization: 22
25. Mobile → HTTP/2 helps reduce network footprint and optimize asset delivery with connection multiplexing and headers compression → Lazy fetching is costly in terms of battery usage → Burst your data and return to idle - Ilya Grigorik, High Performance Browser Networking 25
26. SSL → Greater push for confidentiality, e.g. LetsEncrypt.org → Set up HTTPS session resumption, OCSP stapling, and optimal TLS and TCP frame size, all of which particularly affect mobile clients → HTTP/2 connection multiplexing means just a single TLS negotiation per origin 26
27. Compression → gzip & deflate providing a transparent way of optimizing served assets - still a substantial amount of traffic not using it → Zopfli 5% of extra size reduction for the price of longer compression → Brotli offers roughtly 20% better compression than Zopfli - coming soon to Chrome & Firefox 27
29. Caching → utilize browser caching and cache invalidation using ETag & Last-Modified headers → don't write your own caching mechanisms unless you have a good reason to do so 29
30. Latency → True limiting factor of perceived web speed → Particularly affects mobile clients or those far from origin servers → cumulative factor - does not improve with time → a round trip from Amsterdam to Sydney takes ~ 300ms, like on an average 3G connection 30
31. Content Delivery Networks to the rescue Preconnect & prefetch hints done by browser's heuristics or provided via <meta> tags 31
32. Take aways ✔ Serve fine grained assets with HTTP/2 and HTTP/1 fallback ✔ Replace inlining with HTTP/2 server push ✔ Move content closer to clients to reduce latency ✔ Optimize network stack for optimal mobile & desktop delivery 32
33. Parsing & rendering 33
34. Parsing → The less is there to parse the faster it's going to be → Optimal CSS batches => better perceived speed → Chrome / Opera CSS parser offers 15-25% speedup, can one day do it on a separate thread → Firefox experimental parallel CSS parser 34
35. Rendering → Building CSS object model blocks rendering → Optimal CSS batches minimize blocking behaviour → Above the fold rendering, via CSS inlining (HTTP/ 1) or server push (HTTP/2), to render critical CSS and defer the rest 35
36. Time to first byte vs DOM Paint → Trigger DOM Paint as quickly as possible → Optimize for perceived speed → Use HTTP/2 server push to deliver essential assets 36
38. Take aways ✔ Send CSS in optimal batches to minimize time spent on parsing, rendering & painting ✔ Render progressively, optimize for perceived loading speed 38
39. Emerging angles 39
40. WebRTC & Service Worker 40
41. → Promise of offline-first, native-like web applications → Peer to peer messaging with WebRTC → Background workers with Service Worker 41
42. WebRTC: Assets delivery (PeerJS) → Can we reuse existing WebRTC sessions? → Is it more efficient to download files from a local network? 42
43. Service Worker: instant page rendering → Can we serve a page from local cache without opening any network connections? → Can we prioritize content updates to anything else? 43
44. Service Worker: CSS patching via delta updates → Can assets be updated assets by a patch? → Is it an optional update? 44
45. Service Worker: Deferring updates on mobile networks → Is updating assets essential at this moment? → Do we have right network conditions to do so? 45
46. Summary 46
47. Apply evergreen optimizations 47
48. Embrace HTTP/2 with HTTP/1 fallback 48
49. Embrace Service Workers (if possible) 49
50. Measure 50
51. Find out who is using your site, from where, in which browsers, using what technologies 51
52. Find out who's your audience and tune your setup to deliver the best experience for them 52
53. Thank you 53
54. Q&A 54
55. Resources CSS Performance Tuning - London Web Performance meetup, May 2015 55