Astro for Small-Business Websites: A 33-Item Speed Checklist and a Six-Page Build

Marc Mulvaney — Fri, 30 Oct 2026 08:48:51 GMT

I build small-business websites in Astro. In the HTTP Archive Core Web Vitals Technology Report for October 2026, 72.2% of Astro sites passed all three Core Web Vitals on mobile, against 49.0% of WordPress sites and 53.0% of all sites tracked. The median Astro home page weighed about 1.3 MB on mobile that month, under half the 2.7 MB median WordPress page, in the same report.

One caveat, stated once: those figures come from real sites measured in the field, not from a lab test. Framework choice is not the only cause of the gap. Hosting, themes, plugins and third-party scripts also affect each site's result.

This post covers what Astro does differently, the Core Web Vitals thresholds Google publishes, the Astro versus WordPress numbers for October 2026, an illustrative six-page plumber build with code, the cases where WordPress is still the right call, and a 33-item checklist you can run on your own site today.

What Astro does differently

Astro renders components to HTML and CSS at build time. The Astro docs put it this way: "By default, Astro will automatically render every UI component to just HTML & CSS, stripping out all client-side JavaScript automatically."

Interactive parts become islands. The same page of the docs states: "With islands, client-side JavaScript is only loaded for the explicit interactive components that you mark using client:* directives." A quote form or a booking widget gets JavaScript. The header, the service text, the footer and the phone link do not.

A finished Astro build is a folder of HTML, CSS and image files plus the few JavaScript files the islands need. Any static host serves that folder. No PHP runs on each visit. No database query runs on each visit. There is no admin login page on the public site.

Images go through the component from astro:assets. The Astro image docs state: "The component optimizes for CLS by automatically setting the correct width and height for your images." The component also converts images to WebP by default and keeps the alt attribute required.

Content lives in Markdown files, in content collections or in a headless CMS. A content change triggers a rebuild, and the host serves the new static files.

Why the speed numbers matter to a local business

Google publishes the pass thresholds on web.dev: Largest Contentful Paint (LCP) within 2.5 seconds, Interaction to Next Paint (INP) of 200 milliseconds or less, Cumulative Layout Shift (CLS) of 0.1 or less, measured at the 75th percentile of page loads, split by mobile and desktop.

Google recommends those thresholds for Search. Google Search Central says: "We highly recommend site owners achieve good Core Web Vitals for success with Search and to ensure a great user experience generally. This, along with other page experience aspects, aligns with what our core ranking systems seek to reward."

Google ranks the mobile version. Google's mobile-first indexing page states: "Google uses the mobile version of a site's content, crawled with the smartphone agent, for indexing and ranking."

Page weight correlates with LCP. The Web Almanac 2024 page weight chapter reports "a clear correlation between the page weight and Largest Contentful Paint, the higher the page weight, the longer the time to LCP. This is especially true for mobile devices." The median mobile page grew: the Web Almanac 2025 puts it at 2,362 KB as of July 2025, up from 845 KB in July 2015.

Fewer than half of mobile sites passed in 2025. The Web Almanac 2025 performance chapter reports that good Core Web Vitals performance "reached 44% on mobile and 55% on desktop" in 2024 and "further improved in 2025 to 48% for mobile websites and 56% for desktop websites."

Google published one revenue case. Its Vodafone case study is titled "Vodafone: A 31% improvement in LCP increased sales by 8%". That is one company's measured result.

Astro vs WordPress: the October 2026 numbers

All figures below are medians for mobile from the HTTP Archive Technology Report, October 2026.

Metric (mobile, October 2026)	Astro	WordPress	All sites
Origins passing all three Core Web Vitals	72.2%	49.0%	53.0%
Median total page weight	1,285,350 bytes (about 1.3 MB)	2,730,019 bytes (about 2.7 MB)	2,551,208 bytes (about 2.6 MB)
Median JavaScript bytes	389,918 (about 390 KB)	689,307 (about 689 KB)	736,473
Median image bytes	306,488 (about 306 KB)	1,030,068 (about 1.0 MB)	750,219
Median Lighthouse performance score	70.5	44	49
Median Lighthouse SEO score	100	92	92
Median Lighthouse accessibility score	95.5	88	87.5
Median Lighthouse best practices score	92	79	77

