Website speed optimization services: speed measured on real visitors, without breaking the design.

We wrote this guide for business owners, marketing teams and developers who feel their site loads slowly, or see a red result in PageSpeed Insights, but can’t see where the slowness comes from or what to fix first. The thresholds and mechanisms we describe are based on documentation from web.dev, Chrome for Developers, Google Search Central and MDN; the sources are listed by number below the FAQ. We verified definitions and thresholds against the source as of September 2026. Our own field observations are marked separately under the heading “Expert note”.

Our work on website speed runs in three layers: measurement; loading; interactivity and stability. The eleven sections below walk through these layers and what we look at during setup, in order.

Which metrics are used to assess site speed?

Google assesses site speed with three metrics called Core Web Vitals: LCP measures loading, INP measures interactivity, and CLS measures visual stability.¹ Each metric has three ranges, “good”, “needs improvement” and “poor”; the thresholds PageSpeed Insights uses are:²

A threshold is read from a distribution, not a single measurement: to see that the target is met for most visitors, web.dev recommends looking at the 75th percentile of page loads, treating mobile and desktop separately.¹ The 75th percentile is the point where three quarters of loads are at this value or better; that way, visitors on a slow connection or an old phone don’t get lost in an average.

The “passed” decision is made on this value too. PageSpeed Insights considers the Core Web Vitals assessment passed if the 75th percentile of all three metrics is “good”; if there isn’t enough INP data, “good” LCP and CLS are enough.² The Core Web Vitals report in Search Console, meanwhile, groups URLs with a similar experience and sets the group’s status by its weakest metric; a group with good INP but poor CLS shows as poor in the report.³

Where does field data come from, and which pages show it?

Field data comes from the Chrome UX Report (CrUX) dataset, built from the experience of real Chrome users, and forms only on public pages that get enough visits.⁴ A user’s experience enters CrUX only if they’ve turned on usage statistics reporting, sync their browsing history, haven’t set a sync passphrase and use a supported platform.⁴ Chrome on iOS, Android apps that use WebView, and other Chromium browsers such as Microsoft Edge don’t contribute to the dataset.⁴

On the page side, there are two conditions. The page must be publicly discoverable: a page served with an HTTP status other than 200 after redirects, or marked noindex, doesn’t meet this condition.⁴ The page must also get enough visits; pages and origins (the site as a whole) that don’t pass the threshold aren’t included in the dataset.⁴ PageSpeed Insights reports real users’ experience over the last 28 days; if there isn’t enough data for the site as a whole either, it can’t show any field data.²

Why do PageSpeed Insights scores and field data differ?

A lab test loads the page on a single device under fixed network conditions; field data is the past experience of real users on different devices and connections, so the two give different values.² The lab result in PageSpeed Insights comes from Lighthouse; the mobile test emulates a mid-tier device and a mobile network, and desktop emulates a wired connection.²

The most important consequence of the difference is in INP. Tools such as Lighthouse that load the page in a simulated environment without a user can’t measure INP, because there’s no user input; Total Blocking Time (TBT), which can be measured in the lab, is a proxy for INP.¹

Do Core Web Vitals affect Google rankings?

It does, but it isn’t decisive on its own: Google writes that Core Web Vitals are used by its ranking systems, and that there’s no single signal for page experience.⁵ According to the same document, Google Search tries to show the most relevant content even if the page experience is poor.⁵ Getting good results in Search Console’s Core Web Vitals report or in third-party tools doesn’t mean a page will rank at the top on Google either.⁵

That’s why we justify speed work by the experience visitors get, not by a ranking promise. If search visibility is the goal, content, crawling and indexing are handled together; we cover that side on our SEO consulting page.

What parts make up LCP?

LCP is the time from when the user starts opening the page to when the largest image or text block in the viewport is rendered, and it breaks down into four subparts.⁶ web.dev also suggests a share for each of these parts:⁶

The first part, TTFB, covers redirect time, starting a service worker if there is one, the DNS lookup, connection and TLS setup, and the request, up to when the first byte of the response arrives.⁷ TTFB isn’t a Core Web Vitals metric, but it comes before FCP (First Contentful Paint) and LCP; time lost on the server is reflected in both.⁷ web.dev gives 0.8 seconds or less as the target for most sites and considers anything over 1.8 seconds poor.⁷ That’s why we read TTFB not on its own but by its share within LCP.

