Speed advice has a long shelf life and a short fact-check. Half of what gets repeated in forums and sales pages dates from an era of slower servers, smaller images and no HTTP/3, and the other half was a marketing line before it became folklore. The result is that people spend money and weekends on fixes that do nothing, while the real cause sits untouched in a media library.
Below are seven claims I hear from customers in support queues, with a verdict for each and the reasoning behind it. Some are plain myths, some are partly true, and one is true often enough that you should check it before dismissing it. Where a claim comes down to measurement, I say what to measure and how.
A rule that covers most of the page: find out where the time goes before you change anything. A site that takes six seconds to become usable has a specific reason, and that reason is rarely the one on the sales page for the next plan up.
1. A CDN is only for big sites
Myth
CDNs began as an expensive service for large publishers, but free and cheap tiers are now common. A small blog with international readers will see faster loads and less strain on its server, and gets some protection from abusive traffic as a side effect.
It does add a layer to understand. Misconfigured encryption modes and stale cached pages are the two classic headaches, so set it up deliberately.
The reason a CDN helps a small site is physics rather than size. A visitor in Sydney requesting a page from a server in Frankfurt waits for every round trip across the planet: the DNS answer, the TCP and TLS handshakes, the request, and then each file in turn. Each round trip costs somewhere around 250 to 300 milliseconds in that case. A CDN keeps copies of your images, stylesheets and scripts on servers close to the visitor, so those trips become short ones. The page itself may still come from Frankfurt, but the thirty or so files it references no longer do.
The second benefit is load. Every image served from the CDN is an image your own server did not have to read from disk and send out. On shared hosting, where your CPU and memory allowance is a fixed slice, that matters more than it would on a large dedicated machine. A site that falls over when a post gets shared on social media often survives it once static files are offloaded.
The two headaches mentioned above are real. The first is the encryption mode: if the CDN talks to your origin over plain HTTP while the visitor sees HTTPS, you can end up with redirect loops, because your server keeps redirecting to HTTPS and the CDN keeps asking again over HTTP. The fix is to use the full verification mode, with a valid certificate on the origin. The second is stale content. If you change a stylesheet and the CDN keeps handing out the old one, visitors see a broken layout until the cache expires. Using versioned file names (style.css?ver=4.2) or purging the cache after a deployment avoids it.
2. A bigger plan will fix a slow site
Usually a myth
Slow sites are most often slow for reasons that hardware does not fix: huge unoptimised images, dozens of plugins, uncached dynamic pages, slow third-party scripts, or database queries that scan whole tables.
There are cases where you truly are out of CPU or memory and a larger plan helps. The way to find out is to measure first, because if the cause is a 4 MB hero image, the extra RAM will make no difference.
The distinction to draw is between a slow server and a heavy page. A slow server shows up as a long wait before the first byte arrives. A heavy page shows up as a quick first byte followed by a long download and a long render. Upgrading the plan only touches the first kind. You can tell them apart with one command:
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s total: %{time_total}s size: %{size_download} bytes\n" https://example.com/If time to first byte is under about 0.6 seconds on an uncached request and the total is several seconds, the server is coping and the page is the problem. If the first byte takes two seconds or more, something on the server side is slow, and the next question is whether it is starved of resources or merely badly used. Hosting control panels usually show CPU, memory and process counts for the account. If those graphs sit at the ceiling during slow periods, a larger plan is a reasonable purchase. If they sit at ten per cent, it is not.
Real cases of a plan being too small do exist. A WooCommerce shop with several thousand products, a membership site with logged-in users who cannot be cached, or a forum during a busy evening will all consume memory in proportion to concurrency. Moving from a basic shared plan to a VPS can help there, but only after the obvious waste has been removed, otherwise you are paying more to run the same inefficiency.
The cheap fixes come first: resize images to the dimensions they are displayed at, convert large photographs to WebP or AVIF, remove plugins that nobody uses, and check whether PHP is on a current 8.x release, which is noticeably faster than 7.x for the same code.
3. A caching plugin fixes any slow site
Myth
Caching removes repeated work for pages that are the same for everyone. It does little for the first visit after the cache is cleared, for logged-in users, or for slowness caused by large images and heavy scripts that the browser must download anyway.
It is usually the best first step, and rarely the whole answer.
To see why, follow what WordPress does without a cache. For every request PHP starts, loads the core files and every active plugin, runs a few dozen database queries, assembles the HTML from the theme templates, and sends it. A page cache stores the finished HTML as a static file, so the next visitor gets that file straight from disk without PHP or the database being involved. On a typical blog this takes the server's share of the response from several hundred milliseconds to a few tens.
Now the limits. The first visitor after a purge still pays the full cost, which is why some plugins offer to preload the cache by crawling your sitemap. Logged-in users, shopping carts, and checkout pages are deliberately excluded from page caching because they differ per person, and these are often precisely the pages that feel slow. Search results and filtered product listings generate an effectively unlimited set of URLs, so they seldom stay warm.
And caching does nothing about weight. If the cached page references a 3 MB slider image and four tracking scripts, the browser still downloads and runs them. A fast server delivering a heavy page is still a slow experience, only with a shorter initial wait.
Object caching (Redis or Memcached, where your host offers it) helps the uncached cases by remembering database results between requests. It is the right tool for dynamic sites, but again it addresses server time and not page weight.
- Install one page cache plugin, not two. Competing caches fight each other and produce confusing results.
- Test the site logged out, because administrators are normally served uncached pages.
- Look for the cache header or a comment at the end of the page source that says the page was served from cache.
- Only then compare timings before and after.
4. More plugins always means a slower site
Partly true
What matters is what each plugin does. A tiny plugin that adds one function costs almost nothing. A single large one that loads scripts on every page and runs queries on each request can slow a site more than ten small ones.
Measure rather than count. Disable suspects on a staging copy and compare timings.
The costs a plugin can add fall into three groups. The first is PHP execution: its code is loaded on every request, whether or not that request uses it. The second is database work: some plugins add queries to every page, and a few store large serialised blobs in the options table that WordPress loads on every request because they are marked autoload. The third is front-end weight: stylesheets and scripts enqueued site-wide, even on pages where the feature does not appear. A contact form plugin that loads its scripts on every page when the form exists on only one is a common offender.
The plugin count still has a real cost in one respect: maintenance. Fifty plugins means fifty places for an update to break something and fifty authors who might stop supporting their work. That is a security and reliability argument more than a speed one, but it is a reason to delete anything you do not use.
Query Monitor is the standard free tool for finding the culprits. It shows, per request, which plugins ran the slowest queries and how many queries there were in total. A healthy small site might run 30 to 60 queries per uncached page; if you see several hundred, someone is doing something expensive. For the front-end side, the browser's developer tools (Network tab, sorted by size) show which files load and which plugin's folder they came from.
5. A CDN replaces good hosting
Myth
A CDN speeds up static files and shields your server from some traffic, but dynamic pages still come from your origin. If the origin is slow, uncached pages stay slow.
Think of a CDN as an amplifier for a decent server, not a substitute.
The key phrase is "dynamic pages". A CDN is good at serving files that are identical for everyone: images, CSS, JavaScript, fonts, downloads. A WordPress page generated by PHP is not in that category by default. The CDN receives the request, finds nothing cached for it, and passes it to your server, which then does all its usual work. The visitor gets the page a little later than they would have without the middle step, not sooner.
Some providers can cache full HTML pages at the edge, which does take the origin out of the picture for anonymous visitors. It requires rules to bypass the cache for logged-in users and carts, and it requires a plan for purging pages when content changes. Done well it is very effective. Done carelessly it shows one customer another customer's basket, which is the sort of incident that ends up in a casebook entry.
There is also the matter of availability. If your origin is down, a CDN can keep serving cached copies for a while, which is helpful, but it cannot generate a new page or process an order. Anything that needs the database needs the server to be working.
So the order to work in is to get the origin healthy first: current PHP, a page cache, tuned images, a database that is not choking. Then add the CDN to deal with distance and bursts. Trying it the other way round makes a slow server look fast in tests that only fetch static files, and then it disappoints in real use.
6. A speed score of 100 is the goal
Myth
Test scores are guides, not targets. Chasing the number can lead to removing features visitors like, and different tools give different numbers for the same page.
Look at real loading times for real users, and fix what your visitors actually notice.
A speed test is a simulation. It loads your page from one location, on one emulated device and connection, usually once, and then applies a formula to the result. Run it three times and you will get three scores, sometimes ten points apart. Run it from two tools and the gap can be larger, since they use different test locations and different weightings.
A score also compresses very different problems into one number. Two sites can both score 72, one because of a slow server and the other because of a huge image, and they need opposite fixes. The useful part of the report is the list of specific findings underneath the score: which resource is the largest, what blocks rendering, how long the main thread is busy.
The temptation with a score is to game it. People defer every script, strip out fonts, and remove sliders, and sometimes break the checkout or the cookie banner in the process. A site that scores 98 but whose menu takes a second to respond has not been improved.
Better questions: how long does the main content take to appear for a typical visitor? Does the page jump around while loading? Does it react quickly when tapped? Those correspond to the metrics grouped as Core Web Vitals, and field data from real visits (where your traffic is high enough to have any) is more trustworthy than a lab run. For a small site with little data, use the lab test as a guide to what is heavy, then confirm with your own phone on mobile data.
Aim for "fast enough that nobody notices", then stop. The gap between a score of 90 and 100 is rarely visible to a human and often costs more effort than everything that came before it.
7. Speed only matters for search ranking
Myth
Ranking is one reason. The bigger one is people: slow pages lose visitors, especially on mobile, and customers abandon slow checkouts.
Even if search engines ignored speed entirely, you would still want a fast site.
Search engines do use page experience signals, but as one input among many, and relevance of content outweighs them by a wide margin. A fast page with nothing useful on it will not outrank a slower page that answers the question. Speed tends to act as a tiebreaker, and it matters most in the places where the competition is close.
The effect on people is more direct. Mobile visitors are often on a weaker connection than the developer testing the site on office broadband. A page that appears after four seconds on a cheap phone loses a share of them before they read a word. Checkout is more sensitive again, because the visitor is in the middle of a task and any delay invites second thoughts, or a trip to a competitor. Support teams also notice it: a slow site generates tickets, from "your form didn't submit" to "I clicked twice and was charged twice".
Speed also has a cost side. Lighter pages use less bandwidth, which matters on plans with transfer limits, and less CPU, which keeps you inside shared hosting resource limits for longer as traffic grows. Efficiency is a form of capacity.
What to look at on your own setup
Start with the numbers rather than a hunch. Run the curl command from claim 2 three times, at different times of day, and write down time to first byte and total time. Then open the browser's developer tools, switch to the Network tab, tick "Disable cache", reload, and sort by size. The biggest files are the first suspects. Check the total transferred at the bottom: a page over 3 MB is heavy by almost any standard, and the page weight tool will help you see how much of that is images.
Then change one thing at a time and measure again. If you change five settings at once and the site gets faster, you will not know which one mattered, and you will not know which one to undo when something breaks.