Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Frontend performance

48 visualizaciones

Publicado el

Slides for an internal tech meeting at Beezwax

Publicado en: Software
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Frontend performance

  1. 1. Frontend Performance Make websites load faster by analyzing the Critical Rendering Path
  2. 2. Why • 47% of consumers expect a site to load in 2 seconds or less • 40% abandon a site if it takes more than 3 seconds to load • 79% of shoppers who are dissatisfied with the website speed are less likely to consume the website’s services For more stats: https://blog.kissmetrics.com/loading-time/?wide=1
  3. 3. Critical Rending Path • The CRP is the minimal amount of information the browser needs in order to display a page • Understanding the CRP it’s key for optimizing a website • By understanding how the browser displays a page, we can optimize our application to do it faster
  4. 4. Critical Rending Path Let’s see what information the browser needs to collect before drawing our website for the first time.
  5. 5. DOM & CSSOM • Before the browser can render anything, it must build the DOM and CSSOM. • The DOM is the Document Object Model, which is a tree data structure built from HTML source code. • The CSSOM is the CSS Object Model, which is a tree data structure built from CSS source code. • DOM and CSSOM are independent from each other.
  6. 6. Taken from https://developers.google.com/web/fundamentals/performance/critical-rendering-path/constructing-the-object-model?hl=en
  7. 7. DOM & CSSOM • Many browsers have Developer Tools • Screenshots in this presentation use Chrome, but other browsers should have similar features. • We can use our browser’s “DevTools” to know how long the browser took to generate our DOM and CSSOM.
  8. 8. Render Tree Taking our DOM and CSSOM, the browser combines them into a Render Tree
  9. 9. Layout • With the Render Tree in place, the browser can now calculate the position of all of our HTML elements in the page • All percentages and relative units are converted to pixels • This step is called “Layout” or “Reflow”
  10. 10. Painting • The browser has now all the information it needs and starts the last step, which is called “Painting” or “Rasterizing” • It basically draws the whole page into the screen
  11. 11. Quick Review 1. Generate DOM 2. Generate CSSOM 3. Combine DOM and CSSOM into Render Tree 4. Run Layout on the Render Tree and get the exact position of each element 5. Paint the elements into the screen
  12. 12. That’s it! We can now optimize our pages by analyzing each step of the CRP using DevTools. Our goal is to optimize each step in order to render an initial usable page as soon as possible.
  13. 13. Tips ’n’ Tricks • Render-blocking CSS • CSS selector tuning • Render-blocking Javascript • Webfonts tuning • Prefer CSS animations over JS animations • Embed small resources (images, css, etc)
  14. 14. Render Blocking CSS • The browser waits until all CSS is downloaded and parsed before rendering the page • Media types and media queries allow us to mark some chunks of CSS as non-blocking (if we are on desktop we don’t need to block for mobile styles) • All CSS resources are downloaded
  15. 15. Render Blocking CSS <link href="style.css" rel="stylesheet"> <link href="style.css" rel="stylesheet" media="all"> <link href="portrait.css" rel="stylesheet" media="orientation:portrait"> <link href="print.css" rel="stylesheet" media="print">
  16. 16. CSS Selector Tuning Prefer using classes over IDs as they have practically the same performance • Classes can be composed, eg: .hidden .subtle .responsive • Using IDs in selectors makes it too easy to override other rules you might not want to • Avoid using elements in selectors, as they hurt performance the most, eg: li { color: red; } • Avoid nesting rules more than 3 levels deep, eg: .foo .bar .baz
  17. 17. CSS Selector Tuning Let’s see how the browser matches the following rule: .menu li a { color: red; }
  18. 18. CSS Selector Tuning 1. The browser matches the rule from right to left, so starting with the a part of the rule, all links in the DOM are tested. 2. Then, for each link, it will test whether it’s inside a li element. 3. Finally, for all links inside a li element, it will test if it’s inside a .menu element. 4. This is of course, very slow, as it will do all this testing for every single link in the page.
  19. 19. CSS Selector Tuning We can fix this by adding classes to the links in the menu: .menu li .menu-item { color: red } or even better: .menu-item { color: red } We reduce the Depth of Applicability (nesting) by using names with more context
  20. 20. CSS Selector Tuning There are some conventions you can follow in order to write performant and easy to extend CSS without much thought, a good example is BEM, which stands for Block Element Modifier. More on BEM: http://getbem.com/introduction/
  21. 21. Render Blocking Javascript • The browser blocks until all Javascript files have been downloaded and executed • If the Javascript code does not immediately modify the DOM, it can be set as async: <script src=“fonts.js” async></script> • That way, the page will be rendered without waiting for the Javascript file
  22. 22. Webfont Tuning • If you use a webfont, you can remove not-used glyphs and styles to make the font smaller (eg: only english glyphs with light and bold styles) • Some browsers wait until the font is loaded before drawing text, others display a default font and then change it when the font is finished loading • You can use async Javascript to consistently load fonts without blocking the first render
  23. 23. Resources https://developers.google.com/web/fundamentals/performance/?hl=en
  24. 24. – Federico Ramirez That’s it! Questions?

×