How are the server response, caching and CDN set up?

HTML is served with a cache that’s revalidated on every use, versioned static files with long-lived caching, and, where possible, through a CDN (content delivery network) close to the visitor. web.dev recommends using a CDN to bring the server geographically closer to the user.⁶ When resources are served with an efficient cache-control policy, a visitor who requests the same resource a second time gets the file from cache.⁶

We set caching rules by file type. In the cache busting method MDN describes, a file’s URL changes when its content changes, so the file can be kept in cache for a long time.⁸ For versioned CSS, JavaScript and images, MDN’s example is a one-year max-age with the immutable directive; HTML, whose URL stays the same, is revalidated with the server on every use with no-cache.⁸ MDN also writes that unnecessary use of no-store, which never stores the response, loses benefits such as the browser’s back/forward cache (bfcache).⁸

How are images and fonts prepared?

The LCP image is discovered early in the HTML and downloaded with priority, at the right size and in a modern format; icons are in SVG, and fonts load only the weights that are needed. web.dev writes that the LCP image should never be lazy-loaded, as this always causes an unnecessary load delay and worsens LCP.⁶ For an image likely to be the LCP element, it recommends the fetchpriority=”high” attribute, and to shorten download time, serving the image at the right size, using a modern format and compressing it.⁶ Even when the image has downloaded, rendering can be delayed: stylesheets still loading in the <head> or synchronous scripts can block rendering of the whole page.⁶

On formats, MDN recommends WebP or AVIF for raster (pixel-based) images, as they generally compress better than PNG, JPEG and GIF.⁹ Lossy WebP files are on average 25–35% smaller than JPEGs at visually similar compression levels.⁹ When using AVIF, fallbacks to formats with wider browser support should be provided with the <picture> element.⁹ Icons and logos stay vector: MDN writes that most icons have a vector version, and to prefer the SVG version where possible.⁹

1. LCP image: we find which element is the LCP on a template, separately on mobile and desktop; we make that image directly visible in the HTML, take it out of lazy loading and give it fetchpriority=”high”.
2. Format and size: we convert photos to WebP or AVIF and serve them with srcset to match the size on screen; we keep icons, logos and illustrations in SVG.
3. Offscreen images: we lazy-load images and iframes below the first screen, and give all of them width and height.
4. Fonts: we load only the weights in use, preload the font on the first screen, and choose the font-display value by measuring layout shift.

What does INP measure, and how is interactivity sped up?

INP measures how quickly a page responds overall to user interactions throughout a visit; the interactions measured are mouse clicks, taps on a touchscreen and key presses on a physical or on-screen keyboard.¹⁰ Hovering, zooming and scrolling don’t count.¹⁰ According to Chrome usage data, 90% of a user’s time on a page is spent after it loads; so responsiveness after loading matters as much as loading speed.¹⁰ On most sites, the slowest interaction is reported as INP; on pages with many interactions, the single highest one is ignored for every 50 interactions.¹⁰

INP is the successor to FID (First Input Delay) and replaced it as a Core Web Vitals metric on 12 March 2024; Google had announced that FID would be removed from Search Console that day, with a six-month transition period for other tools.¹⁰¹¹

The duration of an interaction has three phases: input delay, until the first callback is processed; processing time, during which all callbacks run; and presentation delay, from when the callbacks finish until the next frame reaches the screen.¹⁰ In the field, we see that what stretches these three phases is most often JavaScript keeping the main thread busy for a long time.

During setup, we find the page types with poor INP from field data, reproduce the most frequent interactions (menu, filters, add to cart, forms) in the lab, and pull out long tasks in a performance recording. We remove unused and duplicate tags in the tag manager, and run non-essential ones after the page has loaded. The fix is usually not deleting a script, but splitting up its work and changing when it runs.

How is layout shift (CLS) prevented?

CLS is prevented by reserving space in the initial layout for every element that loads later; web.dev lists the most common causes of poor CLS as images without dimensions, ads, embeds and iframes without dimensions, dynamically injected content and web fonts.¹² Because modern browsers calculate an image’s default aspect ratio from its width and height attributes, setting these two attributes prevents shifting.¹² Reserving space in the initial layout for late-loading content does the same job.¹²

