Seven things that slow down almost every site.
When I look at a slow site, the same issues show up almost every time. Fixing them is usually less expensive than owners expect.
The same problems show up on almost every slow site. Different platform, different industry, different size, but it comes down to the same short list, in roughly the same order of severity. I have never opened a slow site and found a clever, mysterious problem. It is always the basics, and the basics are cheap to fix.
1. Unoptimized images.
Still number one, every time. Photos uploaded straight from a phone at 4000 pixels wide, served as JPEGs, dropped into a slot that is 400 pixels wide on screen. The browser downloads the full file anyway and shrinks it afterwards. On a listing page with 40 products, that is 40 oversized images loading at once while the visitor stares at a blank grid. The fix is boring and it works: resize images to the size they actually display, serve modern formats like WebP or AVIF, set width and height so the layout does not jump while they load, and lazy-load anything below the fold. A proper image setup handles most of this automatically once it is in place. I regularly watch a page drop from six seconds to under two on this alone.
2. Plugins and scripts nobody removed.
A chat widget from 2022 that nobody answers anymore. A heatmap tool from a campaign that ended last spring. An A/B testing script from a consultant who left. A second analytics tag someone added and forgot. Every one of these still loads on every visit, phoning home to a server you do not control and blocking the page while it does. I open the network tab, list everything the site loads, and ask the owner what each thing is for. Half the time nobody knows. Those get removed the same afternoon. The audit takes a few hours and the page is noticeably lighter by the end of the day.
3. No caching strategy.
Dynamic sites that could be mostly static are not. A homepage that changes once a week gets rebuilt on every visit. A product listing that updates once a day gets pulled fresh from the database hundreds of times an hour. The server repeats the same expensive work for pages that did not change. You do not need anything fancy. Browser caching so returning visitors reuse what they already downloaded, a CDN so files come from near the visitor instead of one server in Germany, and page caching for anything that need not be live to the second. On most sites this is the biggest server-side win, and it lowers the hosting bill too.
4. Fonts loaded the slow way.
Four font weights, pulled from an external service, with no preload, blocking the text from rendering until they arrive. It is on almost every slow site. Sometimes the text sits invisible for a full second while the browser waits for a font nobody would have missed. The fix is usually an hour of work. Self-host the fonts instead of loading them from someone else's server, preload the one or two weights you actually use, add font-display: swap so text shows immediately in a fallback and swaps when the real font is ready, and drop the weights you are not using. Nobody has ever complained that a page had one fewer italic.
5. No monitoring.
The scariest thing is not a slow site. It is a site that went down at two in the morning on a Friday and nobody noticed until Monday, when a customer emailed to ask if the company still exists. Every hour it was down was an hour of orders going to a competitor. Uptime monitoring is free, or close to it. A service pings the site every minute and messages you the moment it stops responding. Not having it is not a budget problem, it is negligence. It is the first thing I set up on any project, before I touch anything else, no exceptions.
6. Too much JavaScript for a simple page.
A brochure site or a straightforward webshop does not need megabytes of JavaScript, but plenty of them ship it anyway. A heavy theme, a page builder that wraps every button in five layers, a slider library for a slider that got deleted a year ago. The phone has to download all of it, parse it, and run it before the visitor can do much, and the phone is where most of your traffic is. I check how a site behaves on a mid-range Android over normal mobile data, not on a fast laptop on office wifi. That is the real test. Usually the fix is trimming what the theme loads, swapping a bloated builder for something lighter, and only loading the heavy parts on the pages that actually use them.
7. Hosting that cannot keep up.
The cheapest shared hosting puts your site on one machine with hundreds of others. When a neighbour has a busy day, your site slows down for reasons that have nothing to do with your site. I see businesses paying for their own premises and their own staff, then running the shop on five euros a month of hosting and wondering why it drags at lunchtime. You do not need the most expensive tier either. You need hosting that matches your traffic, sits near your customers, and does not fall over during your busiest hour. Moving from oversold shared hosting to something appropriate is often a same-day change with an immediate difference.
Most of these fixes take hours, not weeks. What they cost you to ignore is almost always higher than what they cost to fix.
Making a site faster without rebuilding it.
None of this is glamorous work and none of it means rebuilding your site. It is a checklist. Go through it in order, fix what you find, and most sites end up two to three times faster without a single new feature.