WordPress vs. Static Site for an Insurance Agency Website

The finding this article hangs on

Platform debates usually run on vibes, so we'll run this one on a measurement we took ourselves. On August 18, 2026 we ran Google's PageSpeed Insights API against 1,080 insurance agency homepages and published the aggregate dataset CC0¹. Three numbers set the stage: the median mobile performance score was 61; the middle half of the industry sat between 52 and 70; and the median site took 7.9 seconds to paint its largest element on a mobile connection, against Google's 2.5-second "good" threshold for LCP².

Then we fingerprinted the top tier. Among 1,046 substantive agency sites, exactly 12 — 1.15% — scored 99+. Ten of the twelve were static: hand-built pages or website-builder static export. Two ran WordPress, and one of those two reached the tier via NitroPack, an optimization service that effectively serves a staticized version of each page. That distribution — ten native-static, one staticized-WordPress, one disciplined-WordPress — is the spine of everything below.

What WordPress actually is (and isn't)

WordPress is a dynamic content management system: pages live in a database, and PHP assembles the HTML when a visitor (or crawler) requests it. Its genuine strengths follow from that design. The editing experience is mature — any licensed agent can log in and fix a phone number. The ecosystem is unmatched: themes, form builders, SEO plugins, membership tools, someone-already-built-it for nearly anything. And the talent pool is enormous; you will never struggle to find someone who "does WordPress."

What WordPress isn't is inherently slow — and our own data proves that with the two 99+ exceptions. The honest framing is statistical, not categorical: the typical WordPress install, as actually configured by the typical agency's vendor, stacks a heavyweight theme, a page builder, and a dozen plugins, and that stack is what lands sites in the median-61 band. Why the typical install ends up there has a specific mechanism, not a mystery.

Why the typical install ends up slow

Each layer of the standard agency WordPress build adds render-blocking work to every page. The theme ships its own CSS and JavaScript bundles sized for every feature the theme supports, not the ones your site uses. The page builder (Elementor, Divi, WPBakery) adds its runtime on top — markup wrappers, builder CSS, builder JS. Then plugins: a form plugin, a slider, a chat widget, an SEO plugin, an analytics injector — many of which enqueue scripts site-wide even on pages that never use them. None of these choices is individually fatal; the sum is a phone parsing hundreds of kilobytes of JavaScript before the largest element paints — the exact cost the mobile PageSpeed score prices in.

What a static site actually is

A static site does the assembly once, at build time. Every page is rendered to plain HTML before deployment, served from a CDN, with JavaScript added only where a specific page earns it (a quoting widget, a calculator). There's no database query and no PHP execution at request time — which is also why there's no WordPress-style patching treadmill on the public surface. Modern static frameworks (ours is Astro) generate the whole machine layer too: full JSON-LD schema on every page, a generated llms.txt, and agent-callable WebMCP endpoints — the parts an AEO audit scores that a plugin stack controls only partially.

The honest cost: editing is developer-gated or pipeline-driven. There's no admin login where a non-technical office manager rewrites a page on a Saturday. For us that trade works because content ships through a generator; for some agencies it genuinely doesn't — which is the next section's point.

The comparison, factually

The two WordPress sites that made 99+

The exceptions are worth dwelling on, because they keep this article honest in both directions. One of the two WordPress sites in the 99+ tier got there behind NitroPack — which is less a counterexample than a concession: the optimization layer wins by serving pre-optimized, effectively static output in front of the dynamic stack. The other got there the hard way, which proves disciplined WordPress can compete at the top. What the dataset says is not "WordPress can't" — it's that in a field of over a thousand real agency sites, almost nobody's WordPress vendor actually does¹. Betting your agency's web presence on being the rare exception is a choice you should at least make knowingly.

When WordPress is genuinely fine

Three cases, stated without hedging. First: your team edits the site constantly and non-technical editing is non-negotiable — WordPress's editor is still the best-in-class experience, and a lean build (no page builder, minimal plugins, or a NitroPack-style layer) can be made fast enough. Second: you're deep in a WordPress-native ecosystem — a membership area, an existing content library, integrations that would cost real money to rebuild — and the migration cost outweighs a speed-tier gain. Third: your growth engine isn't organic — if referrals and paid leads fill the book and the site is a business card, the median-61 band costs you little. In all three cases the right move is the FAQ's "measure, then subtract" path, not a rebuild.

What we build, and why

Our position follows from the dataset rather than preceding it: we build static (Astro, pre-rendered, CDN-served) because the top speed tier of our own industry sample is where our client builds have to measure — 99–100 mobile from clean builds — and because the AI-search layer (the AEO half of the job) rewards exactly what static generation makes free: complete schema, generated llms.txt, callable agent endpoints, and pages a crawler parses without executing anything. When a client is better served staying on WordPress, the honest advice is the tune-up path above — and we've given it.

Questions agencies ask