- By Jeremy Wagner
- Main takeaway is that it's still an incredibly complex space, and one that a developer has to take control of otherwise poor performance will take control of you. There's a lot of strategies, but I'm still left wondering why focusing on performance is not the default for developers or the platform.
- Wasps!
- It was great to see talking about a number of issues that affect performance
- Thermal Throttling
- Device Capabilities - Nokia 2 Go (Android)
- Developers are ultimately responsible
- The platform is far more capable now - you don't need so many libraries
- Document your architectural choices and hold your projects to them
- Server-first is User-first
- SPA
- Perceptual improvements to performance
- However they have to use lot's of JS to replace infrastrutuce the browser already provides
- Effective Caching in a Service Worker might be able to help with the same perceived performance benefits
- Use effective Caching
- Mentions
immutable, but I think this is only supported in Firefox
- Mentions
- Progressive Enhancement
is- mentions not in Safari- Some interesting code to enhance a form element. Quite liked the submit button demo
- Metrics
- Lab Metrics
- Field Metrics
- FP, FCP, LCP
- CLS
- TTI, FID, TBT
- Tools
- Chrome uses flame charts for tasks, but also has per-frame
- Safari bar chart on a per-frame basis.
- Has a really good explainer of how to use Chrome DevTools for Loading Performance, Runtime Performance and how to test on devices
- Responsible feature delivery
- You should be able to reply in
importsyntax and function - Enables good code-splitting and useful for selectively loading polyfills
- Resource hints
- Add to header or head for critical JS so we get a headstart
- Save-Data header
- Understand your users might have it set and respond appropriately, can either think about it on the server or the client.
- Service Worker, navigationPreload can help massively improve performance (theres a chart with interesting data)
- You should be able to reply in
- Tools
- Transpilers Bundlers - be careful can add significant code that you might not have been aware of, but they can have a postivie impact by helping you split code and compress etc.
- Understand your users browsers and you can make better decisions.
- Use the browser feature as much as possible, HTML and CSS
- Oberserver API's to react when the user does something - reaches a certain point, then load more code etc.
- Think about Idle time and do things then, can help stop jank in user interactions.
- 3rd Party JS
- Can be very bad. Developers should take more control.
- Can lead on to a lot of non-performant related issues, security etc.
I lead the Chrome Developer Relations team at Google.
We want people to have the best experience possible on the web without having to install a native app or produce content in a walled garden.
Our team tries to make it easier for developers to build on the web by supporting every Chrome release, creating great content to support developers on web.dev, contributing to MDN, helping to improve browser compatibility, and some of the best developer tools like Lighthouse, Workbox, Squoosh to name just a few.
