Astro vs WordPress: The Real Core Web Vitals Numbers for Service Business Sites
August 20, 2026 · The Valley Marketing Group
If you run a plumbing, HVAC, roofing, dental, or med spa business in the Valley, your website's Core Web Vitals scores are quietly shaping whether you show up when someone searches "plumber near me" from their phone in a driveway with two bars of signal. We've spent the last year moving client sites off WordPress and onto Astro, and the 2026 comparative data on Core Web Vitals between the two platforms is stark enough that we think every service business owner deserves to see the actual numbers — not marketing spin, the real Chrome UX Report and HTTP Archive figures.
What Core Web Vitals Actually Measure
Core Web Vitals are a set of three specific, user-centered metrics Google uses to measure real-world page experience: how fast the main content loads, how quickly the page responds to input, and how visually stable it stays while loading. They were built to replace vague notions of "site speed" with numbers that correlate to what a person actually feels when they land on a page.
The three metrics are:
- Largest Contentful Paint (LCP) — the time it takes for the largest visible element (usually a hero image, headline, or above-the-fold block) to fully render. Google considers under 2.5 seconds "good."
- Interaction to Next Paint (INP) — how quickly the page responds when a visitor taps a button, opens a menu, or fills in a form field. Under 200 milliseconds is the target.
- Cumulative Layout Shift (CLS) — how much the page's visual layout jumps around as it loads (a button that shifts right as an ad loads, for example). A score under 0.1 is considered stable.
Google folded these into its ranking systems because they're proxies for something search engines have always cared about indirectly: whether a visitor actually got a usable experience out of the click they gave you. We wrote about this shift in more detail in why we stopped building client sites on WordPress — Core Web Vitals data was one of the deciding factors, not the only one.
The Real Numbers: Astro vs WordPress Pass Rates
According to 2026 comparative data pulled from the Chrome UX Report and HTTP Archive, Astro sites pass Core Web Vitals on mobile at a 60% rate, compared to WordPress sites passing at 38%. That's a 22 percentage point gap — meaning a randomly selected Astro site is roughly 60% more likely to pass Google's mobile thresholds than a randomly selected WordPress site (Search Engine Journal, 2026).
That gap isn't abstract. If nearly two out of three WordPress sites are failing Core Web Vitals on mobile, and mobile is where the overwhelming majority of "near me" searches happen, a huge share of local service business websites are underperforming in exactly the moment that matters most — someone standing in their kitchen with a leaking pipe, phone in hand.
The same data set found that Astro produces HTML output that is 72% lighter than WordPress's, and LCP times that are 65% faster. Astro sites typically land LCP under 1.5 seconds; WordPress sites, without extensive caching and CDN tuning, often land between 2 and 3 seconds (Search Engine Journal, 2026). That's the difference between a page that feels instant and one where a visitor has already glanced away.
Page weight tells a similar story. Astro sites average 1.65 MB per page, while WordPress sites carry a median page weight of roughly 2.63 MB (Zorinto, 2026). Every extra megabyte is bytes a visitor's phone has to download, parse, and render before they see anything useful — and on a spotty 4G connection outside a job site, that difference is the gap between a page that loads and one that gets abandoned.
What "Passing" Actually Means for Your Site
Passing Core Web Vitals doesn't mean your site is fast in some abstract sense — it means Google's field data, collected from real Chrome users who visited your pages, shows LCP, INP, and CLS all landing in the "good" range for the 75th percentile of visits. A site can look fast to you on a fiber connection in your office and still fail Core Web Vitals for the mobile visitor on a 4G connection standing in a driveway. That's exactly the population that matters most for a plumber, electrician, or dentist.
Why Astro Performs Better: The Architecture, Not Just the Code
The gap between Astro and WordPress isn't a matter of one team writing tighter code than another. It comes from a fundamentally different architecture.
Zero Client-Side JavaScript by Default
Astro ships zero client-side JavaScript by default. Its "islands architecture" renders each page as static HTML and only hydrates JavaScript for the specific components that need interactivity — a booking form, a review carousel, a mobile nav toggle. Everything else on the page stays plain HTML and CSS with no JavaScript execution cost at all (Search Engine Journal, 2026). Less JavaScript running on a visitor's phone means less time spent parsing and executing code before the page responds to a tap — which is directly what INP measures.
Static HTML Output
Astro pages are built ahead of time into plain HTML files. There's no templating engine assembling the page at the moment a visitor requests it — the file is already sitting there, ready to be handed over as-is.
No Runtime PHP or Database Queries Per Page Load
This is the architectural difference that matters most. Every time someone loads a WordPress page, the server typically has to run PHP, query the MySQL database for post content, widgets, and menu data, run that through the theme's template logic, and assemble the final HTML — on every single request, for every single visitor, unless a caching layer intercepts it. A static, pre-built site skips all of that: the HTML was generated once, at build time, and every visitor after that just receives the finished file. That's why headless and static architectures generally achieve a faster Time to First Byte than traditional CMS platforms — there's no server-side render-and-query cycle standing between the request and the response.
Why WordPress Needs Plugins and CDNs to Compensate
None of this means WordPress can't perform well — it can, and plenty of well-tuned WordPress sites score respectably. But getting there requires actively working against the platform's default architecture: caching plugins (WP Rocket, W3 Total Cache), a CDN in front of the origin server, image optimization plugins, database cleanup, and often a managed hosting plan built specifically to handle the load. Each of those is a piece of infrastructure that has to be installed, configured correctly, kept updated, and paid for — and if any one of them is misconfigured, or conflicts with another plugin, the performance gains can quietly disappear.
That's the core issue: caching and CDN layers are a workaround for the architecture, not a fix to it. They add a layer of complexity that has to be maintained indefinitely, and every plugin added to solve a performance problem is another dependency that can break, go unmaintained, or become a security liability. We've written specifically about how that plugin stack becomes an ongoing cost center in the hidden costs of running a WordPress site, and about the security exposure that comes bundled with it in our companion piece on WordPress plugin security.
Astro sites don't need a caching plugin to serve a cached-feeling page, because the page was static from the moment it was built. There's no cache to invalidate, no plugin conflict to debug, and no origin server getting hammered by a traffic spike.
An Honest Caveat: The Gap Isn't Fixed
We think it's worth being straight about the nuance here rather than overselling the numbers. Part of the reported gap reflects the kinds of sites that are currently being built on Astro — often newer, more deliberately optimized, and less likely to carry years of plugin accumulation than the average WordPress install. As Astro sites take on heavier interactivity — e-commerce carts, complex booking flows, dashboards — some of that out-of-the-box advantage narrows, because more JavaScript inevitably has to hydrate somewhere (Search Engine Journal, 2026).
For most local service business sites, though, that caveat barely applies. A plumbing, HVAC, dental, or med spa site doesn't need a shopping cart or a complex web app — it needs fast-loading service pages, a lead form, a phone number, and content that answers what a searcher is asking. That's exactly the profile of site where Astro's default advantage holds up best, because there's very little interactivity pulling against it.
What This Means for Local Service Businesses Specifically
Mobile-First, Spotty-Connection Searchers
Google indexes and ranks primarily based on the mobile version of your site — a policy known as mobile-first indexing. For a local service business, the overwhelming majority of "near me" and emergency-intent searches happen on a phone, often on a cellular connection rather than home WiFi: someone standing next to a broken water heater, sitting in their car outside a shopping center, or searching during a work break. These are exactly the conditions where a 2-3 second LCP on WordPress versus a sub-1.5 second LCP on Astro becomes the difference between a page that loads before they give up and one that doesn't.
Speed and Lead Capture Are Directly Connected
Every additional second a page takes to become usable is a second where a visitor can bail before ever seeing your phone number or your lead form. A visitor who never lays eyes on your call-to-action can't convert, no matter how well the form itself is built. Fast Core Web Vitals scores aren't a vanity technical metric — they're upstream of whether your marketing spend, your SEO content, and your ad clicks ever actually convert into a phone call or a booked appointment.
Trust Signals Compound
A page that loads instantly and doesn't jump around while a visitor is trying to tap "Call Now" reads as more professional and more trustworthy than one that stutters and shifts. For a service category where trust is the entire sale — letting someone into your home, your mouth, your car — that first few seconds of experience is doing more persuasive work than most people give it credit for.
A Closer Look at Interaction to Next Paint (INP)
Of the three Core Web Vitals, INP is the newest and the one most business owners understand least, so it's worth a closer explanation. INP replaced an older metric called First Input Delay in 2024, and the reason for the change matters: First Input Delay only measured the very first interaction on a page — the first tap, the first click — and ignored everything after it. A page could feel sluggish on the third or fourth interaction and still pass the old metric perfectly. INP measures responsiveness across the entire visit, capturing the worst interaction delay a visitor experienced, not just the first one.
For a service business site, this shows up in concrete moments: a visitor taps to open a mobile navigation menu and it takes a beat too long to respond; they tap into a form field and the keyboard or focus state lags; they tap "Call Now" and there's a noticeable delay before anything happens. Each of those moments is a small friction point, and INP is Google's attempt to quantify how much friction a real visitor actually experienced, not just how the page looked when it first appeared.
This metric in particular tends to punish JavaScript-heavy pages disproportionately, because every interaction has to wait for the browser's main thread to finish whatever JavaScript work is already queued up. A page loaded with a page-builder runtime, several plugin scripts, and theme JavaScript — the typical WordPress profile described earlier — has more competing work on that main thread, which is a direct, mechanical reason WordPress sites tend to score worse on INP specifically, independent of anything about server response time or image weight.
Want us to look at your setup?
Free 24-hour audit. No pitch, no pressure.
Cumulative Layout Shift: The Metric That's Purely About Trust
CLS deserves its own explanation too, because unlike LCP and INP, it isn't really about speed at all — it's about visual stability, and it has an outsized effect on how trustworthy a page feels. A high CLS score usually comes from a specific, avoidable pattern: an image, ad, or embedded element loads without its final dimensions reserved in advance, so the rest of the page's content jumps down (or sideways) to make room for it once it finishes loading. Anyone who has tried to tap a button on a mobile page only to have it shift at the last second, causing a mis-tap on an ad or the wrong link, has experienced exactly what CLS measures.
For a service business, this failure mode is particularly costly around the exact elements meant to drive conversions: a "Call Now" button or a lead form that shifts position as the page finishes loading is a button a rushed visitor might tap incorrectly, or simply give up on. WordPress sites commonly generate layout shift through late-loading web fonts that change text size after the page has already rendered, ads or embedded widgets that reserve no space until they load, and page-builder elements that render in stages rather than all at once. A static Astro build, by contrast, has every element's final layout determined at build time, so there's no staged rendering process for a visitor to experience as a shift in the first place.
How This Connects to Local SEO Rankings
Core Web Vitals are one input among many in Google's ranking systems, and they matter most as a tiebreaker between pages that are otherwise similarly relevant — but for local service businesses, that tiebreaker effect shows up constantly, because dozens of competitors in the same metro are often targeting the exact same "[service] near me" queries with comparable on-page content. When relevance is roughly equal, page experience becomes one of the differentiators deciding who shows up first.
This isn't limited to organic blue-link rankings, either. Local pack visibility — the map-and-three-listings block that dominates the top of local search results — is influenced by a mix of proximity, relevance, and prominence signals, and a site that Google's crawlers and real users experience as fast and stable feeds into that prominence signal over time. We go deeper on the specific factors driving that local pack placement in our breakdown of Google Maps pack ranking factors for Phoenix service businesses. Core Web Vitals won't single-handedly win you the local pack, but a WordPress site failing Core Web Vitals at a 62% rate industry-wide is starting that competition with a real handicap.
How to Check Your Own Site's Core Web Vitals Right Now
You don't need to take our word — or Search Engine Journal's — for where your own site stands. Google publishes the real, field-collected data behind Core Web Vitals through two free tools, and checking them takes about five minutes.
Google Search Console
If you have Search Console set up for your domain, the "Core Web Vitals" report under the Experience section shows real Chrome UX Report data collected from actual visitors to your site over the past 28 days — not a lab simulation. It groups your URLs into "Good," "Needs Improvement," and "Poor" buckets for both mobile and desktop, which is the exact classification search rankings care about. If you're not sure whether your site is registered with Search Console, that's worth fixing before anything else — it's the same tool that shows indexing status and search performance, and it's free.
PageSpeed Insights
Google's PageSpeed Insights tool (found at pagespeed.web.dev) tests any URL on demand and returns both field data (if enough real visitors have loaded that page) and a lab-simulated score, broken down metric by metric — LCP, INP, CLS, plus supporting diagnostics like total page weight and the specific resources slowing things down. Unlike Search Console, you don't need to own or verify the site to run this test; you can check a competitor's site, an old version of your own site, or a page you're considering rebuilding, and get an immediate read.
What to Actually Look For
When you run either tool, the number that matters most for a service business is the mobile score, not desktop — mobile is where the bulk of local search traffic lands, and it's consistently the harder threshold to pass because phones have less processing power and less reliable connections than office desktops. If your mobile LCP is showing 2.5 seconds or higher, or your page is flagged for excessive JavaScript execution time, that's a direct, measurable symptom of the architecture problem this whole post is about — not something a single settings tweak is likely to fix.
The Business Cost of Failing Core Web Vitals Beyond Rankings
Core Web Vitals don't only affect organic search rankings. If you're running Google Ads campaigns — which most competitive service businesses in the Valley are — landing page experience is a documented factor in Google Ads Quality Score, the metric that determines both your cost-per-click and your ad rank. A slow, unstable landing page can mean you're paying more per click than a competitor running the identical ad targeting the identical keyword, simply because Google's systems have flagged your page as a worse experience for the person who just clicked. That's real money leaving the account before a single lead is ever generated, layered directly on top of whatever organic ranking disadvantage the same slow page is creating.
There's also a compounding effect with bounce rate that doesn't show up in a Core Web Vitals report but shows up in your analytics: a visitor who bounces immediately because a page hasn't rendered yet still counts as a "visit" in most analytics tools, making top-of-funnel numbers look healthier than the business results underneath them actually are. A business owner staring at steady traffic numbers next to disappointing lead volume is often looking at exactly this gap — visitors arriving, and a slow page quietly turning a meaningful share of them away before they ever see a phone number.
Common WordPress Performance Fixes — and Why They Have a Ceiling
To be fair to the WordPress ecosystem, there's an entire category of plugins built specifically to close this gap, and some of them genuinely help. It's worth understanding what they do and where they run into a wall.
Caching Plugins (WP Rocket, W3 Total Cache, WP Super Cache)
These plugins generate a static HTML snapshot of a page the first time it's requested, then serve that snapshot to subsequent visitors instead of re-running the full PHP-and-database render cycle each time. This is genuinely effective at reducing server response time — it's essentially an attempt to make WordPress temporarily behave like a static site for cached pages. The limitation: the cache has to be correctly configured, has to be invalidated and rebuilt every time content changes, and does nothing for the client-side JavaScript weight that a visitor's browser still has to download and execute after the cached HTML arrives.
Image Optimization Plugins (ShortPixel, Smush, Imagify)
These compress and resize images automatically, which helps with page weight — one of the more legitimate wins available within WordPress. But they're solving one input to LCP (image size) while leaving the underlying render pipeline, plugin JavaScript, and database query overhead untouched.
"Lazy Loading" and Deferred JavaScript Plugins
These delay loading images and scripts that aren't immediately visible on screen, which can help initial paint times. The tradeoff is added complexity — another plugin, another potential conflict, another thing that can silently misconfigure and break either performance or functionality (a lazy-loaded image that never triggers, for instance).
Where the Ceiling Is
Every one of these tools is working around the same underlying fact: WordPress's default architecture assumes a live PHP application assembling pages on demand, and every performance plugin is an attempt to fake the behavior of a static site without actually becoming one. Stacked together, a heavily optimized WordPress site can close a meaningful part of the gap — but it's doing so through an accumulating pile of additional plugins, each with its own update cadence, potential for conflict, and — as covered in our piece on WordPress plugin security — its own vulnerability surface. Astro doesn't need any of this stack to achieve the same starting point, because static output isn't a workaround for Astro. It's the default.
A Note on Other Static Site Approaches
Astro isn't the only framework capable of producing a fast, static-first website — Next.js, Gatsby, and Hugo are all reasonable tools in the same general category, and a well-built site on any of them can post strong Core Web Vitals numbers too. We standardized on Astro specifically for the profile of site we build most often: content-heavy, form-driven local service business sites that benefit enormously from islands architecture's "static by default, interactive only where needed" model, without the added JavaScript framework overhead that comes bundled into some of the alternatives by default. The broader point holds regardless of which specific static-first framework a developer chooses: the architectural category — pre-built HTML, minimal shipped JavaScript, no per-request database query — is what's driving the Core Web Vitals gap in the data above, not any single framework's particular implementation.
What We're Actually Recommending
We're not suggesting every WordPress site needs to be torn down tomorrow — a well-maintained, properly cached WordPress install can perform acceptably, and migrations aren't free. But when we're building a new site for a local service client, or evaluating whether an existing WordPress site is worth migrating, the Core Web Vitals data is one of the clearest, most measurable arguments for starting on a static architecture like Astro rather than fighting WordPress's defaults with an ever-growing plugin stack. The 22-point pass-rate gap, the 65% faster LCP, and the lighter page weight aren't incremental improvements — they're a different starting position entirely, achieved by default rather than through ongoing maintenance.
If you want to know exactly where your current site stands on these metrics — real Chrome UX Report data, not a guess — we offer a free audit that walks through your Core Web Vitals scores, what's driving them, and what it would take to close the gap.
How Valley Can Help
We Help Businesses Like Yours Get More Leads — and Close More of Them
The Valley Marketing Group is a Phoenix-based marketing agency specializing in AI-powered lead generation, paid advertising, and web development for local service businesses.
- Google Ads & paid search — campaigns built to generate qualified leads, not just clicks
- AI phone receptionist — never miss a call or lead while you're on the job
- Website design & development — WordPress, Webflow, Shopify, WooCommerce
- SEO content & local search — rank for the searches your customers are already making