Chrome Dev Summit - Performance summary
#perfmatters: Tooling techniques for the performance ninja
Knowing your way around your development tools is key to becoming a performance expert. Colt stepped through the three pillars of performance: network, compute and render, providing a tour of the key problem in each area and the tools available for finding and eradicating them.
- You can now profile Chrome on Android with the DevTools you know and love from desktop.
- The iteration loop for performance work is: gather data, achieve insight, take action.
- Prioritize assets that are on the critical rendering path for your pages.
- Avoid painting; it’s super expensive.
- Avoid memory churn and executing code during critical times in your app.
#perfmatters: Optimizing network performance
Network and latency typically accounts for 70% of a site’s total page load time. That’s a large percentage, but it also means that any improvements you make there will reap huge benefits for your users. In this talk Ilya stepped through recent changes in Chrome that will improve loading time, as well as a few changes you can make in your environment to help keep network load to an absolute minimum.
- Chrome M27 has a new and improved resource scheduler.
- Chrome M28 has made SPDY sites (even) faster.
- Chrome’s simple cache has received an overhaul.
- SPDY / HTTP/2.0 offer huge transfer speed improvements. There are mature SPDY modules available for nginx, Apache and Jetty (to name just three).
- QUIC is a new and experimental protocol built on top of UDP; it’s early days but however it works out users will win.
#perfmatters: 60fps layout and rendering
Hitting 60fps in your projects directly correlates to user engagement and is crucial to its success. In this talk Nat and Tom talked about Chrome’s rendering pipeline, some common causes of dropped frames and how to avoid them.
- Painting is extremely expensive. A Paint Storm is where you unnecessarily repeat expensive paint work.
- Layers are used to cache painted elements.
- Input handlers (touch and mousewheel listeners) can kill responsiveness; avoid them if you can. Where you can’t keep them to a minimum.
#perfmatters: Instant mobile web apps
- Prioritize visible content.
- Load scripts asynchronously.
- Minimize render-blocking CSS; deliver only the styles needed to display the initial viewport, then deliver the rest.
- Large data URIs inlined in render-blocking CSS are harmful for render performance; they are blocking resources where image URLs are non-blocking.