a fast website: delivery speed and load speed are not the same thing
web · 2026-11-01 · 4 min
"i need a fast website" means two different things, and most conversations fail because nobody separates them. fast to build is a calendar promise. fast to load is a technical measurement. a site can be delivered in a week and take four seconds to open, or take a month and open in 600 milliseconds.
the first is a sales claim. the second is the one visitors feel and google measures.
fast to build
a week, a month, six months: this depends on decisions, content and integrations. it is a project management number. it says nothing about what the browser does when someone arrives.
an ai builder is fast to build. it is not automatically fast to load: generated pages often carry a framework, a font set, analytics, chat widgets and uncompressed images nobody chose.
fast to load
this one is measurable in three numbers.
- lcp (largest contentful paint): when the main content appears. good under 2.5 s, poor over 4 s.
- inp (interaction to next paint): how quickly the page reacts to a tap. good under 200 ms.
- cls (cumulative layout shift): how much the page jumps while loading. good under 0.1.
google measures these on real visitors, not on your laptop. that is why a site can score 95 in a lab test and still feel slow on a phone in a shop with one bar of signal.
measure yours in three minutes
- open pagespeed insights and paste your url. read the mobile tab, not desktop.
- look at the field data first (real users, last 28 days). if it is missing, you have too little traffic, and the lab data is the only signal you have.
- in the opportunities list, ignore the score. read the three biggest transfer sizes and the three longest tasks.
if the page transfers more than 1 mb, the problem is weight. if the main image appears late, the problem is the hero. if tapping a menu takes half a second, the problem is javascript.
the usual culprits, in order of frequency
images. a 4 mb photo from a phone, served as jpg, at full resolution, inside a 600 px box. the fix is resizing, webp or avif, and correct dimensions.
fonts. two or three families, each with four weights, preloaded. a display font can easily be 300-700 kb. the fix is subsetting, fewer weights, and font-display swap.
javascript. plugin after plugin, tag after tag. every third-party widget is a request, a parse and a risk. the fix is deleting, not optimising.
hosting and caching. a cheap shared server in another continent, html with no cache headers, no compression. the fix is boring and effective.
plugins. on wordpress, a page builder plus ten extensions can produce a 2 mb page before any content. the fix is fewer plugins or a static build.
what a performance budget looks like
before building, agree on numbers: html under 100 kb, css under 60 kb, js under 150 kb, hero image under 200 kb, lcp under 2.5 s on a mid-range phone. then measure in the build, not in the final week.
on this site the budget is partly enforced: pages are pre-rendered, metadata and links are checked by the build, and the contrast gate fails the release. it is not perfect. the display font is still heavier than it should be, and it is the next item on the list. saying it is cheaper than pretending.
is a fast site always a better site?
no. speed is a constraint, not a goal. a fast page that does not answer the question is still useless. but a slow page loses people before they can judge the content.
does speed affect google ranking?
core web vitals are a confirmed ranking input, but a small one compared with relevance and content. treat speed as conversion work first and seo work second.
how much does it cost to fix a slow site?
less than a new site, usually. an audit and a focused week of fixes (images, fonts, scripts, caching) often recovers most of the gap. a rebuild is justified when the platform itself is the weight.
if you want the numbers for your site, book a 30-minute call or read how to speed up a website and the core web vitals notes for parma.