Getting Started with Web Performance

In this article, we will explain critical speed concepts and strategies: what web performance is, why it matters, which metrics to focus on, and how to monitor your site. Understanding these ideas will empower you to start the journey in optimising the speed of your sites and applications with confidence.

What is web performance (site speed)?#

On a high-level, site speed is the speed in which requested content is downloaded, rendered and ready to be interacted with. That time is quantified through various speed metrics, which we’ll cover shortly.

What makes speed so complex is that what we deem fast through observing the metrics alone might not accurately portray the experience of our users — which is why we talk about objective (measurable by metrics) and subjective (perceivable by people) speed. The latter is also known as perceived performance, and shaping it is its own discipline.

Site speed is continually balancing between improving key metrics and testing our assumptions with people using our software.

While site speed primarily manifests itself in the front-end (through interacting with interfaces), optimisations in that space span over not only HTML, CSS or JavaScript. Sometimes, improving speed means optimising database queries, reworking app internals (especially in the case of mobile apps) or tweaking the hosting and CDN pipelines.

Speed doesn’t have to be specific to development. You can go as far as to define speed as one of your product principles — how easy and fast is the user able to achieve their goals?

What does site speed affect?#

Poor speed has a far-reaching impact on not only user experience and accessibility, but also business growth, the ability to advertise, and the ability to market your products.

Organisations that invest in speed improvements observe significant reductions in bounce rates, increases in traffic, engagement, conversion and, consequently, revenue. The evidence is consistent across industries:

When 1 second of delay can cost up to 30% of conversion, performance becomes too costly to ignore.

The user experience impact of poor speed is quantifiable. Mobile users routinely abandon pages that fail to load within a few seconds, and our perception is unforgiving — after one second, our flow of thought is interrupted, and by ten, we’re distracted from the task we were trying to complete.

Google’s search ranking algorithm penalises slow sites. Core Web Vitals became a confirmed ranking factor in June 2021, and the data Google evaluates comes from real Chrome users. That means your speed work isn’t only about user experience; it’s about visibility. If you and a direct competitor publish equally great content, performance becomes the tiebreaker.

Slow speed is a design vector that directly reflects on your brand: its trustworthiness, its craft, and its quality. If you’re still building the internal case, our guide on how to convince your boss about performance is a useful place to start.

What are the most important speed metrics?#

Dozens of speed metrics exist, but for a primer there is one set worth knowing first: the Core Web Vitals. Google introduced them to surface a small, focused group of measurements that quantify the qualities of a fast experience: loading, interactivity, and visual stability.

• Largest Contentful Paint (LCP) measures loading. It marks the moment the largest visible element on the page is rendered.
• Interaction to Next Paint (INP) measures interactivity. It captures how long the page takes to respond after user input, and considers every interaction during a visit, not just the first.
• Cumulative Layout Shift (CLS) measures visual stability. It quantifies how much content jumps around as the page loads.

These are the recommended thresholds to aim for:

Crucially, the Core Web Vitals that Google uses for ranking are evaluated using field data: measurements taken from real Chrome users, not lab tests.

As you progress, supplementary metrics like Total Blocking Time, Time to First Byte, First Contentful Paint, and the Lighthouse Performance Score help diagnose what’s causing your Core Web Vitals to lag. For a deeper treatment of Core Web Vitals themselves, see our complete guide; for the wider landscape, see our metrics reference.

Lab data vs field data#

Two phrases come up constantly in performance work, and confusing them will send you optimising the wrong numbers.

Lab data comes from controlled tests run on a simulated device in a fixed environment: same machine, same network, same location, every time. Tools like Lighthouse and WebPageTest produce lab data. Because the conditions never vary, lab results are reproducible: when a metric changes, it’s because something in your code changed.

Field data (also called Real User Monitoring, or RUM) comes from actual visitors using your site under real-world conditions: their devices, their networks, their geography, their browser extensions. Google’s Chrome User Experience Report (CrUX) is a public dataset of field data from Chrome users who have opted in, refreshed daily over a trailing 28-day window.

