$30 off During Our Annual Pro Sale. View Details »

Diving Deep Into Performance Optimization

Diving Deep Into Performance Optimization

The fundamentals to optimize performance of web applications.

Ahmad Alfy

March 20, 2019
Tweet

More Decks by Ahmad Alfy

Other Decks in Programming

Transcript

  1. • My name is Ahmad El-Alfy. • I wrote my

    first HTML document nearly 20 years ago. • Development head and front-end developer at • Facebook Developers Circle Cairo Lead. • Organizer at EgyptJS • Web standards and Accessibility fanatic. @ahmadalfy
  2. We’re Hiring … as usual :) [email protected] Front-end developers Backend

    Developers (PHP/Rails) Quality Control Engineers Mobile developers
  3. A little back story • We started offering a new

    service we call CTO as a service. • Part of my job was evaluating and profiling a lot of applications and products developed by others. I quickly fell in love with performance audits and investigations.
  4. Agenda • Setting up performance budget • Fundamentals to understand

    performance optimization • Network inside the browser • How the browsers work • Different tools we use to identify problems • Techniques
  5. What metrics we can use? • DOMContentLoaded ? • window.onload

    ? • Frames Per Second ? • Jank ? Layout Thrashing ? • First Pain ?
  6. Our focus primarily was on how much bytes we are

    shipping down the wire and how many requests we are making
  7. The RAIL performance goals Touch to paint
 < 100 ms

    Touch to move
 < 16 ms Each frame completes in
 < 16 ms Main thread JS work complete
 < 50 ms / chunk Ready to use
 < 1000 ms https://developers.google.com/web/fundamentals/performance/rail#ux
  8. HTTP 1.1 • It’s a 20 years old protocol that

    we’re still using • It suffers from a lot of problems like latency and limitations on transfer size and number of requests. • BUT We were able to overcome that
  9. CSS • While downloading CSS files, rendering in the web

    page is completely blocked. This is because of a phenomenon called “Progressive Rendering”. Without it, you will see content shifting and changing their style while the assets are being downloaded. • Inline CSS is an exception, it will render immediately after loading.
  10. Images • Images in the HTML is downloaded according to

    the specs: • Images in CSS will be downloaded if it is a part of the render tree
  11. Fonts • Font files will only be downloaded if an

    element uses a font that is a part of the render tree and contain text. • This results in the phenomena we call Flash of Unstyled Text and Flash of Invisible Text
  12. Lighthouse A relatively new tool that replaced the de facto

    standard Page Speed Insights. Available in Google Chrome under the tab “Audit” in the DevTools. You can use it to emulate slower network connection or a slow CPU. Available as a command line interface.
  13. Bro Tip: use the CLI • Run much faster than

    the one in the DevTools, can run in headless mode as well. • Isn’t affected by the extensions you have on your Chrome setup. • Save the results in an HTML document with the exact time, date and version of the lighthouse API. • Can be integrated with your CI.
  14. The report • Images • Origins • Render blocking resources

    • Critical path requests • Text visibility • Main thread work • Cache policy • DOM Size
  15. Images — cont • Don’t ever use an animated gif,

    change it to a video. • Gifs consume more memory from the browser and they have bigger file size than an equivalent movie.
  16. Images — cont • Start using WebP NOW • Relatively

    new format, invented by Google. It offers 30% compression over the other formats.
  17. Images — cont • LAZY LOAD EVERYTHING • It is

    a term commonly used to describe a technique where we stop image loading until it is visible in the user’s viewport. • It is used heavily in listing to: • Improve user experience • Save the bandwidth
  18. Origins Once the browser find a resource located on another

    origin, it will attempt to open a TCP connection to that new origin to retrieve the data. This technique works by telling the browser ahead that it needs to connect to the following list of origins so that when the browser react the request, most of the handshaking, DNS lookup and the other network stuff have been taken care of
  19. Render blocking requests This is because CSS and JavaScript both

    block the main thread while downloading. The old practice was to move the stylesheet to the top and move the scripts to the bottom. The new recommendation is to inline the CSS used for the critical part (above the fold) and move everything else to the bottom. Scripts should also use the attribute defer or async.
  20. Text visibility FOIT block the user for sometime till the

    font is downloaded or it pass the timeout phase of the font loading. We can control the behavior of the font using the property font-display to eliminate the font swapping period and always use a fallback font.
  21. Cache Policy Having a proper cache policy significantly improve subsequent

    visits load. The problem usually arise from third party scripts that have short cache lifetime by default (like GTM, GA … etc) We can always rely on cache busting mechanisms to invalidate the cache
  22. DOM size Google recommends having less than 1500 DOM node.

    Problems usually arise in: • Huge content websites with significant DOM nodes • Using inline SVGs • Serving content for both mobile and desktop and using display none to hide nodes on any platform
  23. Working with videos • Videos should be lazy loaded as

    well and should be properly sized and encoded • If a video is used for presentation only, test the internet connection speed and remove it if it isn’t loading
  24. let videoLoad = new Promise((resolve) => { video.addEventListener('canplaythrough', () =>

    { resolve('can play'); }); }); let videoTimeout = new Promise((resolve) => { setTimeout(() => { resolve('The video timed out.'); }, 2000); }); Promise.race([videoLoad, videoTimeout]).then(data => { if (data === 'can play') { video.play(); setTimeout(() => { video.classList.add('video-loaded'); }, 3000); } else { this.cancelLoad(video); } });
  25. Profiling JavaScript The performance panel can help you profile your

    JavaScript code (identifying the slow parts), detect where the spikes happen (scripting? painting? layout?)
  26. References • Google Chrome Release Notes. • Essential Images Optimization,

    an eBook by Addy Osmani. • Web.Dev; huge resource by Google • Books: High Performance Websites, Even Faster Web Sites. Both by by Steve Souders • Web performance made easy (Google I/O '18)