Most site speed advice is a list of thirty things. The list is not wrong and it is unordered, so people start with the item that is easiest instead of the one that matters, and finish with a marginally faster site.
The order below is roughly by size of effect. Do them in sequence and stop when the site is fast enough.
Zero: measure, and measure the right thing
Before changing anything, get a baseline. Otherwise you cannot tell which change helped, and you will keep all of them.
Test from a location near your visitors, twice. The first run is unrepresentative because nothing is cached yet.
And note what is actually slow. A slow first byte is the server generating the page. Slow rendering after that is the page's own weight. Those have completely different fixes, and most people optimise the second while suffering from the first.
One: caching, and it is not close
The largest single improvement available, usually by a wide margin.
Without page caching, every visit runs the application, queries the database and assembles the page from scratch. With it, the finished HTML is served directly.
Server-level caching beats a plugin, because the request never starts PHP at all. Use it if your hosting offers it, and do not run both. Two layers with different ideas about when to clear produce changes that appear for some visitors and not others. Caching layers walks through which layer does what.
On shared hosting this also raises capacity: a cached page does not occupy one of your limited concurrent PHP processes.
Two: images
Almost always the largest thing a page downloads, and usually several times larger than necessary.
Resize before uploading. A 4000-pixel photograph displayed at 800 pixels wastes the difference on every visit, and no plugin undoes that. Then serve WebP, and turn off the image sizes your theme does not use.
A compression plugin comes after those three, not instead of them. Optimizing images explains the sequence.
Three: the plugin doing something expensive
One plugin querying the database on every page load costs more than thirty that do nothing on the front end. The count is not the measure.
Find it rather than guessing: deactivate plugins in halves, measuring each time. It takes twenty minutes on a staging copy and it identifies the culprit exactly.
The usual suspects are sliders, page builders, "all-in-one" suites, and anything adding scripts to every page whether or not that page uses it. Vetting plugins walks through avoiding the next one.
Four: the database
Check one number before doing anything else here: the total size of autoloaded options, which is read on every request before the application knows what page it is serving.
Under 1 MB is fine, over 3 MB is a real problem, and the usual cause is plugins you removed leaving their data behind. Cleaning up the database explains the query.
Everything else database-related (revisions, transients, orphaned tables) matters less than that one figure.
Five: browser caching and compression
Headers telling browsers to keep assets, and compression so they arrive smaller.
Both are server settings, both take minutes, and neither helps a first visit, which is why they test poorly and matter in reality, since most sites have many returning visitors. Compression and cache headers goes into setting them.
Six: a CDN, if your audience is spread
A CDN reduces distance. If your visitors are all in one city, that distance is already zero and a CDN adds a layer for nothing.
If they are spread across countries, it is a real improvement and it also absorbs traffic that would otherwise reach your server. Choosing and setting up a CDN goes into the certificate mode that catches people.
Seven: the hosting plan
Last, deliberately.
A bigger server makes an uncached site with four-megabyte images cheaper to ignore rather than fixed. Every step above is free or nearly free; upgrading is recurring.
When caching is working, images are sized properly, no plugin is misbehaving, and the site is still at its ceiling during normal traffic; that is a real outgrown-the-plan situation and the upgrade is the right answer. Comparing the tiers explains it honestly.
The symptom that means something else
A site that is fast at night and slow in the afternoon is not slow: it is queuing.
Requests are waiting for a process to become free, which is a capacity ceiling instead of a code problem. Caching is the fix, because a cached page never occupies a process at all. Monitoring your hosting resources walks through confirming it.
A genuinely slow site is slow consistently. That distinction saves people from optimising code that is fine.
Change one thing at a time
The rule that makes all of the above work.
Measure, change one thing, measure again. Anything that did not help gets reverted rather than kept "just in case", those accumulate into a configuration nobody can reason about, and the next person inherits it.
Before changing anything, it is worth knowing what the score you are chasing actually measures. How to Measure Page Speed Properly deals with the difference between the lab result and what visitors experience.
A site with nothing executing skips most of this work entirely, provided three settings are right. There is more in How to Host a Static Site or Single-Page App Correctly.
Find the slowest pages rather than testing the home page
Optimisation usually starts on the page the owner looks at, which is rarely the page that is slow.
awk '{print $7}' ~/logs/example.com | sort | uniq -c | sort -rn | head -15
grep -c . ~/logs/example.com
Take the most requested pages and measure those, since a small improvement on a page served ten thousand times is worth more than a large one on a page served twice.
for p in / /shop /product/example /search?q=test; do
printf '%-24s %s\n' "$p" "$(curl -s -o /dev/null -w '%{time_starttransfer}' "https://example.com$p")"
done
Search results, filtered listings and account pages are the usual offenders, because none of them can be cached and all of them do real work on every request.
Separate the work from the waiting
Two sites can have identical response times for entirely different reasons, and the fix differs completely.
curl -s -o /dev/null -w 'dns %{time_namelookup} tls %{time_appconnect} ttfb %{time_starttransfer} total %{time_total}\n' https://example.com/
uptime; ps -eo state,comm | awk '$1 ~ /^D/' | wc -l
A long gap before the first byte with an idle machine means the server is waiting on something: a database query, an external service, a name lookup. A long gap with a busy machine means it is doing too much work.
The first is fixed by removing the wait or doing it in advance. The second is fixed by doing less or having more capacity. Applying the wrong one is how a month goes by with no improvement.
Confirm the change actually helped
Most optimisation work is never measured afterwards, so nobody knows which of the six changes was the one that mattered.
for i in $(seq 1 20); do curl -s -o /dev/null -w '%{time_starttransfer}\n' "https://example.com/?r=$i"; done \
| sort -n | awk '{a[NR]=$1} END {printf "medyan %.3f p90 %.3f\n", a[int(NR/2)], a[int(NR*0.9)]}'
Record that before and after each change, on the same page, at the same time of day. Discard the first run, since it measures a cold cache rather than the site.
Comparing the median and the ninetieth percentile together matters. A change that improves the median and worsens the tail has made the site feel less reliable, which visitors notice more than an average they never see. Measuring page speed properly goes into the method.