How I Measure Website Speed and Prove Performance

If your website feels slow, it is slow - at least to users and Google. This playbook shows exactly how I measure website speed, turn it into SLAs your team can own, and prove the business impact. No mystery scores. No vanity dashboards. Just clear measurement, tight engineering loops, and changes that hold up in board meetings.

Most speed conversations die in tools. A marketer shows an 82 in Lighthouse and says “we’re good.” Then paid CAC creeps up, organic rankings wobble, and mobile bounce worsens. The gap isn’t that you lack a score. It’s that the score doesn’t reflect what buyers actually feel on your key pages under real-world conditions.

I treat performance like a product KPI: it has a definition, a target, a budget, and a way to forecast impact. That turns speed from an engineering side quest into a commercial lever tied to your pipeline. Your “green score” doesn’t matter if your product pages choke on third-party scripts during peak traffic, or your blog template drags INP over the threshold on mobile.

Here’s the frame: define the few metrics that map to UX and Google’s expectations, measure them from your users (not just your laptop), split by device and template, and run fixed-length sprints that only ship improvements you can measure. That’s it. Simple isn’t easy - but it’s what works.

There are two kinds of performance data: lab (synthetic tests in controlled environments) and field (real user monitoring - RUM - data from devices, networks, and traffic patterns you actually get). Lab is for diagnosis and CI/CD gates. Field is for truth. If I had to pick one, I’d pick field. But together they’re unbeatable.

Lab tests tell you what to fix and keep regressions from shipping. Field data tells you whether users feel the fix and whether Google’s crawl and ranking evaluations will respond over time. When leaders ask “are we fast?” I answer with field percentiles, not a single lab run.

Set the expectation now: you will see variance. Different geos, devices, networks, and routes yield different results. That’s not a bug - that’s reality. Your job is to own the 75th percentile outcomes on your money pages and defend them week over week.

Field data sources I trust

Start with the public truth: Chrome UX Report (CrUX) and Google Search Console’s Core Web Vitals reports. CrUX shows origin- and URL-grouped distributions for LCP, INP, and CLS across mobile and desktop. It’s the closest thing to Google’s “official” view of your field performance.

Layer your own RUM. Use a lightweight web-vitals script to capture LCP, INP, CLS, TTFB, and route/template identifiers, then send them to your analytics or a dedicated RUM backend. Break results down by device class, country, connection type, and page template. You’ll discover that your “average” is a myth; your PDP on budget Android in India is a different website than your homepage on corporate desktop in the UAE.

GA4 is fine for aggregations if you’re careful with sampling and cardinality. If you can, stream to a warehouse (BigQuery or similar) and build a simple Looker/Data Studio dashboard for p75 metrics by template. The key is owning your truth rather than refreshing third-party widgets.

Lab tools I use for diagnosis and CI

Lighthouse (local and CI), WebPageTest, and browser DevTools cover 90% of needs. You’re looking for waterfall timing, main-thread blocking time, LCP element identity, INP interactions, and third-party impact. One-off runs are noisy; run 5–9 iterations and use medians.

In CI, set hard thresholds with Lighthouse CI for performance budgets and block merges when a PR would blow them up. Add route-level tests for your top templates. If you’re on a modern framework (Next.js, Remix, Nuxt), run page-level synthetic tests after build to ensure code-splitting didn’t regress.

Keep lab and field in sync: when field data flags a template slipping over target at p75, reproduce the case in lab with the same device emulation and network shaping. Fix, verify in lab, then watch field trend lines confirm over a week.

Google’s Core Web Vitals are the lingua franca for performance. They also align well with user-perceived experience if you measure them correctly. The ones that move the needle now: LCP (Largest Contentful Paint), INP (Interaction to Next Paint), and CLS (Cumulative Layout Shift). TTFB (Time to First Byte) isn’t a CWV, but it heavily influences LCP and perceived speed.

LCP is the moment the main content renders. Think hero image, headline, or product photo. If LCP is late, your page feels blank even if other stuff loads. INP replaced FID; it measures overall interaction latency. If tapping “Add to Cart” feels mushy, that’s INP talking. CLS is layout jitter - content jumping while ads, fonts, or images load.

These are not engineering trivia. LCP and INP connect directly to bounce and conversion rates because they mirror when users can see and act. CLS is the silent killer of trust. When you commit to CWVs, you’re committing to a better buying experience - not chasing a score.

Targets and SLAs I set with teams

Pragmatic, defensible targets at the 75th percentile (p75), mobile-first:

• LCP: under 2.5s (good threshold), with stretch to 2.0s for PDPs and landing pages
• INP: under 200ms (good), stretch to 150ms on core interactions
• CLS: under 0.1; near-zero is the aim on transactional pages
• TTFB: under 0.8s globally; under 0.4s in core regions

