{"id":6,"date":"2026-09-05T18:28:19","date_gmt":"2026-09-05T18:28:19","guid":{"rendered":"https:\/\/hostcrafter.com\/blog\/we-measured-nine-cache-plugins\/"},"modified":"2026-09-06T15:09:39","modified_gmt":"2026-09-06T09:39:39","slug":"wordpress-handle-more-traffic","status":"publish","type":"post","link":"https:\/\/hostcrafter.com\/blog\/wordpress-handle-more-traffic\/","title":{"rendered":"Seven Settings That Let a WordPress Site Take 50\u00d7 More Traffic"},"content":{"rendered":"<p>Here is the idea the whole article hangs on. Take one WordPress site on one server, and change nothing about it except whether a visitor&#8217;s page comes out of a cache.<\/p>\n<div class=\"hc-meters\">\n<div><span class=\"hc-meter-l\">Cache off<\/span><span class=\"hc-meter w2\"><\/span><b>Every visitor makes WordPress build the page<\/b><\/div>\n<div><span class=\"hc-meter-l\">Cache on<\/span><span class=\"hc-meter hc-meter-go w100\"><\/span><b>Most visitors are served a finished page<\/b><\/div>\n<\/div>\n<p>Same plan. Same content. Orders of magnitude more traffic absorbed, because in the second case the server answers without ever starting PHP.<\/p>\n<div class=\"hc-cal\"> <b>Why half an hour, and not a day or a second.<\/b> Every traffic figure in this article is pageviews the site can serve <em>in thirty minutes<\/em>, because that is the window that decides whether a site stays up. A monthly total hides everything: 200,000 visits a month is comfortable spread evenly and is a dead site if half of them arrive when a newsletter goes out. Half an hour is long enough to be a real event \u2014 a newsletter, a Reddit thread, a mention on television \u2014 and short enough that the burst has not finished. It is also the window we size our own servers in. <\/div>\n<p>That is not a realistic before-and-after for a live site \u2014 no real site is 100% cacheable, and we will do the honest arithmetic in a moment. But it tells you where the leverage is, and it is not where most &#8220;speed up WordPress&#8221; advice points. It is not your CPU, your RAM or your plan. It is <strong>the proportion of your visitors who never reach PHP at all.<\/strong><\/p>\n<dl class=\"hc-facts\">\n<div>\n<dt>Measured on<\/dt>\n<dd>Our own nodes, Aug\u2013Sep 2026<\/dd>\n<\/div>\n<div>\n<dt>Biggest single win<\/dt>\n<dd>A page cache that skips PHP<\/dd>\n<\/div>\n<div>\n<dt>Most common leak<\/dt>\n<dd>Plugins loading on every page<\/dd>\n<\/div>\n<div>\n<dt>Time to apply<\/dt>\n<dd>An afternoon<\/dd>\n<\/div>\n<\/dl>\n<nav class=\"hc-toc\">\n<h2>On this page<\/h2>\n<ol>\n<li><a href=\"#ceiling\">The Number That Sets Your Traffic Ceiling<\/a><\/li>\n<li><a href=\"#one\">1. Cache the Page \u2014 and Prove PHP Is Not Running<\/a><\/li>\n<li><a href=\"#two\">2. Match the Cache Plugin to the Web Server<\/a><\/li>\n<li><a href=\"#three\">3. Stop Paying Full Price for Every Ad Click<\/a><\/li>\n<li><a href=\"#four\">4. Find the Plugins That Load on Pages They Are Not On<\/a><\/li>\n<li><a href=\"#five\">5. Put a CDN in Front of the Static Files<\/a><\/li>\n<li><a href=\"#six\">6. Use a Theme That Does Not Need Rescuing<\/a><\/li>\n<li><a href=\"#seven\">7. And Then, the Host<\/a><\/li>\n<li><a href=\"#order\">The Order to Do These In<\/a><\/li>\n<li><a href=\"#faq\">Questions<\/a><\/li>\n<\/ol>\n<\/nav>\n<h2 id=\"ceiling\">The Number That Sets Your Traffic Ceiling<\/h2>\n<p>The gap between those two states is enormous, and it is much larger than the gap between a cheap plan and an expensive one. A bigger plan barely changes what a <em>cached<\/em> page costs, because a cached page costs almost nothing to serve anywhere. What it changes is how many <em>uncached<\/em> requests can run at once, and the whole trick is to have very few of those.<\/p>\n<p>Your real site sits between those two, and where it sits is decided by one figure: <strong>your cache hit ratio<\/strong> \u2014 the share of requests answered from cache. That single number is what converts into traffic capacity, and it does so brutally, because the uncached requests dominate the arithmetic:<\/p>\n<div class=\"hc-tw\"><table>\n<tr>\n<th>Cache hit ratio<\/th>\n<th>Traffic the same site can absorb<\/th>\n<th>Roughly<\/th>\n<\/tr>\n<tr>\n<td>0%<\/td>\n<td>1&times;<\/td>\n<td>An unlucky Reddit link takes the site down<\/td>\n<\/tr>\n<tr>\n<td>50%<\/td>\n<td>2&times;<\/td>\n<td>Still fragile<\/td>\n<\/tr>\n<tr>\n<td>80%<\/td>\n<td>5&times;<\/td>\n<td>A typical WordPress site with a cache plugin<\/td>\n<\/tr>\n<tr>\n<td>90%<\/td>\n<td>10&times;<\/td>\n<td>Tidy<\/td>\n<\/tr>\n<tr>\n<td>95%<\/td>\n<td>20&times;<\/td>\n<td>Good<\/td>\n<\/tr>\n<tr>\n<td><strong>98%<\/strong><\/td>\n<td><strong>50&times;<\/strong><\/td>\n<td><strong>What this article is aiming at<\/strong><\/td>\n<\/tr>\n<tr>\n<td>99%<\/td>\n<td>98&times;<\/td>\n<td>A static site with comments<\/td>\n<\/tr>\n<\/table><\/div>\n<div class=\"hc-cal\"> <b>Be clear about what that table is.<\/b> It is arithmetic, not a promise about any particular host. A cached page costs a tiny fraction of what an uncached one costs, so the uncached requests dominate the total \u2014 which is why the multiplier climbs so steeply as the last few percent of requests move into cache. The point is not the exact figure in any row; it is which lever moves the number, and how far. <\/div>\n<p>Read the middle of the table again. Going from 80% to 98% is a <strong>ten-fold<\/strong> change in how much traffic the same site on the same plan can absorb, and 80% is roughly where a normal WordPress site with a cache plugin installed and left alone actually sits. Across the sites on our own nodes, about <strong>83% of requests<\/strong> are served without ever entering a customer&#8217;s share of the server.<\/p>\n<p>So the seven settings below are all, in one way or another, the same job: <strong>move that percentage up.<\/strong> Nothing here is about buying a faster CPU.<\/p>\n<h2 id=\"one\">1. Cache the Page \u2014 and Prove PHP Is Not Running<\/h2>\n<p>When WordPress builds a page it loads several hundred PHP files, opens a database connection, runs a few dozen queries, executes every active plugin&#8217;s hooks, renders the theme, and hands the result back. We measured that work at about <strong>208 milliseconds of CPU time per page<\/strong> on a normal site. Multiply by the plugins on a real install and it goes up sharply \u2014 every shortcode, every slider, every &#8220;related posts&#8221; block is more of the same work, repeated for every single visitor, to produce a page that is <em>identical<\/em> for all of them.<\/p>\n<p>A page cache stores the finished HTML the first time and hands the file to everybody else. That cost is about a <strong>thousandth<\/strong> of the same page rendered fresh.<\/p>\n<p>Almost every WordPress site has a cache plugin. Far fewer have a cache that actually skips PHP, and that distinction is the whole game. There are two ways a plugin can cache a page:<\/p>\n<ul>\n<li><strong>Through PHP.<\/strong> The plugin drops a file called <code>advanced-cache.php<\/code> into your site. WordPress loads it very early, it finds the stored page and prints it, and PHP exits before the rest of WordPress starts. Genuinely fast \u2014 90 to 250 times faster than no cache \u2014 but it still costs a PHP worker for every single visit. Your plan has a fixed number of those.<\/li>\n<li><strong>Before PHP.<\/strong> The plugin writes rules the web server reads, or talks to a cache built into the web server. The request is answered by the web server itself. <strong>PHP never wakes up<\/strong>, so the number of PHP workers on your plan stops being the ceiling.<\/li>\n<\/ul>\n<p>The distinction is invisible from the outside \u2014 both are fast on an empty server. It only matters when you are busy, which is precisely the moment it matters most.<\/p>\n<div class=\"hc-cal tip\"> <b>How to tell which one you have.<\/b> A response-time test cannot answer this. The honest test is to look at whether the request costs you a PHP worker, and the only way to be certain is to stop PHP and ask again. On your own hosting you cannot do that, so use the proxy: open your browser&#8217;s network tab, load a page you have loaded before, and look at the response headers. A server-level cache announces itself \u2014 <code>x-litespeed-cache: hit<\/code>, <code>cf-cache-status: HIT<\/code>, <code>x-cache: HIT<\/code>. A plugin-level cache usually leaves an HTML comment at the very bottom of the page source instead, along the lines of &#8220;Cached by \u2026&#8221;. Comment at the bottom means PHP ran to put it there. <\/div>\n<h3>How to check your own site<\/h3>\n<p>You do not need a lab for this. Open your site in a private window, load a page twice, and look at what your cache plugin reports in its own dashboard: most of them will tell you plainly whether that page was served from cache. If yours says the page is cached and the site still feels slow, the problem is somewhere else on this list.<\/p>\n<p>The thing to aim for is that an ordinary visitor to an ordinary page never makes WordPress run at all. Everything else in this article is smaller than that.<\/p>\n<h2 id=\"two\">2. Match the Cache Plugin to the Web Server<\/h2>\n<p>This is the part almost no &#8220;best cache plugin&#8221; article mentions, and it is the single most consequential choice on the list: <strong>which plugin lands in the top half of that table depends on what web server you are on.<\/strong> The same plugin can bypass PHP on one server and go through PHP on another.<\/p>\n<div class=\"hc-tw\"><table>\n<tr>\n<th>Your web server<\/th>\n<th>What reaches the top half<\/th>\n<th>Why<\/th>\n<\/tr>\n<tr>\n<td><strong>LiteSpeed<\/strong><\/td>\n<td>LiteSpeed Cache<\/td>\n<td>The plugin does not store pages at all. It adds a header telling the server to keep the page and how to label it, so the cache <em>is<\/em> the web server. Nothing else has that hook.<\/td>\n<\/tr>\n<tr>\n<td><strong>Apache<\/strong><\/td>\n<td>W3 Total Cache, WP Rocket, WP Super Cache<\/td>\n<td>Apache reads <code>.htaccess<\/code>, so a plugin can write rewrite rules that hand its stored HTML straight to Apache. PHP is skipped.<\/td>\n<\/tr>\n<tr>\n<td><strong>nginx<\/strong><\/td>\n<td>Whatever your host has configured \u2014 ask them<\/td>\n<td>nginx does not read <code>.htaccess<\/code>. The rules a plugin writes there are inert. Unless your host has added matching rules to the nginx config, the plugin&#8217;s cache is served <em>through PHP<\/em>.<\/td>\n<\/tr>\n<\/table><\/div>\n<p>Three practical consequences:<\/p>\n<ul>\n<li><strong>If you are not on LiteSpeed, do not install LiteSpeed Cache.<\/strong> It is an excellent plugin and it will do very little for you. Its whole design is a conversation with a LiteSpeed server, and without one on the other end it falls back to a much more ordinary cache.<\/li>\n<li><strong>If you are on nginx, ask your host one question:<\/strong> &#8220;does my cache plugin&#8217;s static HTML get served without starting PHP, or do you have a server-level cache in front?&#8221; Good managed hosts on nginx run their own cache layer and the answer is yes. Cheap shared nginx hosting often does neither, and the plugin is quietly doing PHP work on every hit.<\/li>\n<li><strong>Never run two page caches at once.<\/strong> Two plugins both deciding what to store and when to throw it away is how a visitor gets served a page that should not exist \u2014 a logged-out person seeing a cached admin bar, or a price from last week. If you install a new one, deactivate the old one first.<\/li>\n<\/ul>\n<div class=\"hc-cal\"> <b>Where we stand on this.<\/b> The <a href=\"https:\/\/hostcrafter.com\/kb\/hostcrafter-stack\/\">HostCrafter stack<\/a> is built on LiteSpeed, so every WordPress site we build gets LiteSpeed Cache installed and configured at build time, with the store held by the server rather than inside the site&#8217;s own files \u2014 it costs you no disk and support can clear it for you. Customers who prefer W3 Total Cache or WP Rocket are welcome to use them and they reach the same no-PHP path here; the only rule is the one above, turn one off before turning the other on. <\/div>\n<h2 id=\"three\">3. Stop Paying Full Price for Every Ad Click<\/h2>\n<p>This one is small to fix, invisible until you look, and it lands squarely on the most expensive traffic you have.<\/p>\n<p>When somebody clicks a Google ad, a Facebook post or a newsletter, the link they follow is not <code>yoursite.com\/offer<\/code>. It is <code>yoursite.com\/offer?gclid=EAIaIQob\u2026<\/code>, or <code>?fbclid=\u2026<\/code>, or <code>?utm_source=newsletter&amp;utm_medium=email<\/code>. The page that comes back is <em>byte for byte identical<\/em> \u2014 those parameters are for the analytics script in the browser, not for WordPress.<\/p>\n<p>But most caches key their stored pages on the full URL including the query string. Every unique <code>gclid<\/code> is a URL nobody has ever requested before, so every ad click is a cache miss and a full WordPress render. We measured that penalty on a real site: <strong>237 milliseconds instead of 23 \u2014 ten times the cost, falling precisely on the visitors you paid for.<\/strong><\/p>\n<p>The fix is to strip known advertising and analytics parameters from the cache key, so an ad click and a plain visit answer from the same stored page. Every serious cache can do it. Two traps though, and we walked into both:<\/p>\n<ul>\n<li><strong>The setting can be present, switched on, and doing nothing.<\/strong> LiteSpeed Cache ships a &#8220;Drop Query String&#8221; setting, on by default, already listing <code>utm*<\/code>, <code>gclid<\/code> and <code>fbclid<\/code>. It implements it by writing directives into <code>.htaccess<\/code>, which is not where every server acts on them. We watched three different <code>gclid<\/code> values produce three misses and three full renders with the correct settings sitting in that file the whole time. On our stack it needed the same directives somewhere else entirely, which is a thing a host can fix for every site at once and a thing you cannot fix from inside the plugin.<\/li>\n<li><strong>Do not strip everything.<\/strong> A real search \u2014 <code>?s=running+shoes<\/code> \u2014 is a genuinely different page and must not share a cached copy with the homepage. Strip the click identifiers, leave the rest. We deliberately leave <code>ref<\/code> alone too, because plenty of sites route on it.<\/li>\n<\/ul>\n<div class=\"hc-cal tip\"> <b>Check your own site in thirty seconds.<\/b> Load your homepage, then load it again with <code>?gclid=test111<\/code> on the end, then <code>?gclid=test222<\/code>. If the second and third are noticeably slower than the first, or their response headers say <code>miss<\/code> where the plain one says <code>hit<\/code>, every ad click you buy is costing you a full render. On our nodes all three come back as a hit, and <code>?s=<\/code> still goes to PHP, which is the distinction that matters. <\/div>\n<h2 id=\"four\">4. Find the Plugins That Load on Pages They Are Not On<\/h2>\n<p>The advice &#8220;use fewer plugins&#8221; is not quite right \u2014 twenty well-behaved plugins can be lighter than three badly behaved ones. The real question is narrower: <strong>which plugins add weight to pages they have nothing to do with?<\/strong><\/p>\n<p>Take the most-installed form plugin in the world, Contact Form 7. We read the source of version 6.1.7 as installed on one of our own servers. It registers its assets on <code>wp_enqueue_scripts<\/code> and then does this:<\/p>\n<pre><code>if ( wpcf7_load_js() ) {\n    wpcf7_enqueue_scripts();\n}\n...\nif ( wpcf7_load_css() ) {\n    wpcf7_enqueue_styles();\n}<\/code><\/pre>\n<p>Both of those functions return a constant that defaults to <code>true<\/code>. There is <strong>no check for whether the page contains a form<\/strong>. So on every page of your site \u2014 your homepage, every blog post, your privacy policy \u2014 a visitor downloads:<\/p>\n<div class=\"hc-tw\"><table>\n<tr>\n<th>File<\/th>\n<th>Size<\/th>\n<\/tr>\n<tr>\n<td><code>includes\/js\/index.js<\/code><\/td>\n<td>13,452 bytes<\/td>\n<\/tr>\n<tr>\n<td><code>includes\/swv\/js\/index.js<\/code> (its validation dependency)<\/td>\n<td>12,512 bytes<\/td>\n<\/tr>\n<tr>\n<td><code>includes\/css\/styles.css<\/code><\/td>\n<td>2,979 bytes<\/td>\n<\/tr>\n<tr>\n<td><strong>Total, on every page<\/strong><\/td>\n<td><strong>28,943 bytes across three requests<\/strong><\/td>\n<\/tr>\n<\/table><\/div>\n<p>For scale: a full pageview on a lean theme measured <strong>41 KB over the wire<\/strong> in our own testing. A form plugin, on a page with no form, is adding most of that again \u2014 plus three round trips, which on a phone on mobile data cost more than the bytes do.<\/p>\n<p>Contact Form 7 is not a bad plugin and this is not a reason to abandon it. It is an example of a pattern you should go looking for, because it is everywhere: sliders, page builders, share buttons, review widgets, chat boxes, and cookie banners all commonly load their entire front-end on every page in case one of them needs it.<\/p>\n<h3>How to find them, in five minutes<\/h3>\n<ol class=\"hc-steps\">\n<li>\n<h3>Pick a page with nothing on it<\/h3>\n<p>Your privacy policy, or an old blog post. Something with no form, no slider, no gallery, no shop. That page should be nearly the lightest on your site.<\/p>\n<\/li>\n<li>\n<h3>Open the browser&#8217;s network tab and reload<\/h3>\n<p>Sort by name. Every request with <code>\/wp-content\/plugins\/<\/code> in it is a plugin loading itself on this page. Read the plugin&#8217;s name out of the path and ask: does this page use that plugin?<\/p>\n<\/li>\n<li>\n<h3>Deal with each one, in this order<\/h3>\n<p><strong>Delete it<\/strong> if you are not using it \u2014 deactivated is not deleted, and a deactivated plugin is still a security update you owe. <strong>Replace it<\/strong> if it does one small job badly. <strong>Or restrict it<\/strong>, which is often two lines: Contact Form 7&#8217;s own documented switch is <code>define('WPCF7_LOAD_JS', false);<\/code> and <code>define('WPCF7_LOAD_CSS', false);<\/code> in <code>wp-config.php<\/code>, after which you load them only on the page that has the form.<\/p>\n<\/li>\n<\/ol>\n<div class=\"hc-cal warn\"> <b>Do this on a copy, not on the live site.<\/b> Restricting a plugin&#8217;s asset loading is exactly the kind of change that looks fine on the homepage and breaks the contact form nobody visits until Tuesday. Test it somewhere the public is not watching \u2014 a <a href=\"https:\/\/hostcrafter.com\/kb\/wordpress-staging-site\/\">staging copy<\/a> is a one-click job on our plans, and every host worth paying for has some version of it. <\/div>\n<h2 id=\"five\">5. Put a CDN in Front of the Static Files<\/h2>\n<p>A page cache removes the PHP. A CDN removes the distance. They solve different halves of the same problem and they stack.<\/p>\n<p>Your server is in one place. If it is in Frankfurt and your reader is in S\u00e3o Paulo, every single file on the page \u2014 the HTML, the CSS, each image, each font \u2014 makes a round trip of roughly 200 milliseconds before a single byte arrives. Twenty files means the browser spends most of the page load waiting for the speed of light rather than for your server. A CDN keeps copies of those files on machines in hundreds of cities and answers from the nearest one.<\/p>\n<p>Cloudflare&#8217;s free plan is the obvious starting point: several hundred locations, no charge, and you point your domain&#8217;s nameservers at them. Two things to get right:<\/p>\n<ul>\n<li><strong>By default it only caches your images, CSS and JavaScript<\/strong>, not your HTML. That is the safe default and it is still a large win \u2014 those files are most of the bytes. Caching the HTML too is a bigger win and needs a rule, and needs care if you have logged-in users or a cart.<\/li>\n<li><strong>WordPress tells edges not to cache.<\/strong> Out of the box WordPress sends <code>Cache-Control<\/code> headers that make an edge revalidate on every request, which throws away most of the benefit. Adding the CDN is the easy part; <strong>setting a sensible cache lifetime is where the improvement actually comes from<\/strong>, and it is the step most people skip.<\/li>\n<\/ul>\n<div class=\"hc-cal tip\"> <b>Choose your region first \u2014 it is free and it does most of this.<\/b> A CDN exists to shorten the distance between your reader and your server. If most of your readers are in one country, the largest single win available to you is having the server in that country to begin with: we ask you to pick a region at checkout for exactly this reason, and it costs nothing. Add an edge network on top when your audience is genuinely spread across continents. <\/div>\n<h2 id=\"six\">6. Use a Theme That Does Not Need Rescuing<\/h2>\n<p>Theme choice sets the floor for everything above. You can cache a heavy theme and it will be fast for anonymous visitors \u2014 but every uncached request, every logged-in view, every admin page and every page the cache has just dropped pays the full price, and the theme decides what that price is.<\/p>\n<p>The heavy end is not subtle. A multipurpose theme bundled with a page builder, a slider, an icon font, a portfolio plugin and a demo importer routinely ships 800 KB of CSS and JavaScript before you have written a word. It is not that the authors are careless; it is that a theme sold on &#8220;1,000 ready-made layouts&#8221; has to carry the machinery for all thousand.<\/p>\n<p>What to look for, in order:<\/p>\n<ul>\n<li><strong>A small, honest base.<\/strong> GeneratePress, Astra, Kadence, Blocksy and WordPress&#8217;s own default themes all start in the tens of kilobytes and load only what a page uses. This site and our knowledge base run on a GeneratePress child theme, for exactly this reason.<\/li>\n<li><strong>No web fonts you did not ask for.<\/strong> Each font family is a separate download that blocks text from appearing. System fonts cost nothing and are what your reader&#8217;s device is already optimised to render.<\/li>\n<li><strong>Blocks over a page builder, where you can stand it.<\/strong> Builders that store layout as shortcodes make every page render more expensive and make leaving the theme very hard later.<\/li>\n<\/ul>\n<div class=\"hc-cal tip\"> <b>Changing theme on a site that already has traffic is the risky part, not choosing one.<\/b> Do not do it live and do not do it in a maintenance window either \u2014 read <a href=\"https:\/\/hostcrafter.com\/blog\/change-wordpress-theme-live-site\/\">how to change a WordPress theme without visitors noticing<\/a>, which is the same job done on a copy and swapped in when it is finished. <\/div>\n<h2 id=\"seven\">7. And Then, the Host<\/h2>\n<p>We have put the host last deliberately. Six of the seven items above are free, live inside your own site, and will do more for you than moving. A well-configured site on modest hosting beats a badly configured one on expensive hosting, every time.<\/p>\n<p>What hosting decides is the two things the settings cannot change: <strong>how fast one uncached page is<\/strong>, and <strong>how many of them can run at once<\/strong> \u2014 which is your PHP worker count, and the number most worth asking about before you buy.<\/p>\n<p>Here is the managed WordPress market at its entry tier, from each vendor&#8217;s own pricing page, checked on 6 September 2026:<\/p>\n<div class=\"hc-tw\"><table>\n<tr>\n<th><\/th>\n<th>HostCrafter<br \/>WP Starter<\/th>\n<th>WPX<br \/>Starter<\/th>\n<th>Kinsta<br \/>Single 35k<\/th>\n<th>WP Engine<br \/>Essential<\/th>\n<th>Rocket.net<br \/>Starter<\/th>\n<\/tr>\n<tr>\n<td><strong>Monthly<\/strong><\/td>\n<td><strong>$4.99<\/strong><\/td>\n<td>$17.99<\/td>\n<td>$35<\/td>\n<td>from $30<\/td>\n<td>$30<\/td>\n<\/tr>\n<tr>\n<td><strong>Yearly, per month<\/strong><\/td>\n<td><strong>$3.74<\/strong><\/td>\n<td>$14.99<\/td>\n<td>$30<\/td>\n<td>~$28<\/td>\n<td>\u2014<\/td>\n<\/tr>\n<tr>\n<td>Websites<\/td>\n<td>1<\/td>\n<td>1<\/td>\n<td>1<\/td>\n<td>1<\/td>\n<td>1<\/td>\n<\/tr>\n<tr>\n<td><strong>Monthly visits<\/strong><\/td>\n<td><strong>Unlimited<\/strong><\/td>\n<td>Unlimited<\/td>\n<td>35,000<\/td>\n<td>25,000<\/td>\n<td>Unmetered<\/td>\n<\/tr>\n<tr>\n<td>Storage<\/td>\n<td>12 GB<\/td>\n<td>10 GB<\/td>\n<td>10 GB<\/td>\n<td>10 GB<\/td>\n<td>10 GB<\/td>\n<\/tr>\n<tr>\n<td>Bandwidth<\/td>\n<td>120 GB<\/td>\n<td>100 GB<\/td>\n<td>125 GB CDN<\/td>\n<td>75 GB<\/td>\n<td>50 GB<\/td>\n<\/tr>\n<tr>\n<td>PHP workers<\/td>\n<td>10<\/td>\n<td>9<\/td>\n<td>not published<\/td>\n<td>not published<\/td>\n<td>not published<\/td>\n<\/tr>\n<\/table><\/div>\n<p>Two things in that table are worth more than the price row.<\/p>\n<p><strong>Metered visits.<\/strong> Kinsta&#8217;s entry plan allows 35,000 visits a month and WP Engine&#8217;s 25,000. Read that against the arithmetic at the top of this article: a well-cached site can absorb a burst many times larger than its ordinary day, and on a metered plan that burst is counted. The limit you hit first there is a billing rule, not a server. That is a legitimate way to sell hosting \u2014 it is predictable, and support is not haggling with you about what a &#8220;visit&#8221; is \u2014 but it means a viral week costs you money rather than costing you nothing. We do not bill on visits, and neither does WPX.<\/p>\n<p><strong>PHP workers.<\/strong> Two of the five publish this and three do not, which tells you something in itself. It is the number that decides how many uncached requests can run at the same time \u2014 your checkout, your logged-in users, your search results. If a host will not tell you, ask support before you buy, and ask whether it is per site or per account.<\/p>\n<h2 id=\"order\">The Order to Do These In<\/h2>\n<p>If you only do part of this, do it in this order. It is sorted by effect per hour spent, from the measurements above.<\/p>\n<ol class=\"hc-steps\">\n<li>\n<h3>Confirm you have a page cache that skips PHP<\/h3>\n<p>Check the response headers as described in section 1. If your cache runs through PHP and your host is on LiteSpeed or Apache, switching to the plugin that matches your server is the single biggest change available to you, and it takes ten minutes.<\/p>\n<\/li>\n<li>\n<h3>Fix the query-string hole<\/h3>\n<p>Thirty seconds to test, and it is aimed at your paid traffic. Section 3.<\/p>\n<\/li>\n<li>\n<h3>Audit what loads on a page with nothing on it<\/h3>\n<p>The five-minute network-tab pass in section 4. Expect to find two or three plugins loading everywhere, and expect deleting one of them to be the largest byte saving on the list.<\/p>\n<\/li>\n<li>\n<h3>Put a CDN in front<\/h3>\n<p>An afternoon including DNS, free at Cloudflare&#8217;s entry plan, and the only item here that helps readers who are physically far away.<\/p>\n<\/li>\n<li>\n<h3>Then, and only then, look at the theme and the host<\/h3>\n<p>Both are real levers and both are disruptive. Neither is worth doing before the four above, because a heavy theme on a 98% cache hit ratio is still fast for almost everybody.<\/p>\n<\/li>\n<\/ol>\n<div class=\"hc-faq\">\n<h2 id=\"faq\">Questions<\/h2>\n<h3>Will these settings really give me 50\u00d7 the traffic?<\/h3>\n<p>They will move your cache hit ratio, and the table at the top converts that into capacity. Whether you land at 5\u00d7 or 50\u00d7 depends on where you started and how much of your traffic can be cached at all. A content site, a blog or a brochure site can realistically reach the high nineties. A membership site where everybody is logged in cannot, because logged-in pages are personal and must not be cached \u2014 for those the wins come from the object cache and the host instead.<\/p>\n<h3>Is a cached site out of date?<\/h3>\n<p>No. A well-behaved cache drops the pages that changed when you publish or edit something. What you should not do is set a very long cache lifetime with nothing clearing it \u2014 that is how a site serves last week&#8217;s homepage while the owner insists their edits are not saving.<\/p>\n<h3>Do I need Redis or an object cache as well?<\/h3>\n<p>Probably not, if you are a blog. An object cache speeds up the <em>database queries inside a render<\/em> \u2014 but a page cache has already answered your anonymous visitors without a render happening at all. It earns its keep on shops, membership sites and busy admin areas, where a large share of requests genuinely cannot be page-cached.<\/p>\n<h3>My host says they have &#8220;server-level caching&#8221;. Is that enough?<\/h3>\n<p>Usually yes, and it is the good answer \u2014 it means your visitors are served without WordPress starting. Two follow-ups worth asking: can support clear it for you when a page looks wrong at 9pm, and does it count against your storage? On this stack the answers are yes and no.<\/p>\n<h3>How do I know my cache hit ratio?<\/h3>\n<p>If you use Cloudflare, its analytics report it directly. Otherwise, the practical version is to sample: request twenty of your real URLs, count how many report a cache hit in the headers, and be honest about which of your pages can never be cached. That approximation is good enough to tell you which row of the table you are on, which is all you need.<\/p>\n<\/p><\/div>\n<div class=\"hc-rel\">\n<h2>Read next<\/h2>\n<ul>\n<li><a href=\"https:\/\/hostcrafter.com\/blog\/change-wordpress-theme-live-site\/\">How to Change Your WordPress Theme Without Visitors Noticing<\/a><\/li>\n<li><a href=\"https:\/\/hostcrafter.com\/blog\/micro-niche-wordpress-hosting\/\">Why a Micro-Niche Site Needs Fast Hosting More Than a Big Site Does<\/a><\/li>\n<li><a href=\"https:\/\/hostcrafter.com\/kb\/wordpress-staging-site\/\">How to Create a WordPress Staging Site<\/a><\/li>\n<\/ul><\/div>\n","protected":false},"excerpt":{"rendered":"<p>The same WordPress site, on the same plan, can absorb roughly fifty times the traffic. The difference is seven settings, and not the one you expect.<\/p>\n","protected":false},"author":1,"featured_media":81,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-6","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-performance"],"_links":{"self":[{"href":"https:\/\/hostcrafter.com\/blog\/wp-json\/wp\/v2\/posts\/6","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/hostcrafter.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/hostcrafter.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/hostcrafter.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/hostcrafter.com\/blog\/wp-json\/wp\/v2\/comments?post=6"}],"version-history":[{"count":8,"href":"https:\/\/hostcrafter.com\/blog\/wp-json\/wp\/v2\/posts\/6\/revisions"}],"predecessor-version":[{"id":92,"href":"https:\/\/hostcrafter.com\/blog\/wp-json\/wp\/v2\/posts\/6\/revisions\/92"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/hostcrafter.com\/blog\/wp-json\/wp\/v2\/media\/81"}],"wp:attachment":[{"href":"https:\/\/hostcrafter.com\/blog\/wp-json\/wp\/v2\/media?parent=6"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/hostcrafter.com\/blog\/wp-json\/wp\/v2\/categories?post=6"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/hostcrafter.com\/blog\/wp-json\/wp\/v2\/tags?post=6"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}