Page Speed Sins Most Agencies Leave Behind (And Why)
A site can look quick on launch day and still be carrying a slow-motion disaster underneath. Most agencies hit publish, hand over the keys, and move on. The performance problems they leave behind are not always obvious , they do not throw errors, they do not break anything visibly. They just quietly eat into your load times, your Core Web Vitals scores, and eventually your rankings. These are the ones that get missed most often, and why they tend to stick around.
On this page
Uncompressed Images That Nobody Went Back to Check
Images are the single biggest culprit on most sites. An agency builds the pages, the client uploads their own photos later, and nobody ever reviews what gets added. A raw PNG from a camera can sit at four or five megabytes and serve at full resolution on a screen that only needs a fraction of that. It adds seconds to load time on mobile, and it compounds with every new page added.
The fix is not glamorous. It is a proper compression step baked into the workflow, or a server-side conversion to WebP. What most agencies skip is setting this up so it happens automatically. Without that, it falls through the cracks the moment they stop being involved.
Render-Blocking Scripts Left in the Wrong Place
Every script that loads in the <head> of your page delays everything visible to the user. The browser hits that script, stops, downloads it, processes it, and only then carries on rendering what you can actually see. That pause is called render-blocking, and it directly affects your Largest Contentful Paint score.
Agencies will often load analytics scripts, chat widgets, and third-party tools this way because it is the default and nobody has pushed back on it. Moving scripts to load asynchronously, or deferring them until after the main content is visible, is a straightforward change. But it requires someone to audit every script on the page, understand what each one does, and judge what can safely wait. That takes time agencies rarely bill for after handover.
Object Cache That Creates More Problems Than It Solves
Object caching sounds like a sensible thing. Cache the database queries, serve results faster, done. In practice, on a standard WordPress site without heavy repeated queries, it often works the other way. Cached requests can serve stale data in ways that are hard to spot, and the overhead of maintaining the cache layer can actually slow responses down rather than speed them up.
In our experience, object cache tends to cause quiet, unseen issues on general WordPress sites. It is genuinely useful on WooCommerce stores running complex product queries, but on a brochure site or a blog it adds complexity for questionable gain. The problem is that agencies often install it as a blanket performance measure and never revisit it. If you have noticed odd caching behaviour or inconsistent page rendering, this is worth checking first.
No Attention Paid to TTFB
Time to First Byte is the gap between a browser requesting your page and the server beginning to respond. If that gap is over 600 milliseconds, everything downstream suffers regardless of how well-optimised your front end is. A slow server response is a bottleneck at the source. No amount of compression or script deferral makes up for a host that takes too long to wake up.
Most agencies pick hosting based on price or familiarity, not on measured server response times. The result is sites sitting on shared hosting that crawls under load. If you want to understand what is actually happening at the server level, a slow TTFB is often the root cause that everything else gets blamed for.
Third-Party Scripts Nobody Audited
Every third-party embed adds a network request, often to a server you have no control over. A Facebook pixel, a live chat widget, a HubSpot tracking snippet, an embedded YouTube video. Each one adds latency. On a page with four or five of these, you can be looking at an additional two to three seconds of load time on a slow connection, and none of that shows up in a basic test.
The honest truth is that some of these tools are genuinely needed. But a lot of them get installed during a campaign or a trial and then just stay there. An audit every few months of what is actually loading on your pages, and what is still earning its place, is the kind of practical maintenance that moves real Core Web Vitals scores rather than just surface-level ones.
Why Agencies Leave These Problems Behind
Agencies are not always cutting corners deliberately. A lot of this comes down to how the work is scoped. Performance is checked at launch, the scores look acceptable, and the project closes. What happens to the site over the next twelve months, as content grows and plugins accumulate, is outside the scope of what was agreed.
Solo technical work tends to look at this differently. There is nobody to pass the awkward jobs to, so going underneath the surface rather than just checking what is visible at launch is simply how the work gets done. Choosing who builds and maintains your site matters more than most people realise. What to actually look for in a web design agency is worth reading before you commit to anyone.