An SLA is not a guarantee of outcomes; it’s a contract on the process and acceptable operating range. We define the metric, percentile, pages/templates in scope, measurement source, and reporting cadence. Then we hold the line. If a release causes p75 LCP on PDP to slip from 2.2s to 3.1s in the UAE, the SLA triggers a rollback or hotfix.

Make SLAs bi-directional: marketing commits to restraint on third-party tags and hero media weight; engineering commits to budgets and regression tests. Everyone signs it. Now speed is a team sport.

A good audit answers three questions: where are we slow, why are we slow, and what is the cost of not fixing this? Here’s the simple flow I run in the first week.

First, map your top 50–100 entry URLs by traffic and revenue contribution. Group them by template: homepage, category, product, blog, landing page, account/checkout. Pull CrUX and GSC CWV status for each group on mobile and desktop. Flag any group failing LCP or INP.

Second, run lab tests for each template: 5–9 Lighthouse runs mobile-emulated and desktop, plus a few WebPageTest runs from core geos. Identify LCP elements, initial server response, render-blocking resources, main-thread blocking time, and largest bundles. Create a one-page diagnosis per template with top three issues and evidence screenshots.

Third, quantify the drag. Instead of promising conversion lifts, tie risk to channels. Slow LCP on your paid landing pages? Expect lower Quality Scores and higher CPCs. Poor INP on mobile checkout? Expect higher drop-off at the payment step. Slow category pages? Expect crawl inefficiency and weaker organic coverage over time. The point is to make inaction visible.

Instrumentation: add RUM in parallel

While running lab tests, add lightweight RUM to production. Capture LCP, INP, CLS, TTFB with page template labels and send to your analytics or warehouse. Track p75 by day and by template. This pays off fast - when you fix something, you’ll see it move.

If you already have RUM, check sampling rates and ensure mobile is well represented. Exclude internal IPs and staging. For SPAs, confirm route changes are tracked as navigations with fresh vitals.

Finally, socialize the dashboard. If leaders can’t see the field p75 by template in one place, they won’t care. Keep it boring and legible.

Budgets make speed sustainable. Without them, every quarter adds a tracking pixel, a bigger hero, a new AB test vendor, and a “temporary” script that never leaves. Budgets convert “move fast” into “move fast within constraints.”

I set four budgets per template: total page weight (KB/MB), JavaScript executed (KB and main-thread blocking time), image/video budget (LCP element weight and decoding strategy), and third-party budget (count and total impact on main thread). I also set a font budget: number of font families and total font bytes.

Budgets are only useful if they fail builds. When a PR adds 200KB of blocking JS or bumps LCP image weight beyond target, the CI check fails. You don’t fix it in production - you don’t ship it. That is the culture shift.

Enforcing budgets in CI/CD

Use Lighthouse CI to run audits on key routes after build. Set thresholds: performance score floor is fine as a canary, but budget against specific metrics and asset sizes. Track render-blocking resources and TBT (Total Blocking Time) as a proxy for INP in lab.

For frameworks like Next.js, verify bundle analysis on every PR. Break out by route chunk and shared chunk. A 30KB shared chunk is felt everywhere. Guard your critical path and shared vendors aggressively.

Establish a release checklist item: “CWV p75 unchanged or improved for impacted templates in last 7 days.” If field says no, you wait. Your future self will thank you.

Speed issues are rarely novel. They’re patterns. Once you can spot them, you can fix them fast and prevent relapse. Here are the main categories and the moves that work.

Third-party scripts: tag managers, analytics, AB testing, chat, social widgets, affiliates. The fix is scrap, defer, or isolate. Kill anything unmeasured. Load essentials late and off the main thread. Use server-side or proxy patterns where possible. Measure each script’s main-thread time and network cost.

JavaScript bloat: massive bundles and hydration cost dominate INP. Reduce JS shipped, split bundles by route, prefer server components and partial hydration where supported, and push expensive interactions behind user intent. If a link doesn’t need a framework, don’t hydrate it.

Media and fonts: unoptimized hero images, auto-playing videos, and heavy font stacks slam LCP and CLS. Fix formats, sizing, lazy-loading, and font strategies. Preload only what is truly critical.

Images and video done right

Target LCP: your main hero image or product photo is usually the LCP element. Serve it in AVIF/WebP with the correct intrinsic size, responsive srcset, and fetchpriority=high. Preload the exact file only when you’re sure it will be LCP on that template.

Lazy-load below-the-fold images with decoding="async". Avoid layout jumps by reserving space with width/height and aspect-ratio. For carousels, load the first slide eagerly, the rest lazily.

