Splinx Studio
Almost every client who comes to us with a slow website has already tried the same three things: a caching plugin, a cheaper image compressor, and a hosting upgrade. Usually none of it helped much, because none of it touched the actual problem.
Speed isn't a setting you turn on at the end. It's the sum of decisions made much earlier, and here they are roughly in the order they matter.
1. How much stuff the page loads at all
This is the whole game, and everything else is a footnote. A page that ships 400KB will beat a page that ships 4MB on any connection, any device, any host.
The weight usually comes from a small number of familiar places. An image exported straight from a camera or a design tool at four times the size it displays. A slider library, a popup library, an animation library and a font loader, all pulled in for one effect each. Six tracking scripts nobody has reviewed since 2021. A framework brought in to render a page that could have been plain HTML.
The fix is boring and it works: ship less. Every kilobyte you never send is a kilobyte you never have to optimise.
2. Images, in the right size and format
Images are typically most of a page's weight, and they're the easiest thing to get badly wrong. Three rules cover most of it.
- Export at the size it will actually display, then roughly double it for high resolution screens. Nothing more.
- Use a modern format like WebP. It's usually a third of the size of a PNG with no visible difference.
- Load images below the fold lazily, and give the browser the width and height so nothing jumps around while it loads.
That last point matters more than people expect. A page that visibly shuffles as it loads feels slow even when the numbers say it's fine.
3. What blocks the first paint
The browser can't show anything until it has fetched and understood the things you told it were essential. Every stylesheet in the head is a blocker. Every script without a defer or async attribute is a blocker. Fonts imported from inside CSS are worse, because the browser can't even start fetching them until the CSS has arrived and been parsed.
Most "slow" sites are not doing too much work. They are doing the right work in the wrong order.
Link your fonts directly in the HTML so they download in parallel. Open early connections to any domain you know you'll need. Defer anything that isn't required to draw the first screen. This one reordering often takes a second off a page without removing a single feature.
4. Fonts
Custom fonts are worth having and they're also a common cause of a page sitting blank for a beat. Limit yourself to the weights you genuinely use, because each one is a separate download. Use a display setting that shows a fallback immediately rather than hiding your text while the file arrives. If a font is only used in one small place, ask whether it's worth the trip at all.
5. Hosting, and where it sits
Hosting matters less than most people believe, right up until it doesn't. If your server is in one country and your customers are in another, every request pays for that distance. A content delivery network fixes it by serving copies from somewhere near the visitor, and for a static site that's usually free.
What hosting can't fix is a heavy page. A fast server delivering 5MB is still delivering 5MB.
How to check it honestly
Test on a mid range Android phone on mobile data, not on your laptop on office wifi. That's the experience most of your visitors are actually having. Then run a proper audit, look at how long it takes for the largest thing on screen to appear, and see how much the layout moves while loading.
If a site takes more than about three seconds to become useful on that phone, you're losing people who will never appear in any report, because they left before the analytics script finished loading.