- retain users*
- increase conversion numbers (sign-ups, sales)**
- create delightful user experience
*DoubleClick by Google found 53% of mobile visits abandoned if a page took > 3 s to load
**Pinterest increased traffic / sign-ups by 15% when perceived wait time reduced by 40%.
why?
a set of limits on metrics that affect site performance
Good starting points*:
- Performance Score > 80 on Lighthouse
*for majority market of mid-range devices and 3G-like connectivity
a set of limits on metrics that affect site performance
Good starting points:
- Performance Score > 80 on Lighthouse
- Critical render path resources < 170KB*
*critical for mobile devices for JS bundle downloading
a set of limits on metrics that affect site performance
Good starting points:
- Performance Score > 80 on Lighthouse
- Critical render path resources < 170KB
- Time To Interactive (TTI) < 5s*
* < 3 s according to user drop-off stats
a set of limits on metrics that affect site performance
sequence of steps the browser goes through to convert textual resource into pixels on screen
Browser:
- queues input as tasks on the main thread
- Tasks executed one by one (synchronously, thread-blocking)
- Un-optimised steps block main thread and delay TTI
2.
3.
4.
...to pixels on screen
Why
from textual resources...
downloads...20 - 30% of TTI
1.
Reduce across all textual resources:
- JS, HTML, CSS,
- Images, Fonts
- JSON response for native
How
How?
How
avoid, replace or remove large inline scripts of over 1KB
How
1. remove unused code (WebPack/ Parcel settings, Tree shaking...)
2. carefully consider node_modules:
- copy code that is used instead of using entire module
- switch to smaller npm modules
Why
- Long task - JS code > 50ms that monopolise Browser's Main Thread
- Causes UI 'Freezes' and delays TTI
How
- Code Splitting - cutting up single JS bundle into smaller "chunks"
- use Dynamic imports and Suspense Rendering
Why
- the largest bloat to a page
- tiniest optimisations go a long way
How
minify SVGs, PNGs using sites like tinyPNG.com or APIs such as imgX
time until user thinks the app is loaded
Is it happening?
is it useful?
Can I use it?
time until user thinks the app is loaded
Is it happening?
is it useful?
Can I use it?
- Ensure screen shows something while loading:
- skeletons, loaders, navigation
- keep an eye on Time To FCP and FMP
time until user thinks the app is loaded
Is it happening?
is it useful?
Can I use it?
- Distinguish Hero Elements
- Render them first
- code-split the component if needed
- Ensure screen shows something while loading:
- skeletons, loaders, navigation
- keep an eye on Time To FCP and FMP
time until user thinks the app is loaded
Is it happening?
is it useful?
Can I use it?
- Distinguish Hero Elements
- Render them first
- code-split the component if needed
- Ensure interactivity by not blocking the main thread
- Strive for Time To Interactive < 3s to 5s
- Ensure screen shows something while loading:
- skeletons, loaders, navigation
- keep an eye on Time To FCP and FMP
Ebay - Speed by a Thousand Cuts https://tech.ebayinc.com/engineering/speed-by-a-thousand-cuts/
Incorporate Performance Budgets into the Build
https://web.dev/incorporate-performance-budgets-into-your-build-tools/
Predictive prefetch of static assets
Autosuggest edge caching