Drasken Labs CMS

Tag: Technical SEO

  • Core Web Vitals for Business Websites: What They Measure, What Breaks Them, and What to Fix First

    Core Web Vitals for Business Websites: What They Measure, What Breaks Them, and What to Fix First

    Core Web Vitals for business websites come down to one question: does the page let a visitor become an enquiry without friction? A business website has one job that matters more than the rest: turning a visitor into an enquiry. Everything that slows that down, a hero image that takes four seconds to appear, a form that freezes when someone taps it, a button that jumps just as they go to click it, costs you leads before anyone reads a word of your copy.

    Google has a way of measuring exactly those three failures. They are a ranking signal, but for most businesses the bigger cost of failing them isn’t the ranking. It’s the visitor you paid to bring in who leaves before the page is usable.

    This guide explains what the three metrics measure in 2026, what typically breaks them on business websites, and the order we fix them in when we take over a slow site.

    Quick answer: To pass Core Web Vitals in 2026, a page needs Largest Contentful Paint (LCP) at or under 2.5 seconds, Interaction to Next Paint (INP) at or under 200 milliseconds, and Cumulative Layout Shift (CLS) at or under 0.1, measured at the 75th percentile of real Chrome visitors over a rolling 28-day window. Mobile and desktop are assessed separately.

    What are Core Web Vitals?

    Core Web Vitals are three field metrics that describe how a page feels to a real person: how quickly the main content appears, how quickly the page reacts to input, and whether the layout stays still while it loads.

    MetricWhat it measuresGoodNeeds improvementPoorWhat the visitor experiences
    LCP (Largest Contentful Paint)Loading: when the largest visible element, usually the hero image or headline, finishes rendering≤ 2.5 s2.5–4 s> 4 s“Is this page even loading?”
    INP (Interaction to Next Paint)Responsiveness: the delay between a tap, click or keypress and the next visual update, across the whole visit≤ 200 ms200–500 ms> 500 ms“I tapped the button and nothing happened.”
    CLS (Cumulative Layout Shift)Visual stability: how much content moves unexpectedly while the page loads≤ 0.10.1–0.25> 0.25“I clicked the wrong thing because the page jumped.”

    INP replaced First Input Delay (FID) as the responsiveness metric in March 2024. That change matters for business sites: FID only measured the first interaction, so a site could pass while its enquiry form, menu or filter felt sluggish. INP looks at interactions across the whole visit, which is why many sites that were “green” in 2023 started failing.

    The thresholds themselves have been stable since then. What changed recently is reach: LCP and INP are now measurable in all major browsers, not just Chrome, so the same numbers you see in Google’s tools can be collected from your Safari and Firefox visitors too.

    Core Web Vitals thresholds: LCP 2.5 s, INP 200 ms and CLS 0.1, with what each problem feels like to a visitor
    The three metrics, their thresholds, and what a visitor experiences when each one fails.

    Why Core Web Vitals matter for a business website

    Rankings: a tiebreaker, not a shortcut

    These metrics are part of Google’s page experience signals. Be realistic about their weight: relevance and content quality still decide most rankings. Where they matter is when your service page and a competitor’s are otherwise close. In local and B2B service searches, that’s common, because most pages targeting “website development company in Delhi” or “cloud consultant Dubai” say roughly the same thing.

    Conversions: where the real money is

    Speed and stability affect whether people act. The best-documented example is Vodafone Italy’s A/B test, published on web.dev, where improving LCP by 31% on otherwise identical landing pages produced 8% more sales. For a business website, the equivalent is enquiries, calls and booked consultations.

    Paid traffic: you pay for every bounce

    If you run Google or Meta ads to a landing page, every visitor who leaves before the page renders is a click you paid for and got nothing from. Slow landing pages quietly inflate your cost per lead.

    Your 75th-percentile visitor is not on your laptop

    Google grades you on the experience of the slower end of your real audience. For businesses selling into India, the UAE or Southeast Asia, that visitor is often on a mid-range Android phone on a mobile network. A page that feels instant on office Wi-Fi can still fail.

    Field data vs lab data: the mistake most businesses make

    The most common conversation we have goes like this: “Our developer showed us a Lighthouse score of 95, but Search Console says our pages are failing.” Both can be true.

    • Lab data (Lighthouse, the lab section of PageSpeed Insights) is a single simulated page load on a simulated device. It’s excellent for diagnosing problems and cannot tell you whether you pass.
    • Field data (the Chrome User Experience Report, shown in Search Console and at the top of PageSpeed Insights) is what real visitors experienced over the last 28 days. This is what Google uses.

    Lab tests also can’t measure INP properly, because INP depends on real people clicking real things. A perfect lab score with a heavy chat widget that only loads after interaction will still fail in the field.

    If your site doesn’t get enough traffic to have field data in Search Console, you have two options: use lab tests as a proxy, or collect your own real-user monitoring (RUM) data with the open-source web-vitals library. If you send RUM data into your own metrics stack, tag it by page template (home, service, blog post) rather than by full URL. Per-URL labels are one of the fastest ways to blow up your observability bill with high-cardinality metrics. Setting this up properly is part of what our observability service covers.

    Core Web Vitals field data vs lab data: Lighthouse diagnoses problems, CrUX field data decides pass or fail
    Lab data finds the cause; field data decides whether you pass.

    How to check your own site in five minutes

    1. Open PageSpeed Insights, paste your homepage URL and run the test.
    2. Read the top section first, “Discover what your real users are experiencing”. That is field data. If it says “Passed” for mobile, your homepage passes; the Lighthouse score underneath is only a diagnostic.
    3. Switch between the Mobile and Desktop tabs. Mobile is where most business sites fail.
    4. Repeat for one service page and your main landing page, since those templates usually differ from the homepage.
    5. In Search Console, open Experience → Core Web Vitals to see which groups of URLs are failing and on which metric.

    That gives you a clear, evidence-based picture of where you stand before you spend anything on fixes, and a baseline to compare against once changes go live.

    What usually breaks Core Web Vitals on business websites

    After auditing a lot of company sites, the causes are remarkably consistent. It’s rarely one big problem; it’s a pile of small, reasonable-sounding additions.

    What breaks Core Web Vitals on business websites: causes of poor LCP, INP and CLS
    The most common causes of poor LCP, INP and CLS on business websites.

    LCP problems: the hero takes too long

    • Oversized hero images or sliders. A 3 MB banner exported straight from a design tool, or a five-slide carousel where every slide loads upfront.
    • Lazy-loading the hero. Lazy loading is right for images below the fold and wrong for the one image that defines LCP.
    • Slow server response. Shared hosting, no page caching, or a CMS that builds every page on every request pushes Time to First Byte up, and LCP can’t start until the HTML arrives.
    • Render-blocking CSS and fonts. Several font families, each in multiple weights, loaded before anything can paint.
    • Client-side rendering of the hero. If the headline only appears after a JavaScript bundle downloads and runs, LCP waits for all of it.

    INP problems: the page is busy doing something else

    • Third-party scripts. Chat widgets, analytics, ad pixels, heatmaps, A/B testing tools and tag managers all compete for the same main thread your visitor’s tap needs.
    • Heavy page builders and plugin stacks. Each plugin adds its own JavaScript, often on every page whether it’s used or not.
    • Large JavaScript bundles. Especially on sites that ship an entire app framework to render what is mostly static marketing content.
    • Expensive form handling. Validation libraries, address autocomplete and CRM scripts that run long tasks on every keystroke.

    CLS problems: something arrives late and pushes everything down

    • Cookie banners and promo bars injected at the top of the page after it renders.
    • Images, videos and iframes without dimensions, so the browser doesn’t know how much space to reserve.
    • Web fonts swapping with very different metrics from the fallback font, reflowing every line of text.
    • Embeds such as Google Maps, YouTube, review widgets and social feeds that resize themselves once loaded.

    The fix order we use on business websites

    Fixing these metrics goes faster when you work in the right order. This is the sequence we follow.

    1. Measure by page template, not by page. Search Console groups similar URLs. Your service pages likely share one template; fix the template and you fix them all.
    2. Start with the pages that make money. Homepage, service pages and paid landing pages come before the blog archive.
    3. Fix whichever metric is in the “poor” band first. Moving a metric from poor to needs-improvement usually takes less effort than pushing an amber metric to green.
    4. Audit third-party scripts. Every script should have an owner and a reason. Remove the ones nobody can justify, delay the rest until after the page is interactive, and load chat widgets on intent (a click on a chat button) rather than on page load.
    5. Fix LCP. Serve the hero image in a modern format at the right size, don’t lazy-load it, give it high fetch priority, cache pages at the edge with a CDN, and pre-render marketing pages rather than building them per request.
    6. Fix CLS. Set width and height on media, reserve space for banners and embeds, and use font fallbacks with matched metrics.
    7. Fix INP. Break up long JavaScript tasks, defer non-essential work, and replace heavy components with lighter ones. INP is usually the hardest of the three, so budget time for it.
    8. Stop it regressing. Add a performance budget to your deployment pipeline so a new plugin or a 4 MB image fails the build instead of reaching production. This is standard work in our platform engineering engagements.
    9. Wait for the data. Field data is a 28-day rolling window. Expect to wait around four weeks before Search Console fully reflects a fix.
    Core Web Vitals fix order in nine steps, from measuring by template to waiting for 28 days of field data
    The nine-step fix order, from measuring by template to waiting for field data.

    Hosting and platform choices that affect LCP, INP and CLS

    There is no platform that passes or fails these metrics by default. We’ve seen fast WordPress sites and slow custom React sites. What matters is how the site is built and served.

    • WordPress can pass comfortably with a lean theme, disciplined plugin use and full-page caching. It struggles when a heavy page builder and 30 plugins are all loading on every page.
    • Headless or static setups (for example a Next.js frontend with WordPress as the CMS, which is what our own site runs on) make fast LCP easier because pages are pre-rendered, but they can still fail INP if the frontend ships too much JavaScript.
    • Hosting matters mostly through server response time and caching. A CDN in front of a well-configured server fixes more LCP problems than moving to more complex infrastructure. A marketing website almost certainly doesn’t need Kubernetes, and serving static assets from a CDN is also one of the easier ways to cut cloud costs. If you want this handled end to end, see our cloud and DevOps service.

    If your website includes logged-in areas such as customer dashboards or portals, INP becomes a software engineering problem rather than a website tweak. That’s the point where it helps to treat the site as an application, which we cover in our guide to custom software development services.

    Questions to ask your web developer or agency

    You don’t need to understand every technical detail to hold your website partner accountable. Ask these:

    • Do our key templates pass all three metrics in field data, on mobile and desktop?
    • Which third-party scripts load on our pages, and who decided each one was needed?
    • Is the hero image lazy-loaded? What format and size is it served in?
    • Are pages cached and served from a CDN?
    • What stops a new plugin or image from making the site slower after launch?
    • How will we know if performance regresses before Google does?

    If the answers are vague, performance probably wasn’t part of the brief. That’s worth knowing when you’re comparing quotes, because performance work is one of the real differences between a cheap site and a professional one, as we explain in how much a professional business website costs in 2026.

    How Drasken Labs builds for Core Web Vitals

    We treat Core Web Vitals for business websites as a requirement from the start of a project, not an audit item after launch. In our website development projects that means choosing a rendering approach that suits the content, setting image and script budgets before design sign-off, reserving layout space for every component that loads late, and wiring real-user monitoring into production so we see a regression before it shows up in Search Console. You can see examples of the sites we build in our recent website work.

    Is your website failing LCP, INP or CLS?

    Send us the URL. We’ll tell you which metric is failing, on which templates, and what it would take to fix, whether that’s a focused performance pass or a rebuild.

    Get a Core Web Vitals review from Drasken Labs →

    Sources and further reading

    Are Core Web Vitals a Google ranking factor?

    Yes. They are part of Google’s page experience signals. Content relevance and quality still matter more, so Core Web Vitals tend to act as a tiebreaker between pages that are otherwise similar.

    If my Lighthouse score is 100, do I pass Core Web Vitals?

    Not necessarily. Lighthouse is a lab test on a simulated device. Google assesses Core Web Vitals using field data from real Chrome visitors. Check the Core Web Vitals report in Search Console or the field-data section of PageSpeed Insights.

    How long does it take for fixes to show in Search Console?

    Field data uses a rolling 28-day window, so expect roughly four weeks before a fix is fully reflected. You can use the “Validate fix” option in Search Console to start tracking it.

    Why does Search Console show no Core Web Vitals data for my site?

    Your pages probably don’t have enough real Chrome traffic to be included in the Chrome User Experience Report. Use lab tools for diagnosis and consider collecting your own real-user data with the web-vitals library.

    Can a WordPress website pass Core Web Vitals?

    Yes. WordPress sites pass regularly when they use a lightweight theme, a small set of plugins, page caching and a CDN. Heavy page builders and large plugin stacks are the usual reasons they fail.

    What replaced First Input Delay (FID)?

    Interaction to Next Paint (INP) replaced FID as a Core Web Vital in March 2024. INP measures responsiveness across all interactions during a visit, not just the first one.

    Which Core Web Vital should I fix first?

    Fix whichever metric is in the “poor” band on your most valuable page templates first. After that, LCP usually has the most direct effect on leads, and INP usually takes the most engineering effort.

  • Website Performance Optimization: A Practical Guide for 2026

    Website Performance Optimization: A Practical Guide for 2026

    Website performance optimization is the work of making pages load, respond and stay visually stable fast enough that real visitors on real devices never notice the wait. In 2026, that goal has a precise definition: Google’s Core Web Vitals, measured on your actual traffic.

    Here’s the problem most businesses run into. Someone runs a Lighthouse test, sees a score of 62, installs a caching plugin, re-runs the test, sees 71, and calls it done. Three months later, Search Console still flags the same pages as “Poor,” the site still feels sluggish on a mid-range Android phone, and nobody is sure why.

    That happens because website performance optimization isn’t about a single score. It’s a set of budgets — for server time, bytes, JavaScript execution and layout — and a slow page is one that has blown through at least one of them. Optimization means finding which budget is overspent and fixing that one first.

    This guide walks through the approach we use in website development projects at Drasken Labs: what to measure, where the time usually goes, the fixes for each Core Web Vital, and how to keep a site fast after launch. If you’re still scoping a new site, performance is also one of the factors that shapes what a professional business website costs.

    Short answer: Measure field data first (PageSpeed Insights or Search Console), not lab scores. Fix server response time and the Largest Contentful Paint element before anything else. Then cut JavaScript — especially third-party scripts — to fix responsiveness, reserve space for every image, embed and font to stop layout shifts, and set performance budgets so regressions get caught before release.

    What website performance optimization actually measures

    A fast website isn’t one that gets a green number in a testing tool. It’s one where visitors experience three things:

    • The main content appears quickly. The visitor can see the headline, hero image or product within a couple of seconds.
    • The page responds immediately. Tapping a menu, a filter or a form field produces visible feedback without a lag.
    • Nothing jumps around. Buttons don’t move just as someone goes to tap them, and text doesn’t shift when an ad or font loads.

    Google formalized these three experiences as the Core Web Vitals. They are part of Google’s page experience signals in search, but they matter just as much for conversion: a lead form that lags or shifts under someone’s thumb loses enquiries regardless of where the page ranks.

    Core Web Vitals in 2026: the three numbers that matter

    MetricMeasuresGoodNeeds improvementPoor
    LCP — Largest Contentful PaintLoading: when the largest visible element renders≤ 2.5 s2.5–4.0 s> 4.0 s
    INP — Interaction to Next PaintResponsiveness: delay between an interaction and the next visual update≤ 200 ms200–500 ms> 500 ms
    CLS — Cumulative Layout ShiftVisual stability: unexpected movement of content≤ 0.10.1–0.25> 0.25

    Three details matter more than the thresholds themselves:

    • They’re measured at the 75th percentile. A page passes only if at least 75% of real visits meet the “good” threshold. Your fast office connection is irrelevant; the visitor on a crowded 4G network is not.
    • INP replaced First Input Delay in March 2024. FID only measured the delay before the first interaction was processed. INP looks at interactions across the whole visit, which makes it considerably harder to pass on JavaScript-heavy sites.
    • The thresholds haven’t changed. You may see claims that Google tightened LCP to 2.0 seconds. Google’s documentation still says 2.5 seconds. Aiming lower is a sensible safety margin, not a new rule.
    Website performance optimization targets: Core Web Vitals thresholds of LCP 2.5 s, INP 200 ms and CLS 0.1
    The three Core Web Vitals and the thresholds a page must meet at the 75th percentile.

    Lab data vs field data: why a 95 score can still fail

    There are two kinds of performance data, and confusing them is the most common reason website performance optimization work goes nowhere.

    Lab data comes from tools like Lighthouse, which load a page once in a simulated environment. It’s reproducible and useful for debugging, but it’s one synthetic visit on one simulated device.

    Field data comes from real Chrome users, collected in the Chrome User Experience Report (CrUX) over a rolling 28-day window. This is what Search Console reports and what Google uses for page experience. PageSpeed Insights shows both, with field data at the top when your site has enough traffic.

    A page can score 95 in Lighthouse and still fail INP in the field, because Lighthouse doesn’t click on anything. Real users do — and the chat widget, analytics tags and consent banner that sat idle during the lab test all compete for the main thread when a real visitor starts tapping.

    Use field data to decide what to fix. Use lab data to figure out why it’s slow and to verify fixes before they ship.

    Where the time actually goes: a diagnostic order

    When we audit a slow site, we work through the page load in the order the browser experiences it. Fixing a later stage while an earlier one is broken usually produces little visible improvement.

    1. Server response (TTFB). How long before the first byte of HTML arrives? If this is over roughly 800 ms for most visitors, nothing downstream can fully compensate.
    2. Render-blocking resources. CSS and synchronous scripts in the <head> that must download before anything paints.
    3. The LCP resource. Is the hero image or headline font discovered early, prioritized, and small enough?
    4. Main-thread JavaScript. How much script runs during load and on each interaction, and whose code is it?
    5. Layout stability. What moves after the first paint, and why?

    The Performance panel in Chrome DevTools shows all five on a single timeline. Record a load with CPU throttling set to 4x slowdown to approximate a mid-range phone; problems that are invisible on a developer laptop become obvious.

    Website performance diagnostic order: server response, render-blocking resources, LCP resource, main-thread JavaScript, layout stability
    Diagnose in the order the browser loads the page.

    How to fix Largest Contentful Paint (LCP)

    LCP is usually the hero image, a large heading, or a background image. Break its time into four parts — server response, resource discovery, download, and render — and fix whichever part dominates.

    Make the LCP image discoverable and high priority

    The browser can’t start downloading an image it hasn’t found yet. Images set via CSS backgrounds, injected by JavaScript sliders, or lazy-loaded are found late. Use a plain <img> in the HTML and tell the browser it matters:

    Engineers reviewing a deployment dashboard

    Never add loading="lazy" to the LCP image. Lazy loading is for images below the fold; on the hero, it delays exactly the element Google is timing.

    Serve the right format at the right size

    • Use AVIF or WebP, with JPEG as a fallback where your pipeline requires it.
    • Serve responsive sizes through srcset so a phone doesn’t download a 2,400-pixel desktop image.
    • Compress properly. A hero image rarely needs to exceed 150–250 KB.

    Remove render-blocking work

    • Inline the critical CSS needed for above-the-fold content and load the rest without blocking.
    • Add defer to scripts that don’t need to run before the first paint — which is most of them.
    • Self-host fonts, subset them to the characters you use, preload the one or two files needed for the first screen, and use font-display: swap or optional.

    Choose a rendering strategy that fits the page

    If the HTML is generated by client-side JavaScript, the LCP element doesn’t exist until that JavaScript downloads and runs. For content pages, that’s an avoidable delay.

    StrategyHow it worksBest for
    Static generation (SSG)HTML built ahead of time and served from a CDNMarketing pages, blogs, documentation
    Incremental regeneration (ISR)Static pages rebuilt in the background on a schedule or on publishCMS-driven sites, product catalogs
    Server-side rendering (SSR)HTML generated per requestPersonalized or frequently changing pages
    Client-side rendering (CSR)Browser builds the page from JavaScriptLogged-in app screens where SEO doesn’t matter

    A business website with a headless CMS usually belongs in the first two rows. Serving a marketing page as a client-rendered single-page app is one of the most expensive performance mistakes we see.

    How to fix Interaction to Next Paint (INP)

    INP fails when the browser’s main thread is busy at the moment a visitor interacts. The browser can only do one thing at a time on that thread; if a 400 ms script is running when someone taps “Menu,” the tap waits.

    Ship less JavaScript

    The most effective INP fix is removing code, not optimizing it. Audit the bundle and ask of each dependency whether the page needs it at all. Carousels, animation libraries and full UI frameworks often ship on pages that use a fraction of them.

    Break up long tasks

    Any task over 50 ms blocks interactions. Split heavy work into smaller chunks and yield back to the browser between them, so input can be handled in the gaps. In event handlers, do the visual update first — open the menu, show the spinner — and defer the analytics call or data processing until after the next paint.

    Reduce hydration cost

    Frameworks that render on the server and then “hydrate” in the browser can re-run large amounts of code on load. Partial hydration, server components, and loading interactive islands only when they scroll into view all reduce that cost.

    Keep the DOM reasonable

    Very large DOMs make every style recalculation and layout slower. Pages with many thousands of nodes — often from page builders or mega-menus rendered in full on every page — take longer to update after each interaction.

    How to fix Cumulative Layout Shift (CLS)

    CLS is usually the easiest vital to fix, because the causes are predictable:

    • Images and videos without dimensions. Always set width and height attributes, or use CSS aspect-ratio, so the browser reserves space before the file arrives.
    • Embeds, ads and iframes. Give their containers a fixed minimum height.
    • Injected banners. Cookie notices, promo bars and “download our app” prompts that push content down. Overlay them instead of inserting them above content.
    • Web fonts. A fallback font with different metrics causes text to reflow when the web font loads. Use size-adjusted fallbacks so both fonts occupy the same space.
    • Animations. Animate transform and opacity, not top, height or margin.

    Server, hosting and caching

    Front-end work can’t rescue a slow origin. If time to first byte is high, look here first.

    • Put a CDN in front of everything. Static assets and, where possible, full HTML pages should be served from an edge location near the visitor. For a business serving India, the Gulf and Australia from one origin, this alone can remove hundreds of milliseconds.
    • Set proper cache headers. Fingerprinted assets (app.3f9a2c.js) can be cached for a year with Cache-Control: public, max-age=31536000, immutable. HTML needs shorter lifetimes or revalidation.
    • Enable Brotli compression and HTTP/3 on your CDN or reverse proxy.
    • Fix slow backend queries. On dynamic sites, TTFB problems often trace back to unindexed database queries, N+1 query patterns, or uncached API calls to third-party services on every request.
    • Add an object cache. Redis or a similar cache in front of expensive queries keeps response time flat under load.

    None of this requires a complicated platform. A slow marketing site is almost never a container orchestration problem, and you probably don’t need Kubernetes to fix it. What it needs is correct managed hosting and CDN setup. There’s a cost benefit too: serving cached assets from the edge reduces origin load and egress, which is one of the easier wins in cloud cost optimization.

    Third-party scripts: the performance budget nobody owns

    On many business websites we audit, the site’s own code is not the biggest problem. Third-party scripts are: analytics, tag managers, advertising pixels, heatmaps, A/B testing tools, chat widgets, review badges and social embeds.

    Each one was added by a different person for a sensible reason, and none of them were ever removed. Together they can easily account for most of the JavaScript executed on a page — and they run on the same main thread as your menu and forms.

    • Inventory every tag and name an owner for each. If nobody can say what a script is for, remove it.
    • Load non-essential scripts after the page becomes interactive, or on first user interaction.
    • Use facades for heavy embeds. Show a static preview of a chat widget or video player and load the real thing only when clicked.
    • Consider server-side tagging for analytics and ad conversions, which moves work off the visitor’s device.
    • Treat the tag manager as production code. Changes there can undo weeks of website performance optimization work in one publish.

    WordPress performance: specific traps

    WordPress powers a large share of business websites, and it can be very fast. It usually isn’t, for a few recurring reasons:

    • Plugin accumulation. Every plugin can add its own CSS, JavaScript and database queries — often on every page, whether used there or not.
    • Page builders. Visual builders tend to produce deep, heavy markup and large style sheets. They trade development speed for runtime cost.
    • Stacked optimization plugins. Two caching or minification plugins fighting each other is common, and it often breaks things rather than speeding them up.
    • No persistent object cache. Without Redis or Memcached, WordPress re-runs the same queries on every uncached request.
    • Cheap shared hosting with slow PHP workers, which shows up directly as high TTFB.

    For content-heavy sites where performance is a priority, a headless setup — WordPress as the editing interface, with a static or incrementally regenerated front end served from a CDN — removes most of these problems. It’s the architecture we run for our own site. Where the site needs logic beyond content, such as portals, bookings or integrations, that becomes custom software development rather than theme configuration.

    Keeping it fast: budgets and monitoring

    Performance decays. A new hero video, a marketing tag, a plugin update — each one small, and six months later the site is back where it started. The fix is to treat website performance optimization as a constraint that’s checked continuously, not a project that ends.

    Set performance budgets

    Define limits that fail a build or block a release when exceeded. For example:

    • LCP under 2.0 s in lab tests on a throttled mobile profile
    • Total JavaScript under 200 KB compressed for content pages
    • No single image over 250 KB
    • No new third-party origin without review

    Lighthouse CI can run these checks on every pull request.

    Collect real-user monitoring

    CrUX data arrives with a 28-day lag and only at page-group level. Real-user monitoring (RUM) — sending Core Web Vitals from your visitors’ browsers to your own analytics — shows regressions within hours and tells you which device, page type and element is responsible.

    One warning from experience: tag RUM data by page template or route (/blog/[slug]), not by full URL, user ID or session. Unbounded labels are how a monitoring setup turns into a surprise bill, which we covered in detail in our piece on high-cardinality metrics.

    Pair RUM with alerting — for example, notify the team when p75 LCP on product pages exceeds 2.5 s for an hour — and performance becomes something you see before customers do. That’s the same principle behind the observability work we do for application backends, applied to the front end.

    A 30-day website performance optimization plan

    If you’re starting from a site that’s failing Core Web Vitals, this is a realistic order of work:

    1. Week 1 — Measure. Pull field data from Search Console and PageSpeed Insights for your key templates: home, service pages, blog posts, product or landing pages. Record a throttled DevTools trace of each. Inventory every third-party script.
    2. Week 2 — Server and LCP. Fix TTFB with caching and a CDN. Make LCP images discoverable, prioritized and properly sized. Remove render-blocking CSS and scripts.
    3. Week 3 — JavaScript and INP. Remove unused scripts and dependencies, defer the rest, add facades for heavy embeds, and break up long tasks in your own code. Fix CLS causes in the same pass.
    4. Week 4 — Guardrails. Add performance budgets to the build, set up RUM and alerting, and document who owns the tag manager.

    Expect field data to take up to four weeks to reflect the changes, because of CrUX’s rolling window. Watch your RUM data in the meantime.

    A 30-day website performance optimization plan: measure, fix server and LCP, fix JavaScript and INP, add guardrails
    A 30-day website performance optimization plan, week by week.

    How Drasken Labs approaches website performance

    We treat website performance optimization as an engineering constraint from the start of a project, not a plugin added at the end. In practice, that means:

    • Architecture first. Choosing a rendering strategy and hosting setup that suits each page type before any design is built.
    • Budgets in the build. Performance limits enforced in CI, so regressions are caught in review rather than in Search Console.
    • Infrastructure we operate. CDN, caching and hosting configured and run by the same team that built the site.
    • Monitoring after launch. Real-user Core Web Vitals tracked per template, with alerts when something slips.

    For existing sites, we start with a performance audit: field data, traces of key templates, and a third-party script inventory, ending in a prioritized list of fixes with expected impact. You can see how we build and run sites in our recent work.

    Is your website failing Core Web Vitals?

    Send us the URL and your key pages. We’ll tell you where the time is going and what to fix first.

    Request a performance audit

    Final thoughts

    Website performance optimization isn’t about chasing a perfect Lighthouse score. It’s about making sure the visitor on an average phone and an average network sees your content quickly, can interact with it immediately, and isn’t fighting a page that moves under their thumb.

    The order matters: measure real users, fix the server and the LCP element, cut JavaScript — especially scripts you didn’t write — stabilize the layout, and then put budgets and monitoring in place so the work doesn’t quietly unravel.

    Most sites don’t need a rebuild to pass Core Web Vitals. They need someone to find the two or three budgets that are overspent and fix those first.

    Sources and further reading

    What is website performance optimization?

    Website performance optimization is the process of improving how quickly a website loads, how fast it responds to interactions, and how visually stable it is while loading. In practice, it’s measured with Google’s Core Web Vitals: Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift.

    What are good Core Web Vitals scores in 2026?

    A page is rated “good” when LCP is 2.5 seconds or less, INP is 200 milliseconds or less, and CLS is 0.1 or less, measured at the 75th percentile of real visits.

    Does website speed affect SEO?

    Yes, but modestly. Core Web Vitals are part of Google’s page experience signals, which act more like a tie-breaker between similarly relevant pages than a primary ranking factor. Speed has a larger and more direct effect on bounce rate and conversion.

    Why is my PageSpeed score high but Core Web Vitals still failing?

    The PageSpeed score is lab data from one simulated visit. Core Web Vitals in Search Console are field data from real users over 28 days. Real visitors use slower devices and networks, and they interact with the page, which exposes INP problems that lab tests don’t trigger.

    How long does it take for Core Web Vitals improvements to show?

    Field data in the Chrome User Experience Report uses a rolling 28-day window, so improvements typically take up to four weeks to be fully reflected in Search Console and PageSpeed Insights.

    Will a caching plugin fix a slow WordPress site?

    It helps with server response time, but it doesn’t fix heavy JavaScript, unoptimized images, layout shifts or third-party scripts. Most WordPress sites that fail Core Web Vitals need changes to plugins, themes and scripts, not just caching.

    How much does website performance optimization cost?

    It depends on the cause. Fixing images, caching and a handful of scripts is a small, contained engagement. If the site is built on a heavy page builder or renders content client-side, meaningful gains may require rebuilding key templates. An audit is the fastest way to find out which case you’re in.