Start with server response time
Before a browser can paint anything at all, your server has to answer. That first response, measured as time to first byte, happens before any front-end optimisation can possibly help.
If your server takes two or three seconds to answer, no amount of image compression or script deferral will save you. You would be optimising the last twenty percent of the problem while ignoring the first eighty. Measure it first: PageSpeed Insights reports it, and so does your browser’s network tab.
If that number is bad, the conversation is about hosting, PHP version, database queries, and whether something on the site is doing expensive work on every single request.
When your WordPress site is slow, caching is not always the answer
A page cache stores the finished HTML so WordPress does not have to rebuild it for the next visitor. That is genuinely valuable, and it is why a caching plugin sometimes transforms a site overnight.
But a WordPress site is slow for any number of different reasons, and caching addresses exactly one of them: the work of generating the page. It does nothing about a four megabyte hero image, a plugin loading its stylesheet on every page, or render-blocking JavaScript in the head. Those costs are paid by the browser after the cache has already finished its job.
Look at what every page is loading
This is the most common avoidable problem I see. A plugin you use on exactly one page registers its CSS and JavaScript site-wide, so every visitor to every page downloads assets for a feature they will never encounter.
Multiply that across eight or ten plugins and the page is carrying a great deal of code that does nothing. Auditing what actually loads, and where, usually finds more real improvement than any plugin setting screen.
Then measure the right three numbers
Google’s Core Web Vitals split the experience into three separate measurements, and they have completely different causes:
- LCP is how long until the largest thing on screen appears. Usually an image, a font, or a slow server.
- INP is how quickly the page responds when somebody interacts with it. Usually JavaScript.
- CLS is how much the layout jumps around while loading. Usually images without dimensions, or fonts swapping late.
Chasing a single overall score hides which of these is actually failing. Diagnose them separately and the fixes become obvious.
One self-inflicted problem worth knowing
Entrance animations hide an element until JavaScript runs. Apply one to your main heading and you have just delayed the largest element on the page, which is usually what LCP measures.
The site looks more polished and measures worse. Keep the biggest element on screen static and animate everything around it instead. That is exactly how the hero on this site is built.
Questions people ask about this
Will a caching plugin make my site faster?
Sometimes, and sometimes not at all. Caching helps when the work is in generating the page. If the problem is a slow server response, an oversized image, or a plugin loading assets on every page, caching will not touch it.
What counts as a good server response time?
Google suggests keeping time to first byte under roughly 800 milliseconds. Above about two seconds you have a hosting or application problem that front-end work cannot compensate for.
Do I need to delete plugins to make the site fast?
Usually not. The problem is rarely the number of plugins and almost always what they load and where. A plugin used on one page should not be loading its assets across the whole site.