Benchmark layer
WordPress speed benchmarks by vertical
SEOParity uses vertical speed benchmarks as evidence, not as a Lighthouse scoreboard. The layer starts with the published Houston dental study and defines the standard future verticals must meet before publication.
Published
Houston dental practices
20 public local-service sites
Mobile speed benchmark with charts, aggregate CSV, methodology, and caveats.
OpenMethod defined
WooCommerce catalogs
Requires a new public sample before publication
Use catalog page type, product count, category depth, theme/plugin symptoms, and mobile lab data.
OpenMethod defined
Content-heavy WordPress sites
Requires a new public sample before publication
Use template type, ad/script weight, image delivery, LCP element type, and crawlable content depth.
Open| Rule | Benchmark standard |
|---|---|
| Sample rule | Use public URLs only, avoid publishing private lead data, and avoid shaming individual sites when aggregate evidence is enough. |
| Metrics | Mobile PageSpeed Performance, LCP, TBT, CLS, Speed Index, render-blocking savings, and visible bottleneck class. |
| Caveats | Lab data is not field data. Treat it as directional until CrUX, RUM, or enough production sessions exist. |
| Output | Publish charts, aggregate CSV, method notes, caveats, local implications, and a route to the WordPress speed test. |
| Reopen rule | Add a new vertical only after the sample meets the method bar and the data can be explained without overclaiming. |
How this supports migration decisions
A benchmark does not prove a single site needs a rebuild. It shows what the market looks like, then the speed test and audit determine whether a specific site should be optimized, rebuilt, or left alone.