Web Performance: Understand and Improve Core Web Vitals

Fast pages are experienced by people as pleasant and rated by search engines as a quality signal. At the same time many misunderstandings are circulating: a perfect test score in the lab says little about the experience of real visitors on real devices, and performance is only one of many signals for rankings. This article explains the metrics that count today, shows where you achieve the most and includes an example from our own site.

The metrics: Core Web Vitals

The Core Web Vitals measure three aspects of user experience. These values count as “good” (as of October 2026):

• LCP (Largest Contentful Paint): when is the largest visible element fully loaded, often a hero image or a large heading? Good: under 2.5 seconds.
• INP (Interaction to Next Paint): how quickly does the page respond to input such as clicks and key presses? Good: under 200 milliseconds. INP replaced the former metric First Input Delay in 2024.
• CLS (Cumulative Layout Shift): do elements jump while loading? Good: under 0.1.

In addition, server response time (TTFB) is useful: a value of at most about 0.8 seconds counts as good. It is not a Core Web Vital but influences LCP.

Lab data and field data

Lab data (for example Lighthouse) is produced in a controlled environment: reproducible, good for finding causes. Field data comes from real visitors on their devices and connections, for example from the Chrome User Experience Report, Google Search Console (the “Core Web Vitals” report) or your own monitoring. It often differs. If you only optimize the Lighthouse score, you may not solve the problem visitors really have. New websites have no field data at first because there are too few visits.

Where you achieve the most

Images: often the biggest lever. Modern formats (WebP, AVIF), suitable sizes instead of huge originals, set width and height, load images below the visible area later (loading="lazy"), but do not delay the most important image at the top and prioritize it where needed.

Fonts: load only the font styles you need. With preload, critical fonts load earlier, and a fallback font with matching metrics prevents text from jumping when the web font loads.

CSS and JavaScript: remove what is unnecessary, load scripts with defer or async, split large bundles and include third-party scripts (tracking, chat, videos) only if they are worth it. Every script costs time.

Server and delivery: enable compression (gzip or Brotli), use caching with long lifetimes for files with a hash in the name and short ones for HTML. A CDN can shorten the distance to visitors. Statically generated pages are often faster than any page recalculated on every request.

Order: start with measurement, then with whatever costs the most time. Usually that is images, then fonts and scripts, last fine-tuning.

An example from our own site

On one of our pages with many images, a test with a throttled mobile connection showed a layout shift (CLS 0.14, just above the threshold). The cause was the font, which loaded after the first paint and made the text re-wrap. The fix had two parts: preload the font files early and define a fallback font with the same line metrics. Afterward the value was 0. That is a single case, but it shows the principle: measure first, find the cause, then intervene precisely.

Myths

• “A Lighthouse score of 100 means everything is fine.” It only says something about one test run. Check field data too.
• “Performance decides the ranking.” It is one signal among many. Content relevance usually counts more. It does improve user experience and bounce rates, though.
• “One plugin solves everything.” Optimization plugins help but do not replace clean implementation.

Performance checklist

1. Measure Core Web Vitals and TTFB (lab and field).
2. Check images: format, size, dimensions, lazy loading, do not delay the most important image.
3. Fonts: few styles, load early, fallback font with matching metrics.
4. Reduce scripts, review third parties, use defer/async.
5. Set up compression and caching.
6. Look for layout shifts (elements without fixed size, content loaded later).
7. Watch results in Search Console and PageSpeed Insights.
8. Set a performance budget and check it with every change.

Briefly answered

Which metric is most important? That depends on the problem. Usually it is LCP and CLS, for interactive applications also INP.

How often should I measure? After every larger change and regularly in operation, for example monthly in Search Console.

Is it worth it for small websites? Yes. Especially there, images, fonts and scripts can often be improved considerably with little effort.

Conclusion

Good performance comes from measuring, the right levers and maintenance, not from a one-off test score. If you would like support with web development and optimization, you will find our offer under development.