Why a site feels slow: common PHP and WordPress causes

When an owner says “the site is slow”, it is almost never one magic fix. It is usually a mix of small issues that together cost seconds and fail under peak traffic.

Below is what I see most often on PHP and WordPress projects — practical, not theory for theory’s sake.

1. Heavy SQL queries

Catalogs, filters, “related items”, admin reports — easy N+1 and full table scans. The page feels fine in quiet hours and falls apart during promotions or concurrent traffic.

What I do: inspect slow queries, indexes, batch instead of one-by-one selects, cache where data changes rarely. Sometimes a surgical fix is enough — no full catalog rewrite.

2. Plugins and “everything included”

On WordPress, slowness often comes not from “the CMS itself” but from a dozen plugins each pulling scripts, calling remote APIs and heating up admin. Page builders and heavy analytics on every page hurt especially hard.

Simple approach: keep what the business really needs, remove or replace the rest with thin custom code. A custom theme without extras is usually faster than a universal Swiss-army theme.

3. Images and static assets

4–8 MB originals, no WebP, no lazy load, wrong sizes — classic. The page is heavy before PHP even thinks.

Fixes fast: compression, proper srcset, static cache on CDN/server, fewer fonts and header scripts.

4. Missing cache where it belongs

Not every site should be “fully page-cached”. But public landings, cards, lists and HTML fragments that do not change every second waste PHP and MySQL without cache.

Do not break account areas and carts: full-page cache for the public contour, object/fragment cache where logic is denser.

5. Peak load

A site can look fine on a normal day and die during a sale. Then we look at query queues, DB locks, external APIs (payments, CRM), hosting limits and what can move to background jobs.

How I usually start

1. Reproduce: which page, what load, logged-in or not.
2. Measure: TTFB vs static download — different worlds.
3. Find the top three bottlenecks, not “rewrite everything”.
4. Fix by impact and risk.

If a production site already stalls on real scenarios — write me. Often it improves without a from-scratch project.