For fonts, font-display: optional can prevent a relayout, because it uses the web font only if it’s ready at initial layout; loading critical fonts as early as possible with <link rel=preload> is also recommended.¹² In animations, composited transforms such as translate don’t affect other elements, so they don’t count toward CLS.¹² Shifts within 500 milliseconds of user input aren’t added to CLS either; that’s why a panel that opens when a button is pressed isn’t a problem, while content pushed down on its own is.¹²

What does a speed analysis show, and what does it get you?

A useful speed analysis isn’t a single score; it gives the name and position on the page of the element dragging the score down: which element is delaying the Largest Contentful Paint (LCP), which block is shifting the page (CLS), and how much time each fix will save. The Speed screen in markention app, where we monitor site speed, answers these questions in one view; the screenshot below was taken from the dashboard, with sample data.

On the left are the lab measurement’s metrics: First Contentful Paint, Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift and Speed Index. These values come from a single test on an emulated device and a throttled network, so they’re for diagnosis.² On the right, the full-page screenshot captured in Google’s measurement opens in a phone frame. The blue frame shows the LCP element and when it was rendered, the orange frame the shifting block and its shift score; tapping the LCP or CLS chip keeps only that metric’s markers and lists only the related audits below. Opportunities are sorted by estimated savings, and the loading filmstrip shows how the page fills in second by second.

What this view adds to the work:

• The right target: instead of “the site is slow”, you can say “the cover image on the home page renders at 4.1 seconds”; the element to fix is clear by name and position.
• Order: because opportunities are sorted by estimated savings, the work that saves the most time without putting the design at risk is done first.
• Template-level fixes: one example each of the home page, service, blog, product, category and campaign pages is measured separately; a problem in a template is fixed once and verified on every page that uses that template.
• Monitoring with proof: the measurement repeats automatically once a week; the measurement history shows the lab result side by side with the 75th percentile of real user data.¹ If a tag or plugin added later slows the site down, it shows up in the next measurement.

The values in the example are illustrative; in real work we set up the same screen with your page types and track how the fix is reflected in field data as the 28-day window fills.⁴

How do our website speed optimization services work in the first 30 days?

The job of the first 30 days isn’t to change every page at once; it’s to fix the bottleneck on the template that affects the most visitors without breaking the design, and start measuring the effect. We proceed in this order.

1. Week 1 · Measurement: mobile and desktop field data for each page type is read; for pages without data, lab measurement and, if needed, our own measurement script are set up.
2. Week 2 · Diagnosis: on each page type, the LCP element, the share of each subpart, long tasks, tags and shifting elements are pulled out; findings are reported in writing in order of impact and risk.
3. Week 3 · Fixes: server, cache, image, font and tag fixes are made in a test environment, compared with screenshots and put live.
4. Week 4 · First reading: lab results are tracked right away, and field data as the 28-day window fills; next month’s plan comes out of it.

Validation started in Search Console to confirm a fix runs for 28 days; at the end of the first month you see the start of the change in field data, not all of it.³ If you’d like to measure the effect of speed on conversions with an experiment, we cover that side on our CRO consulting page.

Speed plugin, server upgrade or speed optimization service: what’s the difference?

There are three common answers to “how do I make my site faster?”. All three can work; the difference is whether they find the actual bottleneck.

How should you choose a website speed optimization agency?

Speed proposals often arrive with a PageSpeed score attached. When comparing them, look at these points before the score:

1. Data source: does the report state separately whether each figure comes from the lab or from real visitors’ field data?
2. Design safeguard: how is it confirmed, with before and after screenshots, that the design and icons stay the same?
3. Rollback: is every change documented, and can it be rolled back if needed?
4. Tracking and consent: how are conversion tracking and cookie consent protected while tags are reorganized?
5. Access: which access is requested, and is it removed when the work ends?
6. Score promises: a promise of “100 on PageSpeed” or of rankings skips over the fact that lab scores move from test to test and that rankings don’t depend on a single signal.

What determines website speed optimization pricing?

The cost of speed work depends less on the size of the site than on where the bottlenecks are and how long the work is monitored:

We work out the scope together in the first meeting, then send a written proposal. Third-party fees such as hosting, a CDN or an image conversion service are separate from our fee.

Website speed optimization pricing: estimated ranges

Estimated range, excluding VAT; rows marked “/ month” are monthly, the others are one-off. Scope is confirmed in a written proposal after the first meeting. As of October 2026.

If you’d like to read where your site stands today together, pick a meeting day that suits you below; in the first meeting we settle together which page type to start with.