Site speed optimization makes pages load, respond and stay stable faster for real visitors. Google's Core Web Vitals set the targets: LCP 2.5 seconds or less, INP 200 milliseconds or less and CLS 0.1 or less, measured at the 75th percentile of page loads. We fix the causes and verify them in field data.
The three Core Web Vitals and their thresholds
Core Web Vitals are Google's three measures of real page experience. The thresholds come from web.dev:
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| LCP (Largest Contentful Paint) | When the main content, usually the hero image or headline, finishes rendering | 2.5 s or less | Over 4 s |
| INP (Interaction to Next Paint) | How quickly the page responds visually after a tap, click or key press | 200 ms or less | Over 500 ms |
| CLS (Cumulative Layout Shift) | How much the layout jumps around while loading | 0.1 or less | Over 0.25 |
A page passes when it hits the good threshold at the 75th percentile of page loads, measured separately for mobile and desktop. That means three out of four visits must be good, not your own visit on office Wi-Fi. INP replaced First Input Delay as a Core Web Vital in 2024, and many older speed fixes never addressed it.
Field data versus lab data
Two kinds of numbers get confused all the time:
- Field data comes from the Chrome User Experience Report (CrUX), which aggregates real Chrome users' visits. It is what Search Console's Core Web Vitals report and the top of PageSpeed Insights show, as a rolling average of the previous 28 days.
- Lab data comes from Lighthouse, a single simulated load on a throttled device. It produces the familiar 0 to 100 score and is excellent for debugging, but it is not what your visitors experience.
That is why a site can score 95 in Lighthouse and still fail Core Web Vitals in Search Console, or the other way round. We use lab tools to find causes and field data to judge success. CrUX only reports on pages and sites with enough public traffic, so smaller sites may only have origin-level data; we say so instead of guessing.
How the web is doing
The HTTP Archive Web Almanac 2025, based on CrUX data from July 2025, found that only 48% of mobile sites had good Core Web Vitals, up from 44% in 2024. Desktop sat at 56%. Looking at mobile metrics one by one, 62% of sites had good LCP, 77% good INP and 81% good CLS. In plain terms, more than half of mobile sites still fail Core Web Vitals, and LCP is the usual culprit. Passing is a real edge, not table stakes.
Common WordPress culprits
Plenty of Naples small business sites run on WordPress, and the slowdowns tend to repeat:
- Heavy page builders that wrap every element in layers of extra markup and load their full CSS and JavaScript on every page.
- Hero sliders and background videos that delay the largest element and hurt LCP on phones.
- Third-party scripts: chat widgets, booking embeds, review carousels, heatmaps and multiple tag managers, which block the main thread and drag INP.
- Unoptimized images: full-size camera files, no modern formats, no width and height attributes, and lazy loading applied to the hero image itself.
- Web fonts loaded from several families and weights, causing late text and layout shifts.
- Plugin sprawl, where each plugin adds its own assets site-wide.
When a theme or builder is the root cause, patching may not be enough, and a rebuild as an SEO-ready WordPress site can be the better long-term fix in effort and maintenance.
Hosting, caching and CDN
Server response time sits underneath LCP. Slow shared hosting, no page caching or an overloaded database add delay before the browser receives a single byte. We check time to first byte from several locations, page and object caching, PHP version and the CDN setup. A CDN (content delivery network) serves files from servers close to the visitor, which matters for Naples businesses whose seasonal customers browse from the Midwest and Northeast before they fly down. We recommend hosting changes only when the data shows the server is the bottleneck.
How we verify results in the field
Because field data is a 28 day rolling window, a fix shipped today is only fully reflected four weeks later. Our verification routine:
- Record the CrUX baseline for key URLs and the origin before any change.
- Ship fixes in batches and log the date of each.
- Check lab results immediately to confirm the fix works technically.
- Re-check CrUX and Search Console once a full 28 day window has passed since the last fix.
- Report pass or fail per metric, per device, at the 75th percentile.
Speed is one part of a broader technical SEO audit, and if you are unsure where to start, a free first look at your field data is a good first step.