Performance 2
Tools
Calibre, Speedcurve, Bundlesize, Webpack Performance Budgets
Synthetic Testing:
Chrome: network emulation, CPU throttling
Chrome: code coverage which shows which code blocks were executed and not (opportunity for lazy loading)
Chrome: Use network request blocking for 3rd party domains to see their impact on critical path loading.
Lighthouse
WebPageTest including integration with Git Hooks
Real phone and network testing
Headers
Minifying / Optimizing
Gzip / Brotli
Metrics
While some metrics may seem interesting, they may tell us noting about UX. These include: onLoad, onDomContentLoaded, and Speed Index.
Good metrics are stable, explain something, and cannot be manipulated. Include: First Paint, Visual Complete, TTI.
Speed Index
"Perceptual Speed Index is a page load performance metric that shows you how quickly the contents of a page are visibly populated." It's subjective, high level, user-perceived performance without tied to seconds.
Time to Interactive (TTI)
A general goal is to have TTI under 5 seconds on an average mobile device over 3G, and under 2 seconds for repeat-loading after installing/activating a Service Worker
Real User Metrics
Analytics Programs
Google Analytics, etc.
Public Datasets
Chrome User Experience Report which provides stats collected by Chrome users who visit 10,000 selected websites. For each, it identifies device type, effective connection type, and info from the Paint API, domContentLoaded, and onload events with histograms.
HTTPArchive - Queryable archive of response bodies, Google Lighthouse reports, performance metrics, JS usage statistics.
Patterns
PRPL
From Google...
PRPL is a pattern for structuring and serving Progressive Web Apps (PWAs), with an emphasis on the performance of app delivery and launch. It stands for:
Push critical resources for the initial URL route.
Render initial route.
Pre-cache remaining routes.
Lazy-load and create remaining routes on demand.
Beyond targeting the fundamental goals and standards of PWAs, PRPL strives to optimize for:
Minimum time-to-interactive
Especially on first use (regardless of entry point)
Especially on real-world mobile devices
Maximum caching efficiency, especially over time as updates are released
Simplicity of development and deployment
Shared Ownership
Ensuring all staff members are responsible for performance. Performance budgets can guide meeting goals.
Push the minimal code for the initial route Render route and get interactive Pre-cache using Service Workers Lazy-load async (split) routes.
Uses aggressive code-splitting, and used by modern toolkits.
Other Areas
Modules
Do browsers need polyfills to support ES2015 Modules? They add weight.
Service Workers
off-main thread fetch, script streaming
Libs like Workbox that make dev easier
From Chrome Dev Summit 2017 slide on Pinterest:
Started: Runtime caching async JS chunks (for V8 bytecode cache) Precaching vendor & entry chunks Precaching most used routes Generating a SW for each country market locale
Today: Cache all JS/CSS cache-first Cache the App Shell Precache bundle loaded by the shell Webpack runtime, vendor, entry Named chunks to cache async routes
Navigation Architecture
Chrome PlzNavigate allows: move all navigation-related callbacks into the browser process
Last updated