Lab and field data routinely disagree, and that’s expected. A page can score beautifully in Lighthouse on your fast development machine and still fail INP in the field, because most of your visitors are on slower devices, weaker networks, or running third-party scripts your lab test never loaded.

Use lab tools to find causes. Use field data to judge success.

This is the single most important mental model in modern performance work. Lab tools tell you why something is slow; field data tells you who is affected, and how much. You need both. For more on the pitfalls of conflating the two, see our writeup of the common mistakes in tracking site speed.

What are the biggest speed offenders?#

Significant problems will inevitably depend on your context, but there are types of assets and specific areas that cause most speed headaches.

JavaScript is responsible for the vast majority of speed issues we see. According to the 2025 Web Almanac, the median mobile page now transfers 646 KB of JavaScript. That’s the compressed figure. Uncompressed, parsed and executed, the cost on a mid-range mobile device is many times higher in time and battery than the transfer alone suggests.

What often gets missed when analysing script is that the uncompressed size is typically 2–3× larger than the optimised package, usually sent in a single file that has to be parsed before anything else can happen. With size comes the hefty price of execution times that worsen with slower networks and devices.

Avoiding long-running tasks and blocking the JavaScript main thread is one of the most critical speed strategies to employ.

When talking about script, it’s important to mention the impact of third party resources. External script is harder to control and often goes unoptimised as developers defer responsibility to service providers. When the majority of sites serve dozens of external scripts, their impact cannot be ignored.

We can be effective at managing external script by adopting progressive loading strategies. Only download and execute what’s relevant for a given customer context: a chat widget, for instance, does not need to load before someone shows an intent to use it.

Appropriate management and prioritisation of critical requests is another area that can make or break the speed of your sites. With the power to direct how browsers fetch assets through priority hints, we can ensure essential assets are available in time to provide a speedy rendering experience. For a wider survey, our piece on the causes of slow websites catalogues the patterns we encounter most.

How to monitor performance: CrUX, RUM, and Synthetic#

Choosing the right monitoring approach is a question of which combination, not which tool. Each of the three established approaches answers a different question, and a serious performance practice uses all three.

CrUX — what Google sees#

The Chrome User Experience Report is Google’s public dataset of field data from real Chrome users, refreshed daily over a trailing 28-day window. There’s nothing to instrument: any public site with sufficient traffic has CrUX data, and that data is exactly what Google uses to evaluate Core Web Vitals for ranking.

CrUX is best for SEO accuracy, competitor benchmarking, and monitoring sites you don’t own. It has limits: a traffic threshold is required, it’s Chrome-only and excludes iOS, and the data is aggregated rather than per-session. But for understanding where you stand with Google, nothing else compares.

Real User Monitoring (RUM) — what your visitors experience#

RUM captures Core Web Vitals and UX signals from live browser sessions on your site, via a lightweight script in your <head>. Where CrUX gives you aggregate field data, RUM gives you depth: the specific DOM elements dragging down your metrics, segmented by country, device, browser, page, or any URL pattern you care about.

RUM is best for the actionable, hands-on work of performance optimisation. It shows you which image is slow, which button has bad INP, which element shifted — across every visitor, not just the Chrome users CrUX covers. For a longer treatment, see our piece on real user monitoring.

Synthetic monitoring — controlled, reproducible tests#

Synthetic monitoring runs automated browser tests from fixed locations and devices, on a schedule or on-demand. Because the conditions are fixed, the results are reproducible. When a metric moves, you know your code changed, not the world around it.

Synthetic is best for catching regressions before they ship: CI/CD checks, pull request reviews, performance budgets, deploy-time alerts, and deep diagnostics like render waterfalls, long task analysis, and third-party impact reports. For a deeper look, see Synthetic monitoring.

How the three compare#

Calibre gives you all three on every plan, because no single data source can answer every question.

Hopefully, you’ve now got enough grounding to confidently start monitoring and improving the experience of your products. The most important habit to build is to never depend on a single data source. Pick the right one for each question you’re trying to answer.

If you’d like to see where your site stands right now, our free Core Web Vitals Test will give you a CrUX-based assessment in a few seconds. Or start a free Calibre trial to get CrUX, RUM, and Synthetic across every page you care about.