Core Web Vitals are field metrics: they describe what real visitors experienced, not what a lab browser measured on a fast connection. That makes them useful and awkward at the same time. They are useful because they correlate with the experience that affects conversion. They are awkward because the data is observational, noisy, and shaped by the site as much as the server.
This report groups 50 WordPress sites by host and compares the p75 of each metric. The headline is not “host X wins.” It is that the host effect is real but smaller than most buyers assume, and that the biggest gains usually come from the application layer.
- 64% of the cohort passed all three Core Web Vitals thresholds at p75.
- Rocket.net and Kinsta had the strongest LCP distributions, at 1.26 s and 1.43 s p75.
- INP was the most common failure: 30% of sites (15 of 50) missed the 200 ms threshold.
- Theme family explained more variance in LCP than host did, especially on media-heavy homepages.
- Hosting cannot fix a 700 ms JavaScript task, an unoptimized hero image, or a render-blocking tag manager.
The cohort results
The table reports the median p75 for each metric within each host group, plus the share of sites that passed all three thresholds. Pass rate is the most practical column: it describes how often a site on that host achieved a good experience, not just how good the best sites were.
| Host | LCP | INP | CLS | Pass rate | Sites |
|---|---|---|---|---|---|
| Rocket.net | 1.26 s | 84 ms | 0.04 | 73% | 11 |
| Kinsta | 1.43 s | 91 ms | 0.05 | 67% | 12 |
| WP Engine | 1.52 s | 98 ms | 0.05 | 70% | 10 |
| Cloudways | 1.61 s | 104 ms | 0.06 | 56% | 9 |
| Pressable | 1.66 s | 112 ms | 0.06 | 50% | 8 |
Cohort data: measured field data for the Sep–Oct 2026 window. The thresholds are Google's: LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1. Pass rate means all three thresholds met at p75.
LCP p75 by host
Lower is better. Cohort medians, Sep–Oct 2026.
The spread inside each host is the real story
The difference between the best and worst host median is 400 ms of LCP. The difference between the best and worst site on the same host can be several seconds. That is not a reason to ignore hosting; it is a reason to stop treating hosting as the only lever.
We split the cohort by theme family and page type. On lightweight, block-based themes with optimized images, the host gap narrowed to roughly 180 ms. On heavy multipurpose themes with sliders, the host gap widened, because the origin and edge had more work to do and the render path was longer. Again: the application amplifies or masks the infrastructure.
| Page type | Light theme | Heavy theme | Gap |
|---|---|---|---|
| Blog article | 1.32 s | 1.94 s | +620 ms |
| Marketing homepage | 1.48 s | 2.31 s | +830 ms |
| WooCommerce catalog | 1.71 s | 2.48 s | +770 ms |
| Product page | 1.66 s | 2.39 s | +730 ms |
What each metric is telling you
LCP is usually an image or a hero block. The browser has to discover the resource, download it, and render it. Hosting helps with TTFB and edge delivery; it does not help if the image is 2.4 MB, lazy-loaded incorrectly, or blocked by a font or script. Start with the Largest Contentful Paint element in a lab trace, then fix the asset.
INP is a JavaScript problem. It measures the delay between an interaction and the next paint, across the visit. A fast host can deliver the JavaScript sooner, but a long task on the main thread still blocks the response. Audit event handlers, third-party tags, hydration, and heavy plugins. This is the metric most often missed and the one a host migration is least likely to fix.
CLS is a layout problem. It comes from images without dimensions, injected banners, web fonts that swap, and ads that push content. Hosting is almost irrelevant. A CDN can serve the asset faster, but the layout still shifts if the space was not reserved.
Why host attribution is weaker than it looks
This is an observational cohort, not a randomized experiment. Sites are not assigned to hosts by chance. A premium host may attract agencies with disciplined performance practices; a budget host may inherit older sites with heavy plugin stacks. The host coefficient therefore captures some of the builder effect.
We controlled for page type, theme family, and traffic tier where the cohort allowed. The ordering held, but the gaps shrank. We also excluded sites that changed hosts during the window and sites with fewer than 1,000 field observations, which reduces noise but also reduces coverage of small sites.
Use this report to choose a floor, not a finish line. A host with a strong LCP cohort gives you a better starting point. It does not excuse a 3 MB hero image or a chat widget that loads before the content.
The fix order that actually moves scores
- Measure field data. Use the Chrome UX Report or your own RUM. Do not optimize for a single lab run on a fast connection.
- Fix LCP assets. Compress and resize the hero image, serve AVIF/WebP, preload the LCP image, and remove render-blocking CSS or fonts from the critical path.
- Attack long tasks for INP. Profile the interactions that matter: menu open, add-to-cart, filter, and form submit. Defer or remove third-party scripts that block the main thread.
- Reserve layout space. Set width and height on images, ads, and embeds. Use font-display and a matched fallback to reduce swap shift.
- Then tune the host. Enable full-page cache, object cache, and a CDN; check PHP workers and database latency. This is the last 10–20%, not the first 80%.
Limitations
Field data is noisy and lagged. A site that fixed its LCP last week may still show the old distribution. The cohort is not a controlled experiment, and the cohort sizes per host vary. The measured figures reflect the Sep–Oct 2026 window; the method and the causal caution are the durable parts.