Speed reaches your rankings through two separate doors.
Most guides only show you one of them. The first is direct: Google folds a set of loading and stability measurements, the Core Web Vitals, into its page experience signal, so a page that paints late or shifts around while it loads carries a small ranking handicap. The second is quieter and usually the bigger of the two: a slow page bounces visitors back to the search results, shortens the time they spend reading, and eats into the crawl budget Google uses to decide how much of your site to index at all. Neither door makes speed the thing that outranks genuinely better content. Both are real, and the fix for both is the same one. That is where being fast by construction, rather than fast after months of tuning, changes the math, and it is the reason a database-free CMS like Devani opens at a near-perfect score instead of spending a year climbing toward one.
Speed has been in the algorithm longer than most people realize: a desktop signal since 2010, a mobile one since the 2018 Speed Update, and part of a broader page experience signal via Core Web Vitals since 2021. So "does site speed affect SEO" has been a yes for over a decade. The more useful question is how much, and through which mechanism, because the two channels behave differently and you fix them differently.
Google is careful to downplay the direct channel. Its own search advocates call Core Web Vitals a tiebreaker rather than a heavyweight: when two results are otherwise close on relevance, links, and intent, the faster, more stable one gets the nod. A fast site will not outrank a page that answers the query better. But at the margins where most competitive keywords are actually decided, page experience is the thumb on the scale, and a page that fails the vitals outright can be held back no matter how good the content is.
Three vitals, and the metric feeding all of them.
Core Web Vitals is not a single speed score. It is three specific measurements of how a real page feels while it loads and responds, each with its own threshold.
LCP: how fast the main thing appears
Largest Contentful Paint clocks the moment the biggest visible element, usually a hero image or headline, finishes rendering. Good is 2.5 seconds or less; over 4 seconds is a fail. It is the metric most tied to that gut sense of "this page is slow," and the one a heavy theme or an uncompressed hero image wrecks first.
INP: how fast it answers a tap
Interaction to Next Paint replaced First Input Delay in March 2024 and measures the lag between a click, tap, or keypress and the screen actually updating. Good is under 200 milliseconds. Bloated JavaScript is the usual culprit: the page looks ready, then freezes for a beat when you touch it.
CLS: how much it jumps
Cumulative Layout Shift scores how far content moves around as the page assembles, the reason you tap a button and hit an ad instead. Good is 0.1 or less. It is not about raw speed at all, which trips people up: a fast page with an image that loads without reserved space still fails this one.
TTFB: how fast the server answers
Time to First Byte is not a Core Web Vital itself, but it sits upstream of all three. It measures how long the server takes to send the first byte of the page. A database-driven CMS on budget shared hosting spends this time assembling the page from queries; a site served as static files barely spends it at all.
The score you see is not the score you rank on.
This is the single most misunderstood part of site speed and SEO, and getting it wrong wastes real effort. When you run a page through PageSpeed Insights and get a 0-to-100 number, that is lab data: a synthetic test on a simulated device in one moment, built for debugging. It is genuinely useful for finding what to fix, but Google does not rank on it. The ranking signal comes from field data: the Chrome User Experience Report, which aggregates the vitals from actual Chrome visitors to your page, taken at the 75th percentile over a rolling 28-day window. In plain terms, three-quarters of your real visitors need to hit "good" for the page to pass.
The practical fallout: a page can flash a 95 in the lab and still fail for the half of your audience on mid-range phones. Chase the field data, and use the lab score only as the map that tells you where to dig. Because that field data is collected from the mobile-indexed version of your site under mobile conditions, the mobile number is the one that decides this, not the flattering desktop figure.
The desktop score is the one everyone screenshots. The throttled mobile score is the one Google actually ranks on.
Where the line sits, for each measurement.
Every vital has a good, a needs-work, and a poor band. To pass the assessment a page has to clear all three at the 75th percentile of real visits.
| Metric | Good | Needs work | Poor |
|---|---|---|---|
| LCP (loading) | 2.5s or less | 2.5s to 4s | over 4s |
| INP (responsiveness) | 200ms or less | 200ms to 500ms | over 500ms |
| CLS (visual stability) | 0.1 or less | 0.1 to 0.25 | over 0.25 |
| PageSpeed score (lab only) | 90 to 100 | 50 to 89 | 0 to 49 |
Read the last row carefully. The 0-to-100 PageSpeed score is a lab convenience, not a Core Web Vital and not the ranking input. A 100 is worth having because it usually means the field vitals will follow, but it is the vitals, measured on real visitors, that Google reads.
The bigger effect never shows up in the vitals.
Even if page experience were worth nothing to the algorithm, speed would still move your rankings, because it moves the human behavior the algorithm watches. Google's own research found that 53 percent of mobile visits are abandoned when a page takes longer than three seconds to load. Every one of those is a visitor who hit the back button and returned to the search results, which is exactly the pogo-sticking pattern that tells Google your result did not satisfy the query. Slower pages also lower dwell time and conversions across the board, and a widely cited figure puts every 100 milliseconds of improvement at roughly a 1 percent lift in conversions.
There is a crawl angle too, mostly for larger sites. Googlebot works within a crawl budget, and a slow server means it fetches fewer of your pages per visit, so new and updated content takes longer to get indexed. On a ten-page brochure site this is a non-issue; on a few-thousand-page site it is the difference between fresh content ranking this week and next month. A fast server response, the TTFB from earlier, is what buys back that budget.
Fast by construction beats fast by maintenance.
Here is the part the tool vendors skip. On most platforms, a good score is a project you re-run forever. On a database-free one, it is the default you would have to work to lose.
The reason a typical WordPress or drag-and-drop builder site fights this is structural, not a knock on the software. Every page is assembled on request from a database, then layered with a theme and however many plugins each add their own CSS and JavaScript. Speed becomes a range you manage with a caching plugin, a CDN bolt-on, and image tooling, and it drifts back down every time a plugin updates. That is the whole story behind why your WordPress site is slow even after you thought you had fixed it. A representative cold PageSpeed run on a normal WordPress build lands around 63 on desktop and 47 on mobile, with a largest contentful paint north of 7 seconds on the phone: a Core Web Vitals fail on the exact channel Google ranks. A lean build on strong hosting can beat that, but the tuning is continuous work against the platform's defaults, and the WordPress review covers why that maintenance job never really ends.
A database-free CMS removes the thing generating the work. Devani stores the whole site as plain files, renders clean semantic HTML, auto-compresses images to WebP, and serves everything statically from a CDN. No database query sits on the critical path, so TTFB is minimal, and no plugin stack adds weight, so there is nothing to tune back down later. The result is roughly 100 out of 100 Lighthouse out of the box: a real devani.io page posts a desktop performance of 100 with an LCP around 0.7 seconds, and a production site built on it turns in a throttled-mobile LCP of about 1.8 seconds, comfortably inside the 2.5-second "good" line where most default builds are still climbing. You did not tune any of that; it is what the architecture produces when you leave it alone.
A typical CMS or builder
Fast if you keep working at it.
- ✓ Can reach good vitals with a caching plugin, a CDN, and image tuning
- × Every page assembled from the database on request, so TTFB and speed are a range
- × Each theme or plugin adds CSS and JavaScript; scores drift back down over time
- × Cold mobile builds commonly fail LCP, the exact vital Google ranks on
Devani
Fast because there is nothing slowing it down.
- ✓ Database-free: plain files served statically from a CDN, so TTFB is minimal by design
- ✓ Images auto-compressed to WebP, clean semantic HTML, no plugin weight to accumulate
- ✓ Roughly 100/100 Lighthouse out of the box, desktop LCP near 0.7s, no tuning step
- × Architecture removes the usual mistakes, but not all of them: load a page with uncompressed video and even a static site will drag
It is free and open-source, self-hosted on ordinary hosting for about $5 a month, or live in under a minute on the managed free tier if you would rather not run a server. A full site can be built with AI in 10 to 15 minutes, too, because Devani is MCP-native: you connect your own ChatGPT or Claude account and the assistant edits content and layout inside the visual builder. WordPress is catching up on that last point, to be fair. WordPress.com shipped an MCP integration and the Vibe AI plugin arrived by mid-2026, but both work well only inside the block editor. The distinction is inside the builder versus alongside it.
What actually moves the numbers, in rough order of payoff.
- Fix your images first. They are the biggest LCP offender by far. Serve modern formats like WebP or AVIF, size them to how they actually display, and lazy-load anything below the fold. This alone rescues most failing pages.
- Cut render-blocking CSS and JavaScript. Defer or async non-critical scripts, minify what is left, and strip code you are not using. Heavy JavaScript is the usual reason INP fails even on a page that looks quick.
- Put a CDN in front of everything. Serving assets from an edge location near the visitor is the cheapest large win for TTFB and LCP, especially for an audience spread across regions.
- Reserve space for anything that loads late. Give images, embeds, and ads explicit dimensions so the layout does not jump. This is the entire fix for most CLS failures, and it is nearly free.
- Improve the server response. Caching, compression like Gzip or Brotli, and hosting that is not the cheapest shared tier all pull TTFB down, which lifts every metric downstream of it.
- Measure the field, not just the lab. Check Core Web Vitals in Search Console or the Chrome UX Report, where the real-visitor data lives, and treat the PageSpeed lab score as the tool that tells you where to dig.
How fast should a website load for SEO?
Aim for a Largest Contentful Paint of 2.5 seconds or less at the 75th percentile of real visits, which is Google's "good" threshold and the one that matters for ranking. In overall terms that means the main content visible in under about 2.5 seconds and full interactivity shortly after. On the lab PageSpeed score, 90 or above is "good," but treat that as a proxy: it is the field vitals, not the lab number, that Google reads.
Is page speed actually a Google ranking factor?
Yes. It has been a desktop signal since 2010, a mobile one since the 2018 Speed Update, and part of the page experience signal via Core Web Vitals since 2021. The nuance is weight: Google describes it as closer to a tiebreaker than a heavyweight, so speed will not lift weak content over a better answer, but between two comparable pages the faster, more stable one wins, and a page that clearly fails the vitals can be held back.
Does a perfect PageSpeed Insights score guarantee better rankings?
No. The 0-to-100 PageSpeed score is lab data, a synthetic test Google does not rank on. The ranking input is field data from real Chrome visitors, collected over 28 days at the 75th percentile. A 100 in the lab is a good sign the field vitals will pass, but a page can score high in the lab and still fail for real mobile visitors, and content relevance and links still outweigh speed either way.
What is the difference between field data and lab data?
Lab data is a synthetic test run on a simulated device in a controlled moment, which is what PageSpeed Insights and Lighthouse produce; it is for debugging. Field data is measured from your actual visitors through the Chrome User Experience Report and aggregated over a rolling 28-day window. Google ranks on the field data. Use the lab score to find and fix problems, and confirm the fix in the field.
Does site speed matter more on mobile?
Effectively yes. Google indexes the mobile version of your site and collects field vitals under mobile conditions, so the throttled mobile numbers are what decide the page experience signal, not the easier desktop figures. Mobile visitors are also the ones most likely to abandon a slow page, so the indirect behavioral hit lands hardest there too.
The clean way to hold all this in your head: site speed is rarely the reason a page ranks first, and often part of the reason a good page does not. Fix it because the page experience signal is a real tiebreaker, because a slow page hands your visitors back to Google, and because faster pages convert better once they arrive. The only question worth settling early is whether speed will be an ongoing maintenance job or something the platform just does. Fast by construction is the cheaper answer over any real timeframe.
See what a near-perfect score looks like by default.
This blog runs on the database-free CMS described above. Open a page, run it through PageSpeed Insights yourself, and check the LCP before you decide speed has to be a project.