Source: HTTP Archive Technology Report, Astro and WordPress, mobile. The Core Web Vitals row covers 53,101 Astro origins and 2,513,839 WordPress origins tested in October 2026.

The Astro pass rate rose every month from June to October 2026. The same report shows Astro at 67.2% in June 2026, then 69.8%, 71.0%, 71.1% and 72.2% in October. WordPress moved from 48.8% in June to 49.0% in October. All sites moved from 53.1% to 53.0%.

The Web Almanac 2025 CMS chapter ranks CMS platforms by mobile Core Web Vitals and reports: "Duda is the top performer with 85% of its sites meeting the benchmarks ... WordPress remains among the lowest-ranked with a pass rate of 45%." The same chapter puts the WordPress median Lighthouse performance score at 63 on desktop and 41 on mobile.

The CMS chapter states that WordPress is "powering roughly 64% of CMS-driven sites" and that "around 60% of WordPress sites use a page builder." In the table above, the median Astro page carried 389,918 bytes of JavaScript and 306,488 bytes of images. The median WordPress page carried 689,307 bytes of JavaScript and 1,030,068 bytes of images.

Security and maintenance: what a static build removes

Patchstack's State of WordPress Security in 2026 reports: "11,334 new vulnerabilities were found in the WordPress ecosystem in 2025 - that's a 42% increase compared to 2024." The same report states: "91% of new vulnerabilities were found in plugins, and 9% were found in themes. There were only 6 vulnerabilities reported in the WordPress core".

A static Astro site has no plugin layer in production. The dependencies run on the build machine, not on the server that visitors hit. The public site has no PHP interpreter, no database and no login form.

Static does not mean zero risk. The form endpoint, the DNS account, the hosting account and the Git repository still need strong passwords and two-factor authentication. Review every third-party script you add (chat widget, analytics, ad pixel), because each one runs in your visitors' browsers.

A WordPress site needs core, theme and plugin updates on a schedule, plus a backup you have tested. An Astro site needs a dependency update when you next change content, and the build either passes or fails before anything goes live.

Illustrative example: a six-page plumber site

Illustrative example. This is not a real client and these are not measured results. It shows what the build does and what the owner should measure afterwards.

The site has six pages: home, four service pages (water heaters, drain cleaning, leak repair, emergency plumbing), and contact. Every page is static HTML. The phone number is a plain link in the HTML, so it works before any script loads. One JavaScript island, the quote form, loads only when it scrolls into view. Every photo goes through . Every page carries LocalBusiness structured data.

At freewebsite247 we build our customers' sites this way. Every site is built by humans, assisted with AI.

The home page with one island

---
// src/pages/index.astro
import Layout from '../layouts/Layout.astro';
import { Image } from 'astro:assets';
import QuoteForm from '../components/QuoteForm.jsx'; // a React, Preact, Svelte, Vue or Solid component
import vanPhoto from '../assets/van.jpg';
---

  [Business name]: licensed plumber in [City]
  
    Same-day service. 
    Call [PHONE]
  

  

  Services
  
    Water heater repair and replacement
    Drain cleaning
    Leak repair
    24-hour emergency plumbing
  

  Get a quote

What this does:

The tel: link is plain HTML. A visitor can tap and call before any JavaScript loads, or with JavaScript blocked.
from astro:assets reads the width and height from the imported file and writes them into the tag, which is how it prevents layout shift. It converts the file to WebP by default. The alt attribute is required by the component.
loading="eager" on the hero image overrides the component's default lazy loading. Use it on the image you expect to be the LCP element.
client:visible on the quote form means its JavaScript downloads when the form scrolls into the viewport. Until then the page has zero framework JavaScript.
Framework components need the matching Astro integration installed (for example @astrojs/react or @astrojs/preact). Keep the file extension in the import, as the Astro docs do.

The LocalBusiness JSON-LD block

Put this in the of the layout, or in a component included on every page. Replace every value in brackets. Keep the rest exactly as written so the JSON stays valid.

Plumber is a schema.org subtype of LocalBusiness. Swap it for Electrician, HVACBusiness, Dentist, Restaurant or plain LocalBusiness to match the business. In Astro you can also build the object in the component's frontmatter and output it with