Web Performance
Web performance is the discipline of making a site load, respond, and remain visually stable for real users. It combines delivery, browser rendering, JavaScript work, and measurement so the page feels fast on the devices and networks people actually use.
itWeb development | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic: Web Performance
Web performance is the work of making a page useful, responsive, and steady for the person on the other side of the connection. It is not the small green number you receive from a browser tool, though the number may be trying its best. It is the whole route from request to visible content, then from input to an updated screen.
A page is a relay race with a strong preference for tripping over its own shoelaces. The request reaches an origin or cache. HTML arrives. The browser finds resources, transfers them, runs code, lays out pixels, and eventually agrees that a button may be pressed. A delay at any point can become the delay the reader remembers.
Three Core Web Vitals keep the conversation tied to what people notice. Largest Contentful Paint, or LCP, asks when the largest useful element becomes visible. Interaction to Next Paint, or INP, asks how long an interaction waits before its visual result appears. Cumulative Layout Shift, or CLS, catches content that moves after somebody has already aimed at it. They are loading, responsiveness, and stability wearing sensible name badges.
The surprising part is that one test run cannot settle the matter. Field data comes from real page loads and reveals the outcome across actual devices and connections. Lab data comes from a controlled run and gives you a trace, waterfall, and a repeatable scene of the crime. If they disagree, neither has betrayed you. The disagreement tells you that a route, cache state, device, or network condition still needs a name.
For loading, inspect the gaps from Time to First Byte to First Contentful Paint and then to LCP. For interaction, inspect the main thread and its long tasks. For stability, reserve space for images, video, fonts, and late-arriving widgets before they begin rearranging the furniture. The browser does not regard the button you meant to press as a sentimental object.
Start with the Intro for the full path and the vocabulary. Use the Slides when you need the relationships in one view. Keep the Cheatsheet nearby while reading a trace or waterfall. The Practice tab turns the evidence loop into a repeatable investigation, and the Exercise asks you to prove one improvement without changing the weather, the network, and three unrelated files at once.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://web.dev/articles/vitals
Supports
- Core Web Vitals cover loading, interactivity, and visual stability
- LCP, INP, and CLS are the current stable Core Web Vitals
- Current good thresholds are LCP 2.5 seconds or less, INP 200 milliseconds or less, and CLS 0.1 or less
- Core Web Vitals should be evaluated at the 75th percentile, segmented by mobile and desktop
- Chrome User Experience Report supplies anonymized real-user measurements and powers PageSpeed Insights
- Time to First Byte and First Contentful Paint are diagnostic loading metrics for LCP
- Google introduced Core Web Vitals as a user-experience measurement program in 2020
- https://web.dev/articles/optimize-lcp
Supports
- Field data should guide LCP investigation and lab data helps diagnose the cause
- High Time to First Byte can make a good LCP difficult or impossible
- The Time to First Byte to First Contentful Paint and First Contentful Paint to LCP gaps help diagnose loading delay
- https://web.dev/articles/optimize-inp
Supports
- INP good threshold is 200 milliseconds or less at the 75th percentile
- Field data and RUM help identify slow interactions before lab reproduction
- Interaction phases are input delay, processing duration, and presentation delay
- https://web.dev/articles/cls
Supports
- CLS measures the largest burst of unexpected layout shifts over the page lifecycle
- Missing media dimensions, fonts, and dynamically resizing third-party content can cause layout shifts
- Layout shifts involve visible elements changing position between rendered frames
- https://developer.mozilla.org/en-US/docs/Web/API/Performance_API
Supports
- The Performance API is a group of standards for measuring web application performance
- The performance timeline uses high-precision timestamps and can be observed or sent to analytics
- Performance entries include a name, duration, start time, and type
- https://www.w3.org/TR/navigation-timing-2/
Supports
- Navigation Timing exposes complete timing information for a document navigation
- PerformanceNavigationTiming stores and retrieves high-resolution navigation timing data
- https://www.w3.org/TR/resource-timing/
Supports
- PerformanceResourceTiming provides client-side measurements for fetched resources and their phases
- https://www.w3.org/TR/longtasks/
Supports
- Long Tasks API surfaces tasks that can delay user input
- A long task exceeds 50 milliseconds
- https://github.com/davidsonfellipe/awesome-wpo
Supports
- PageSpeed Insights supplies lab and field Core Web Vitals diagnostics
- WebPageTest supports multi-location real-browser tests, waterfalls, filmstrips, and advanced scenarios
- Lighthouse CI can enforce Core Web Vitals budgets in continuous integration
- web-vitals is a browser library for Core Web Vitals measurement
- https://www.w3.org/2018/09/webperf/
Supports
- The W3C Web Performance Working Group began in 2010
- The working group standardizes browser APIs for measuring application performance
- https://www.w3.org/standards/history/navigation-timing/
Supports
- Navigation Timing became a W3C Recommendation on 17 December 2012
- https://www.w3.org/TR/user-timing-1/
Supports
- User Timing Level 1 became a W3C Recommendation on 12 December 2013
- User Timing defines high-precision application marks and measures
- https://www.w3.org/TR/2013/REC-performance-timeline-20131212/
Supports
- Performance Timeline became a W3C Recommendation in December 2013
- Performance Timeline defines a common PerformanceEntry model
- https://www.w3.org/2014/07/mobile-web-app-state/Overview.pdf
Supports
- Resource Timing was stable and growing in deployment in 2014
- Resource Timing exposes timing hooks for fetched resources
- https://www.rfc-editor.org/rfc/rfc7540
Supports
- HTTP/2 was published as RFC 7540 in May 2015
- HTTP/2 defines a binary framing layer for HTTP semantics
- https://www.w3.org/TR/hr-time-2/
Supports
- High Resolution Time Level 2 became a W3C Recommendation in November 2019
- The specification defines a monotonic clock and time origin for web performance timestamps
- https://web.dev/blog/inp-cwv-march-12
Supports
- INP replaced FID as a Core Web Vital on 12 March 2024
- INP measures responsiveness through the next visual update
- https://www.etsy.com/codeascraft/q1-2015-site-performance-report
Supports
- Etsy used both synthetic monitoring and real-user monitoring in its site performance reporting
- Browser support for Navigation Timing changed the underlying datasets for Etsy RUM measurements
- Etsy observed a worse 95th percentile while a page median did not show an outstanding increase
- https://www.etsy.com/uk/codeascraft/q1-2016-site-performance-report
Supports
- Etsy used synthetic monitoring to cross-check other measurement sets
- Etsy identified third-party resource fetches exceeding a synthetic test timeout
- https://medium.com/pinterest-engineering/driving-user-growth-with-performance-improvements-cfc50dafadd7
Supports
- Pinterest used a pre-rendered HTML experiment with stripped common resources to test mobile web performance
- Pinterest rebuilt shared frontend infrastructure to productionize the experiment's learning
- https://www.debugbear.com/features
Supports
- DebugBear offers scheduled synthetic tests, CrUX data, real-user monitoring, and Lighthouse reports
- https://www.cloudflare.com/
Supports
- Cloudflare provides edge delivery and caching services
- https://www.fastly.com/
Supports
- Fastly provides edge cloud and content delivery services
- https://www.akamai.com/
Supports
- Akamai provides edge delivery services
- https://www.speedcurve.com/
Supports
- SpeedCurve provides synthetic and real-user web performance monitoring
- https://calibreapp.com/
Supports
- Calibre provides web performance monitoring and budget tooling
