The email says the site feels a bit slow, and we'll tidy performance after launch. After launch never comes. A slow website is a product problem, not a later pass — three seconds on a phone is where people leave, and they do not write to tell you.
I treat this as website work, not a plugin at the end. The brief I write before I quotehas to name the wait, or the range is fiction. If you haven't named whether it's a website or a web product, stop — a slow brochure and a slow SaaS are different jobs. Both still lose people.
What a slow website actually costs
Not a badge. Not a developer argument. A missed call, a booking that never starts, a search ranking that drifts. You feel it as "leads are quieter this quarter" and hire a copywriter.
- 01
They leave before the page is useful
A phone on a train. Three seconds of spinner. The next search result is already loading. You never hear about it. There is no angry email. There is just a quieter inbox.
- 02
Search quietly stops sending people
Google is not grading your palette. A slow site ranks worse, then the content you paid to write has nobody to read it. You notice as a flat line, months later, and blame the copy.
- 03
It looks fine on your laptop
Office wifi, a huge screen, the page already cached. That is not the customer. If you have to say "it's fast for me," it is slow for them.
I have a number because I was paid to get one. A content-heavy consulting site went from about three seconds to about 450 milliseconds — same words, same Figma, a frontend that stopped making the phone wait. That is in selected work. The lesson is not the tool. It is that the wait was the product. Treating it like paint is how it stayed slow.
Why website speed belongs in the first version
"We'll add performance later" is how you ship a demo that looks finished on a cinema display. A first versionis a stranger finishing the job on a URL that stays up. If the job is "understand us and enquire," the page has to arrive. Later is how every hard part gets postponed until there is a brand to protect and a redesign to sell.
Rendering, images, caching, a CDN — these are not a personality. They are how the HTML gets to the phone. Put them in the build the way you put a domain in the build. The cheap mistakes I keep finding in Next apps — a client boundary too high, images with no size — are written down in the App Router notes. They are afternoons. They are also the opposite of a later pass: you either do them before people arrive, or you pay in silence.
What I actually fix on a slow website
I do not start with a new palette. I start with what the phone downloads before anyone can read. Most of the time the design can stay. The wait cannot.
- 01
The images
Unsized photos, a 4MB hero, a gallery that loads every slide at once. The page jumps. The phone pays. This is afternoon work with a month of payoff — not a redesign.
- 02
The JavaScript the page does not need
A client boundary too high in the tree. A slider library on a page with no slider. The browser downloads a product to show a brochure. Cut it. The design can stay.
- 03
Caching and the CDN
The second visit should be cheap. A content-heavy site that hits origin every time is a hosting bill and a wait. This belongs in production, not a plugin you toggle after launch.
Search rides the same work. Titles, structured data, a page Google can read without executing a novel — that is not a separate SEO retainer you buy when the site is already late. If the HTML is empty until JavaScript wakes up, you are hiding from the crawler and from the customer at the same time.
Later pass
Design ships. Speed waits
A score you screenshot. A wait you never measure on a phone.
In the build
The wait is a requirement
Images, rendering, cache. The page is useful before anyone compliments the type.
When a slow website needs a rebuild
Not always. Pretending every slow site needs a new brand is how agencies sell a rewrite. Most of the time this is a takeover: keep Monday running, cut what the phone downloads, ship behind the same URL. A rebuild of the frontend is earned when the stack cannot tell the truth.
- 01
The template is the product
A theme with twenty plugins, each one a request. You cannot make that fast without lying. Replace the stack. Keep the words and the URLs if they rank.
- 02
The page cannot ship without a pile of client code
Every route waits on a bundle that has nothing to do with the paragraph on screen. Repair is fighting the architecture. Then a rebuild of the frontend is earned — not a new brand, a new way to send HTML.
- 03
Nobody can deploy a one-line fix
If a compressed image takes a ticket, a vendor, and a week, speed will never be in the build. Ownership first. Then the pass. A zip file with no deploy is not a website.
If it takes three seconds on a phone, the site is not finished. A later pass is a story you tell so the launch email can go out.
If you're staring at a URL that feels heavy, send that — tell me what you're building, or just the live site. Wrapping it in an app will not save it; the website has to be enough first. The rest of slow websites is that wait from different angles.