Video thumbnails should be static images unless the hero is the video. If so, use efficient posters and avoid auto-play on mobile. Inline, muted, playsinline video has a place; it just can’t be your LCP on 3G.

JavaScript control and framework choices

Modern frameworks give you power - and rope. Favor server-side rendering (SSR) or static generation (SSG) for content and product pages to get pixels fast. If you’re in Next.js, use Server Components to push work to the server, and client components only where interactivity demands it.

Trim your dependencies. Each library has a byte and CPU tax. Replace utility monsters with focused modules. Tree-shake aggressively, split by route, and inline critical paths that don’t change often.

Interaction performance (INP) often dies on expensive event handlers and re-renders. Debounce, batch updates, and avoid layout thrashing in handlers. Prefer CSS for animations; reserve JS for logic, not paint.

Network and infrastructure

Serve from the edge with a solid CDN and cache strategy. Put HTML as close to users as your stack allows. Compress (Brotli), enable HTTP/3/QUIC, and scale TLS. Focus TTFB: fast origin, smart caching, and optimized server-side rendering paths.

Preconnect and DNS-prefetch where it reduces handshake cost for critical domains. Be selective - don’t preconnect to ten vendors “just in case.” Every preconnect is a resource commitment.

For APIs powering client-side content, use caching, ETags, and stale-while-revalidate to cut network chatter. Where possible, move read-heavy content to build-time or server-side fetches.

Executives don’t need flame charts. They need a single page that answers: are we meeting SLAs, are trends improving, and what did we ship to cause the change? Build one dashboard with p75 LCP/INP/CLS by template, week-over-week deltas, and a short narrative.

Add two business overlays: channel metrics where speed matters (e.g., paid landing pages Quality Score and CPC; SEO impressions/clicks for templates); and top-breakdowns (device, country) where the SLA is at risk. Keep the causality language clean - speed is one lever among many, but its impact is well understood operationally.

When you share wins, share the before/after numbers and the diff that caused it: “Reduced PDP LCP p75 from 3.0s to 2.2s by preloading hero image, compressing to AVIF, and setting fetchpriority. INP improved from 260ms to 190ms after deferring reviews widget.” That’s evidence, not adjectives.

Performance affects discoverability (search), cost (ads), and conversion (UX). You don’t need to promise magic multipliers to make the case - you need measurement discipline. Run holdout tests where you can: ship a speed improvement to 50% of traffic on a specific template, hold the rest, and watch engagement and funnel steps.

For paid, faster landing pages typically improve Quality Score and reduce CPC at the margin, especially on mobile. Monitor ad platform diagnostics before and after. For SEO, better CWVs correlate with stronger coverage and stability. Watch Search Console impressions and CWV status together.

Case studies matter. For example, with a B2B SaaS client (Cleverence), we’ve demonstrated compounding organic growth - 0 to 80K monthly organic visits and 0 to 2K inbound leads per month - by building durable content systems on technically sound, fast pages. If you want the detail, see the client story here: Cleverence case study. Different levers, but the principle holds: performance is a foundation you compound on.

You don’t need a committee to own performance. You need one operator who can diagnose, change code, manage CI checks, and build the dashboard leaders read. That’s the working model I run: fewer meetings, more diffs.

Anton Chisliuk · AI Marketing Ops is a Georgian LLC operating from Dubai and Batumi, focused on outcomes over optics. One senior operator ships SEO, automation, paid, outbound, and sites - no account-manager layer. Proof beats pitch: we’ve taken Cleverence from 0 to 80K organic visits per month with 2K inbound leads per month by building content systems on fast, measurable pages. If you want a quick, no-deck assessment of where your bottlenecks are and what to fix first, grab a free Growth Audit.

Whether you hire internally later or not, the work holds: SLAs, budgets, and CI checks that keep shipping speed by default.

Ownership kills drift. I put one person in charge of performance (often an operator or tech lead) with clear authority: define budgets, run audits, block regressions, and publish the weekly report. Marketing and product own the inputs that can blow budgets - third-party tags and design choices - and agree to the SLA.

Set a monthly speed review on the same footing as revenue and pipeline. Show trends, risks, and the next three commits that will move the needle. Keep it 15 minutes. If a page is failing SLAs at p75, a named owner has a plan by EOW.

Incentives matter. Tie performance to release quality KPIs. Celebrate the PRs that remove 100KB and the feature designs that don’t need JS at all.

You can absolutely DIY if you have an engineer who cares, time to build dashboards, and the will to say “no” to bloat. It’s viable, and you’ll learn a lot. The risk is context switching and lack of a clear owner.

