Performance and Core Web Vitals — a fast web solution
LCP, INP, and CLS — Google's metrics for how a page is actually experienced
Performance is not fine-tuning you add at the end — it's part of whether a web solution actually works for the user. The regulations for web developer education therefore also require that students can optimise a web-based solution for technical performance. Google has collected the most important metrics for experienced performance in three metrics called Core Web Vitals, which are both used to assess user experience and are included as a signal in the search engine's ranking.
§The three goals — and the limits of 'good'
Each metric has a threshold for 'good', a threshold for 'poor', and a range called 'needs improvement'. Google assesses a page based on the 75th percentile of real visits — that is, at least three out of four visits must hit the good threshold before the page as a whole is considered good on that metric.
| Target | What it measures | Good | Poor. |
|---|---|---|---|
| LCP (Largest Contentful Paint) | How fast the largest, visible content is displayed | 2.5 seconds or less | Over 4 seconds |
| INP (Interaction to Next Paint) | How fast the page responds visually to user action | 200 milliseconds or less | Over 500 milliseconds |
| CLS (Cumulative Layout Shift) | How much visible content moves unexpectedly during loading | 0.1 or less | Over 0,25 |
§LCP — important content must be shown quickly
LCP measures when the largest and most prominent element in the visible area is fully loaded — often a hero image or a heading. The most common causes of poor LCP are heavy, unoptimized images, a slow server, and resources that block the page from rendering while they load. Optimize images in size and format, let critical resources load early, and avoid having the most important content wait for things the user isn't looking at yet.
§INP – the response to a click
INP replaced the previous goal FID in 2024 and looks more broadly at responsiveness: it measures the entire flow from a user action until the page has visually responded, throughout the visit, not just on first interaction. Heavy JavaScript tasks that block the main thread are the typical culprit – a button that doesn't respond immediately because the browser is busy with something else. The solution is to break large tasks into smaller chunks and avoid unnecessarily heavy work, especially when the user interacts.
§CLS — when content jumps before the user's eyes
CLS occurs when visible content moves without the user doing anything — the classic example is an image without specified dimensions that only reserves its space once it's fully loaded and pushes the text below it down. Another example is content that suddenly appears at the top of the page while you're reading or clicking. Reserve space for images and embedded content in advance and avoid inserting new content over what the user is already looking at.
- 01Optimize and scale images to the size they are actually displayed at
- 02Let non-critical JavaScript and styling be fetched without blocking the most important content
- 03Divide heavy JavaScript work into smaller pieces
- 04Always specify width and height on images and embedded content
- 05Cache things that don't change often
“The user does not judge your code — the user judges how quickly the page feels ready to use.”
— Common teaching principle in web performance