Website speed and Core Web Vitals optimization

What a speed optimization project includes#

The proposal names the templates in scope, which of these deliverables apply, who implements each fix and how it is accepted:

• Field-data baseline per template from CrUX, Search Console and your analytics
• Lab traces of the slowest templates on an emulated mid-range phone with a slowed CPU
• A fix list ranked by visits affected, metric moved and effort
• A third-party script inventory, each tag with an owner and a decision
• Fixes in your code, theme or CMS, or tickets for your developers
• Real-user measurement of LCP, INP and CLS where Google's data is missing
• A before-and-after report from field data

What are good Core Web Vitals scores?#

Google rates three metrics at the 75th percentile of page loads, separately for mobile and desktop. Largest Contentful Paint (LCP), when the main content appears, is good at 2.5 seconds or less and poor above 4 seconds. Interaction to Next Paint (INP), how fast the page responds to input, is good at 200 milliseconds or less and poor above 500. Cumulative Layout Shift (CLS), how much the layout jumps, is good at 0.1 or less and poor above 0.25.

Where your visitors are changes what passes: see Core Web Vitals in Latin America for how the same sites do in the US and Latin America.

INP replaced First Input Delay on 12 March 2024; an audit or plugin that still grades First Input Delay is out of date.

Field data first, lab data second#

We start from what real visitors experienced, then use lab tests to find the cause. Google's field data is the Chrome User Experience Report (CrUX), a 28-day rolling average of visits by eligible Chrome users. Search Console's Core Web Vitals report reads it, groups similar URLs and gives each group the status of its worst metric.

For a benchmark, our free website platform speed report shows how sites on your platform do for real visitors in your market, from the Chrome UX Report, updated monthly.

PageSpeed Insights shows that field data above a Lighthouse test that simulates one mid-tier phone on a mobile network. Lighthouse can't measure INP, since nobody taps the page, and reports Total Blocking Time instead. Lab tests show causes; field data sets priorities.

CrUX covers only Chrome on desktop and Android, so iPhone visitors are missing, and pages below an undisclosed traffic threshold have no data. When those gaps matter, we add real-user measurement to your site; since Safari 26.2, released in December 2025, it can record LCP and INP on iPhones too.

What slows a site down, and how we fix each cause#

The audit names the cause behind each failing metric. web.dev splits LCP into server response, the delay before the browser finds the main image, its download and its rendering, which tells us whether to fix the server, the HTML or the file. Google's guidance is blunt on one point: never lazy-load the LCP image; give it a high fetch priority instead.

Fixes are ranked by the visits they affect and their effort. Deleting an unused tag takes minutes; a page builder that loads the same scripts on every page means rebuilding that template.

Do Core Web Vitals affect Google rankings?#

Yes, but as one signal among many, behind relevance. Google's page experience documentation says "Core Web Vitals are used by our ranking systems", and also that Search shows the most relevant content even when page experience is sub-par. Good scores don't guarantee top positions.

So we sell speed work for your visitors, who can read and act sooner, not as a ranking fix. If rankings are the goal, our technical SEO service starts from the queries, pages and links that weigh more.

Keeping 3D and motion-heavy pages fast#

A 3D page can pass Core Web Vitals if the scene loads after the content. A canvas isn't among the element types LCP considers, so we keep the headline, copy and a poster image in HTML and start the scene once they're on screen. The risk then moves to INP: preparing shaders, textures and models creates long tasks, which we split and test on throttled phones.

We run our own site this way: the dardo.studio home page is a real-time 3D scene, measured with Cloudflare Web Analytics and Google's open-source web-vitals library, without cookies. We read raw rows before changing anything. On 3 October 2026 Cloudflare's 24-hour page load time read 2.2 seconds, but it was the median of only 17 loads, six of them loaded out of sight by Meta's in-app browser, and that metric waits for every image and script, not for what visitors see.

Throttled lab runs found two plain causes: a lossless screenshot phones downloaded at 318 KB, now 81 KB, and session-recording analytics that started before the page finished loading, now after. On fast 4G the emulated phone finished loading in 894 milliseconds instead of 1,476.

Model and texture budgets are in our article on keeping 3D websites fast; building the scene is our interactive 3D websites service.

How the work runs: audit, fixes, then a field-data check#

Each project starts with a baseline and ends with a comparison on the same data, for the templates that carry the most visits or revenue: the home page, a product or service page, an article.

Fixes go to a staging copy before production, or to your developers as tickets. Lab tests show the effect the same day; field data takes longer, because CrUX averages 28 days and Search Console's fix tracking monitors affected URLs for 28 days. We note each release date and compare once the window has rolled over.

The report and measurement setup stay in your accounts, and a website maintenance plan catches regressions from new tags and images after each release.

What moves the price of speed work#

Speed optimization has no published starting price; the audit and the fixes are quoted separately. What moves the quote:

• Templates in scope: each distinct template is traced, not every URL
• Platform: on Shopify, Webflow or a WordPress page builder, some weight can't be removed
• Third-party scripts, each needing its owner's decision
• Design changes, such as replacing a hero video or a font family
• Missing field data, which must be collected before a baseline exists
• Who implements: Dardo, your developers or both

Our project budget ranges and other services' starting prices are on the pricing page.

When speed optimization is the wrong fix#

Speed work fits a site whose content and structure work but whose pages are slow. If the theme or platform is the weight, rebuilding fixes more than tuning: a website redesign or a website migration, for example to Astro, which renders pages to HTML ahead of time. If pages are fast but visitors don't act, choose conversion rate optimization. For a new site, we plan speed into the build through web development instead of auditing it afterwards.

Questions before you choose#

From the blog#

• Core Web Vitals in Latin America: how many sites pass in each country, and why mobile fails (2026 data)

  In September 2026, a third of sites passed Core Web Vitals for mobile visitors in Colombia and Brazil, against 63% in the US. Data by country and what to do.

• How to improve Core Web Vitals: a field-data-first playbook for marketing sites

  Find the failing metric and template in Search Console, fix LCP, INP and CLS by their cause, then confirm the result in field data about 28 days later.