Traditional agencies can audit and advise, but execution often dies in handoffs and meetings. If you’ve felt the “agency tax” on speed - nice PDF, little movement - you know the pattern. If you want a side-by-side comparison, here’s a breakdown: agency vs. operator.

The operator route is for teams that want one accountable senior builder who moves from audit to code to dashboard without ceremony. It’s not for everyone. But if you want SLAs enforced in CI, and changes that show up in your field data next week, it’s a fit.

Paid performance is allergic to latency. Slow landing pages lose impatient mobile users and reduce Quality Scores. That’s a double hit - lower conversion and higher CPC. Treat your core paid templates like a product: own LCP and INP, guard against tag sprawl, and test speed wins like you’d test a new headline.

If your media team can’t see p75 LCP/INP for each active landing page in the campaign sheet, they’re flying blind. Connect the dots between page speed, QS diagnostics, and CAC and you’ll find easy wins before creative even changes.

If you need help turning speed into cheaper clicks and cleaner conversions across Google, Meta, and LinkedIn, this is part of my performance stack: performance marketing with an operator lens on speed.

Day 1–30: baseline and quick wins. Stand up field RUM, build the one-page dashboard, and fix the obvious: compress and correctly priority-load LCP images, kill dead third-parties, defer non-critical scripts, and set initial budgets. Aim to land two measurable template wins and prove the reporting loop.

Day 31–60: structural changes. Introduce CI checks for budgets, split big bundles, move to server components or SSR/SSG where it makes sense, and optimize fonts (fewer families, preloaded subsets, font-display: swap or optional). Bring p75 LCP and INP into target range on money pages.

Day 61–90: harden and scale. Expand budgets to long tail templates, add geo/device overlays, and tackle heavier lifts (chat vendor isolation, reviews widget deferral, video handling). Lock SLAs into team rituals and move the culture from “fix speed” to “ship within speed.”

New landing page? New product template? Run a preflight checklist so speed doesn’t regress on launch day. It’s a short list, but skipping it costs you real money.

• Does LCP element load in AVIF/WebP with correct dimensions and fetchpriority?
• Are render-blocking CSS/JS minimized and deferred? Any unused CSS purged?
• Is JS bundle within budget and split by route? Any heavy vendor added?
• Are fonts limited and preloaded correctly? Any layout shifts at p75?
• Does Lighthouse CI pass on the template routes with current thresholds?
• Does RUM capture template label so we can watch p75 after launch?

If you can’t check every box, adjust scope or timing. Launching slow pages is expensive - twice: now and later when you rework them.

If organic visibility matters to you, performance is the ground your content stands on. Fast pages crawl deeper, index cleaner, and convert more of the traffic you already earn. When you’re ready to build an organic engine on a fast foundation, start here: Organic Visibility.

Speed isn’t a mystery. Define the right metrics, measure from the field, set budgets and SLAs, and wire the whole thing into CI so regressions never ship. Treat performance like a product KPI and you’ll stop arguing about scores and start seeing cleaner funnels, steadier SEO, and cheaper paid outcomes.

If you want a working plan tailored to your stack and pages, I can help you baseline, instrument, and ship the first two wins in 30 days. Start with a quick, no-fluff chat and we’ll map it: see the Organic Visibility approach.

Written by Anton Chisliuk - leads, sales, content, and systems, one senior operator.

- What’s the single most important speed metric to track?

If you must pick one, track LCP p75 on mobile for your top revenue templates. It’s the clearest proxy for “can users see the point of the page fast enough?” Add INP next; it tells you if they can actually act.

- How often should we report on Core Web Vitals?

Weekly is the right cadence for leadership, with daily internal checks while you’re shipping changes. Watch p75 trends by template and call out regressions within 24 hours.

- Do we need a CDN to hit LCP targets?

A good CDN and edge caching help, especially for global traffic and TTFB. But you still need to fix images, JS, and render-blocking resources. Distribution can’t paper over heavy pages.

- Are SPAs doomed for Core Web Vitals?

No. SPAs can be fast if you control JS size, use server rendering or server components where possible, and optimize interactions. Many SPA slowdowns come from unnecessary hydration and oversized bundles.

- How do third-party tags affect INP?

They often add main-thread work and event listeners that delay interaction responses. Audit each tag’s cost, defer non-essential ones, and isolate heavy widgets. If a vendor can’t be measured, it shouldn’t be on your pages.

- What’s a realistic 90-day goal for a slow site?

Get p75 LCP and INP to pass on your top two templates (e.g., PDP and paid LP), set and enforce budgets in CI, and publish a stable dashboard. That foundation prevents backsliding and sets you up for broader gains.