Wed Directions remixed - performance

Web Performance - a history tour with 

Fast/slow depends on priorities and what you prioritize for your users

2 main browsers these days: Chromium and Safari webkit (FF is too low) and they have different priorities which you should check tuning against:

1. Chromium: show as much content as quickly as possible, will try to defer non-blocking resource, will prioritize head blocking resources, will try render images progressively
2. Safari: optimize for efficiency and get to end state as quickly as possible; less focus on intermediate state, default layots & paints until everything is ready, prefers to render completed image

phase 1: web server performance. 

In early days of web, Performance focussed on server performance: how quickly does server respond to requests? how does server perform under load? Still important today, Time to First Byte is a good metric to measure.

BE performance is important but not the biggest since most of the time is spent in the browser and rendering. FE is probably 80-90% of time.

phase 2: page load time, time to load all page assets. 

Next the focus came to Page Load time: the time it takes the browser to load all the resources in the html. But this does not measure the User Experience because spas load more and make more requests after the page is loaded. So page load is just part of the User Experience.

phase 3: render based metrics. 

More focus on User Experience. Metric such as First Paint Time (when does user seen content painted). Tools like WebPageTest and SpeedIndex. SpeedIndex scored how quickly content is painted on the screen. Had some limitations but good progress.

phase 4: focus on the complete user experience

When did the user see something to let them know something is happening? when is it painted? when can users interact with the app?

metrics: First Paint, First Meaningful Paint, Time to Interactive

Parsing the javascript and executing can take a significant time, so even server side rendered pages which come down pretty UI complete are still unusable for a period of time. The user is clicking around and nothing happens. Hence the push to measure that Time to Interactivity (not just time to paint) which measure when all the javascript is wired up. But Time to Interactive had a flaw in that it drives teams to focus last long running task. So the focus moved to "long tasks" not just last long task

So we come to google chrome teams "web vitals" which are focussed on 3 experiences that they value

1. is something happening? -> First Contentful Paint and Largest Contentful Paint
2. is it responsive?       -> First Input Delay (FID) and Total Blocking Time (TBT) is the lab equivalent
3. is the page stable?     -> Cumulative Layout Shift (CLS)
•  e.g. happens when ads appear and change page content, or if buttons move and user clicks wrong thing

explanations:

• First Contentful Paint: some useful content appears; first image or content appears
• Largest Contentful Paint: main content painted  
• note: LCP for image waits until img is fully loaded even though at ~50% it may be useful to users; so cross check with film strip
• if you have key LCP images you could pre-load to help speed up if slow
• First Meaningful Paint: main user content has loaded
• Cumulative Layout Shift: still being fine tuned by team but measured in units of viewport shifted; so a 1.0 for Layout Shift means the content moved an entire viewports worth of distance.
• First Input Delay: how much as browser main thread blocked before the browser could service that event? how long was main thread blocked while user tried to interact with the page
• Total Blocking Time (TBT): sums up blocking time over 50ms; how much did I block the main thread after load?