Movatterモバイル変換

[0]ホーム
URL:

Upgrade to Pro — share decks privately, control downloads, hide ads and more …
Speaker DeckSpeaker Deck
Speaker Deck

FaCSSt—CSS & Performance

Avatar for Harry Roberts Harry Roberts
January 21, 2016

FaCSSt—CSS & Performance

How CSS can improve (or harm) performance.

Avatar for Harry Roberts

Harry Roberts

January 21, 2016
Tweet

More Decks by Harry Roberts

See All by Harry Roberts

Other Decks in Design

See All in Design

Featured

See All Featured

Transcript

  1. FaCSSt—CSS & Performance Harry Roberts – BCN WebPerf – January,

    2016

  2. Hello, Barcelona!

  3. Who Am I?

  4. Hello, Barcelona! Harry Roberts Consultant Front-end Architect. CSS, Performance, Scalability,

    Architecture. @csswizardry #faCSSt

  5. CSS Performance ❤

  6. What We Know Already

  7. What We Know Already Styles at the top; scripts at

    the bottom. Styles block rendering; scripts block downloads. HTTP requests are expensive—minimise them. Minify, concatenate, and Gzip—reduce transfer count and size.

  8. The Critical Path

  9. The Critical Path Critical in our fight for performance. Journey

    between a user requesting a page and them seeing something. Most of it is spent on CSS. The Critical Path is dead time for your users. Make this journey as short and light as we possibly can.

  10. We’ve started asking for a page. The HTML has made

    it over the wire (see <title>). Now we’re waiting for some CSS. You can see the Critical Path happening!

  11. The Critical Path HTML and CSS are on the Critical

    Path. DOM and CSSOM are needed before anything can be rendered. Thus, they are render-blocking resources. Users see nothing until both are on the client. Get these over the wire as quickly as we possibly can. Everything else can load progressively (images, video, audio, even JS). CSS pretty much is the Critical Path.

  12. The Critical Path Optimise the Critical Path. Make it as

    short as possible. Do not put anything unnecessary onto it. Don’t make the Critical Path carry too much.

  13. CSS Is Your Biggest Performance Bottleneck*

  14. CSS Bottleneck Browsers will not render anything until they have

    all the CSS for the current view/state. Browsers download all CSS: even CSS that doesn’t match the current media type/query.

  15. <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width,

    minimum-scale=1.0"> <title>Test</title> <link rel="stylesheet" href="all.css"> <link rel="stylesheet" href="screen.css" media="screen"> <link rel="stylesheet" href="print.css" media="print"> <link rel="stylesheet" href="bs.css" media="bs"> </head> Always needed. Needed right now. Only needed if we print. Never needed—it’s a nonsense media type.

  16. But they all get downloaded?!

  17. tl;dr: Get CSS onto the Client ASAP

  18. Get CSS onto the Client ASAP Smaller file sizes are

    better. Keep things off of your Critical Path. Make the Critical Path as short as you possibly can. Just get CSS over the wire as fast as you possibly can. Prioritise CSS above all else for first render.

  19. Things We Should Do

  20. The Three Cs.

  21. The Three Cs Concatenate CSS into as few files as

    possible to reduce HTTP requests. Compress transfer over the wire using Gzip to reduce file sizes. Cache stylesheets to prevent them being re-requested unnecessarily.

  22. Remove Unused CSS

  23. Remove Unused CSS CSS file sizes generally shouldn’t be that

    problematic. But still, waste is waste. If it’s not used, try get rid of it.
  24. None
  25. None

  26. Remove Unused CSS DevTools » Audits » Web Page Performance

    » Audit Present State » Run UnCSS automates this (Grunt, Gulp, etc.).
  27. None

  28. Inline Critical/Above the Fold CSS

  29. Inline Critical/Above the Fold CSS A huge performance boost. Send

    the (critical) CSS back with the first response. Cut out an entire round trip—fewer HTTP requests. CSS arrives with HTML, not after it. Begin rendering immediately. Lazy load the rest of the CSS when we get chance. More on this later—sort of.

  30. Google don’t send any
 separate CSS files.

  31. They inline it all.

  32. Inline Critical/Above the Fold CSS Important to lazy load the

    rest of the CSS and then cache it. If it’s a single-page site then we don’t need to lazy load a CSS file. Send it over with the HTML every time.
  33. None
  34. None

  35. Things We Should Avoid

  36. Do Not @import Stylesheets

  37. Do Not @import Stylesheets @import completely kills performance. Causes so

    much extra work. Adds more round trips. Delays downloads. Increases time to render dramatically.

  38. URL index.html 01.css 01.css 02.css 02.css Browser Server

  39. The @import Process Client asks for HTML. Server sends HTML

    back. HTML asks for CSS. Server sends CSS back. CSS asks for more CSS. Server sends more CSS back.

  40. The @import Process Don’t let CSS request other CSS. All

    requests for CSS should be sent out at the same time. Basically, use multiple <link />s.

  41. Browser Server 01.css, 02.css 01.css, 02.css URL index.html

  42. The <link /> Process Client asks for HTML. Server sends

    HTML back. HTML asks for CSS and more CSS. Server sends CSS and more CSS back.

  43. @import on Sotheby’s Working on a Sotheby’s site with a

    client. Very complex mechanism for producing per-page CSS. Complex Sass dependencies (anything can import anything). Compiling Sass on the server as-per the CMS. All in the pursuit of performance. Then they were @importing a CSS file!

  44. @import on Sotheby’s All the hard work of trying to

    create the tiniest possible CSS file… Was being completely undone by @importing their Google Fonts CSS.

  45. @import at Sky Let me show you something crazy…

  46. None

  47. 25kb? Nice!

  48. Wait. What?
 More CSS?!

  49. @import at Sky Why is that all the way down

    there? Either lazy-loaded via JS, or… It’s being @imported.
  50. None

  51. @import at Sky Whilst the browser was downloading, unpacking, parsing,

    and executing the first stylesheet, it had time to download 15 other assets. Then it was told to go off and get some more CSS. Which it had to download, unpack, parse, and execute. Then the browser could start rendering. @import kills performance by delaying everything.

  52. @import at Sky Ideal fix: concatenate into one file*. Quick

    fix: serve via two <link /> elements**.

  53. Avoid Base64 Encoding

  54. Avoid Base64 Encoding We’re told Base64 reduces HTTP requests—a good

    thing. But it actually creates something much more expensive…

  55. Avoid Base64 Encoding Base64 moves progressive assets onto your Critical

    Path. Things that could have loaded as they were ready are now forced to download immediately, and on the Critical Path. Made the journey longer. Making the browser do more work before it can render.

  56. Avoid Base64 Encoding Don’t put non-essential assets onto your Critical

    Path. Pages can render without images. You’re making the CSS heavier for unnecessary assets—let images load in when ready. Never put fonts on the Critical Path—can add hundreds of KB. All just delays that first render.

  57. Don’t Use an Asset Domain or CDN

  58. Don’t Use an Asset Domain or CDN Adds more work

    onto the Critical Path. Makes the browser look up new DNS. Can add 120ms before the CSS even starts downloading. 120ms that we don’t need to spend at all.

  59. Don’t Use an Asset Domain or CDN Always serve CSS

    from the host domain. Host domain’s DNS is already warmed up—zero extra cost. We can start sending CSS back immediately.
  60. None

  61. Asset Domains on m.skybet.com Started off with everything on host

    domain. More requests as site grew larger. Lack of parallelisation was costing us. Created a story for moving assets onto asset domains (stX.skybet.com). Can now download same amount of assets in less time, right?

  62. Asset Domains on m.skybet.com Not quite. Nightly WebPage Test showed

    us that performance had gotten worse! Visually complete was almost ¼ second slower. How on earth had this happened?!

  63. Asset Domains on m.skybet.com We’d started incurring new DNS lookups.

    The cost of going to a new domain was higher than the cost of lack of parallelisation. We moved our CSS back onto the host domain. Left other assets on asset domains. Performance was better than ever.

  64. HTTP/2?

  65. HTTP/2 Will Change Things HTTP/2 brings in new changes. Some

    will really help performance. Requests get cheaper. Preemptively send assets over the wire. Employ better caching strategies.

  66. Multiplexing

  67. Multiplexing HTTP/1.1 is like buying a single item at a

    grocery store, taking it back home, going back to the store for the next item you need, and repeating until your pantry is fully stocked. Multiplexing gives you a shopping cart so you can pick up everything you need in one trip. —cloudflare.com/http2/what-is-http2

  68. Multiplexing HTTP requests become cheaper. More requests can be made

    per TCP connection. Concatenation and spriting become unnecessary! Practically, this means…

  69. Better Caching Strategies

  70. Better Caching Strategies We can now split CSS into many

    different files. Split them based on rate-of-change. Only need to invalidate cache for smaller parts of your UI. Send your reset/Normalize.css styles in one file: cache it forever. Send your app styles in another that can change more frequently. Per-page CSS becomes marginally easier.

  71. <link rel="stylesheet" href="core.css" /> <link rel="stylesheet" href="app.css" /> <link rel="stylesheet"

    href="video-player.css" /> Hardly ever changes. Send as one file and cache for a long time. Changes more frequently. Send as its own file and cache-bust it when needed. Only need this on the video page. Becomes cheap to send as an extra request.

  72. Server Push

  73. Server Push Oh, you asked for an HTML page? Take

    this CSS as well—you’re gonna need it!” Send assets to the browser before it’s even asked for them. Remove round trips completely. Like native inlined CSS (in a very roundabout way). “


  74. Browser Server 01.css, 02.css 01.css, 02.css URL index.html

  75. Browser Server URL index.html,
 01.css, 02.css

  76. Server Push No longer waiting for the HTML to request

    the CSS. We can send the CSS back in anticipation. Saves us so much time—no need to go back to the server!

  77. Lessons

  78. Lessons CSS is expensive. Optimise your Critical Path. Understand where

    all your CSS is coming from. Avoid Base64. Don’t use @import. Avoid CDNs/asset domains for CSS.

  79. Thank You

  80. Thank You Harry Roberts[email protected] @csswizardry

[8]ページ先頭
©2009-2025 Movatter.jp