I’m going to say something that hosting companies hate hearing: most WordPress blogs are on the wrong hosting plan. Not because bloggers are stupid, but because the hosting industry has spent two decades marketing on price and “unlimited” promises rather than actual performance. I’ve moved over 200 client sites between hosting providers. I know what bad hosting costs you, and I know what good hosting changes.
Your hosting is your speed floor. It determines the fastest your site can possibly respond, before your theme, plugins, or content even enter the equation. If your server takes 800ms just to start sending data, your page is never loading in under 2 seconds. No caching plugin, no image optimizer, no CDN can fix a slow server. They can only build on what your server gives them.
Hosting Is Your Speed Floor
Every page load starts the same way. A visitor’s browser sends a request to your server. Your server receives it, runs PHP, queries the database, builds the HTML, and sends it back. The time this takes is your TTFB (Time to First Byte), and it’s the single most revealing metric for hosting quality.
On good hosting, TTFB runs 100-200ms. On mediocre hosting, 300-600ms. On bad hosting, 800ms to over 2 seconds. That’s the gap before anything else happens. Before CSS loads. Before images load. Before JavaScript runs.
I tested a client’s site on their $4/month shared host. TTFB was 1,200ms. We moved the exact same site, same theme, same plugins, same content, to Cloudways on a $14/month DigitalOcean server. TTFB dropped to 180ms. That’s a full second saved before we changed a single thing about the site itself.
Think of hosting like the engine in a car. You can add better tires, a spoiler, and premium fuel. But if the engine makes 40 horsepower, you’re not winning any races. Hosting is the engine.
Shared Hosting vs. Managed WordPress vs. VPS vs. Dedicated
Let me break down the four main types of hosting and be honest about each one.
Shared hosting ($3-15/month). Your site shares a server with dozens or hundreds of other sites. You share CPU, RAM, and disk I/O. When another site on your server gets a traffic spike, your site slows down. There’s no isolation, and resources are oversold. This is what Bluehost, HostGator, SiteGround’s basic plans, and GoDaddy’s shared plans offer.
Shared hosting is fine for a brand new blog with under 1,000 monthly visitors and zero revenue. The moment your site starts making money or getting real traffic, you’ve outgrown it. I see bloggers stay on shared hosting for years because “it’s only $5 a month” while losing hundreds in revenue from slow load times. The math doesn’t work.
Managed WordPress hosting ($15-100+/month). These are hosting providers specifically built for WordPress. They handle server optimization, automatic updates, staging environments, and WordPress-specific caching. Examples include Rocket.net, Kinsta, and WP Engine.
The advantage is hands-off management. The server is tuned for WordPress, the team knows WordPress, and you get WordPress-specific features. The disadvantage is cost and sometimes flexibility. Some managed hosts restrict certain plugins or PHP configurations.
VPS (Virtual Private Server) ($10-80/month). You get a virtual slice of a physical server with dedicated CPU and RAM. Nobody else can affect your resources. But you need to manage the server yourself, or use a managed VPS provider like Cloudways that handles server management while giving you VPS-level performance.
This is my recommendation for most serious bloggers. A managed VPS gives you dedicated resources at a fraction of the cost of managed WordPress hosting. A 2GB RAM DigitalOcean server through Cloudways costs $14/month and outperforms most $30-50/month managed WordPress plans I’ve tested.
Dedicated server ($100-500+/month). An entire physical server just for you. Overkill for most blogs. You’d need millions of monthly pageviews to justify this. I only recommend dedicated servers for high-traffic WooCommerce stores or large membership sites.
The Hosts I Recommend and Use
I’m going to be direct. After testing over 30 hosting providers across hundreds of client sites, I’ve narrowed my recommendations to two.
Cloudways (for most bloggers). This is what I use for the majority of client sites and my own projects. Cloudways sits on top of infrastructure providers (DigitalOcean, Vultr, AWS, Google Cloud) and handles server management. You get VPS-level performance without needing to know Linux.
What I like about Cloudways: TTFB consistently under 200ms on their DigitalOcean servers. Built-in Varnish and Memcached caching. Free Cloudflare Enterprise CDN (this alone is worth more than the hosting cost). Easy server and application management. Pay-as-you-go pricing starting at $14/month.
What I don’t like: the control panel isn’t as polished as some competitors. Email hosting isn’t included (you’ll need a separate email service). Support quality varies by agent. But the performance is consistently excellent, and that’s what matters.
Rocket.net (for hands-off managed hosting). If you want someone else to handle everything and you’re willing to pay for it, Rocket.net is my pick for managed WordPress hosting. They run on Cloudflare’s global network, which means your site is cached at the edge in 300+ locations worldwide.
TTFB on Rocket.net is consistently 50-150ms, which is among the fastest I’ve measured. They include a full-page CDN, automatic optimization, and WordPress-specific security. Plans start at $25/month.
Why not the cheap shared hosts? I get this question constantly. “But [cheap host] only costs $3 a month!” Right. And your TTFB is 900ms, your uptime is 99.5% (which means 44 hours of downtime per year), and you’re sharing resources with hundreds of other sites. The $3/month plan costs you far more in lost visitors, lower rankings, and slower growth than the extra $10-20/month for proper hosting.
I’m not saying every shared host is terrible. SiteGround’s higher-tier plans are decent. But for the price difference, you’re better off on a managed VPS.
How to Benchmark Your Current Hosting
Before you decide whether to switch, measure what you have. You need data, not guesses.
Test 1: Measure TTFB. Go to pagespeed.web.dev and test your homepage on mobile. Look for “Server Response Time” or “Reduce initial server response time” in the diagnostics. That’s your TTFB. Do this test 3 times at different times of day (morning, afternoon, evening) and average the results. Shared hosting often performs well at 2 AM when nobody’s on the server but crawls at peak hours.
Test 2: Use WebPageTest. Go to webpagetest.org, enter your URL, select the server location closest to your audience, and run the test. Look at “First Byte” in the results. Run this test 3 times and average the results.
Test 3: Check uptime. Sign up for a free account at UptimeRobot or BetterStack (formerly Better Uptime). Monitor your site for 30 days. Any provider advertising 99.9% uptime that delivers less than 99.95% is underperforming. On shared hosting, I regularly see actual uptime of 99.5-99.8%, which translates to 17-44 hours of downtime per year.
Test 4: Check PHP version. In your WordPress dashboard, go to Tools > Site Health > Info > Server. Your PHP version should be 8.2 or 8.3 (as of early 2025). If you’re still on PHP 7.4 or 8.0, you’re leaving performance on the table and missing security patches.
TTFB: The Metric That Reveals Your Hosting Quality
TTFB deserves its own section because it’s the most misunderstood and most important hosting metric.
Time to First Byte measures the time from when a browser sends a request to when it receives the first byte of the response. It includes DNS lookup time, TCP connection time, TLS negotiation time, and server processing time. For a properly configured WordPress site with caching, TTFB should be under 200ms.
Here’s a rough TTFB grading scale based on what I’ve measured across hundreds of sites:
Under 100ms: Excellent. This means your content is being served from a CDN edge cache, not your origin server. This is what you get with Rocket.net’s Cloudflare integration or properly configured Cloudflare APO.
100-200ms: Good. Your hosting is solid. Most well-configured VPS and managed WordPress hosts land here. This is your target.
200-400ms: Acceptable. Not great, but not a dealbreaker. Some shared hosting plans manage this during off-peak hours. You’re leaving speed on the table, but it’s workable.
400-800ms: Poor. Your hosting is actively hurting your performance. At this level, no amount of front-end optimization will get you to a 2-second load time on mobile. Start shopping for new hosting.
Over 800ms: Unacceptable. Switch hosting immediately. You’re losing visitors, rankings, and money every day you stay.
I test TTFB from multiple locations because network distance matters. A server in the US will have low TTFB for US visitors but higher TTFB for visitors in India or Europe. This is where CDN integration becomes important, which we’ll cover in a later chapter.
When to Switch Hosting
Switching hosting is disruptive. It takes time, costs money for the new plan, and carries a small risk of issues during migration. So when is it worth it?
Switch immediately if: Your TTFB consistently exceeds 600ms. Your uptime is below 99.9% over 30 days. Your host doesn’t support PHP 8.2+. Your host limits your ability to use caching plugins or server-level caching. You’ve outgrown your plan’s resource limits and experience regular slowdowns.
Switch soon if: Your TTFB is 300-600ms and you’ve already optimized everything else. You’re paying more than $20/month for shared hosting (you could get better VPS performance for the same price). Your host’s support is slow or unhelpful when you need assistance. Your hosting doesn’t include a CDN and you’re paying separately for one.
Don’t switch if: Your TTFB is under 300ms and you’re generally happy with reliability. You just launched and have under 1,000 monthly visitors. You’re in the middle of a content push and don’t want to risk any disruption. Your issues are caused by your theme or plugins, not your hosting.
The most common mistake I see is bloggers switching hosting when their real problem is a bloated theme or 40 plugins. Fix the software first. If TTFB is still slow after that, then switch hosting.
The Migration Process
Moving a WordPress site between hosts is straightforward if you follow the right steps. I’ve done over 200 migrations, and the process is the same every time.
Step 1: Get your new hosting account set up. Install WordPress on the new server but don’t configure anything yet.
Step 2: Use a migration plugin. I use All-in-One WP Migration or UpdraftPlus for most migrations. Export your entire site (database + files) from the old host, and import it on the new host. For sites over 2GB, you might need the premium version or a server-level tool like rsync + mysqldump.
Step 3: Test on the new server. Before changing your DNS, access the new site using the temporary URL your host provides (or modify your local hosts file to point your domain to the new server’s IP). Check that everything works: pages load, forms submit, login works, images display correctly.
Step 4: Update DNS. Point your domain’s DNS to the new server. If you’re using Cloudflare, just change the origin IP. If you’re not using Cloudflare, update the A record at your domain registrar. DNS propagation takes 15 minutes to 48 hours, but usually completes within a few hours.
Step 5: Monitor. Keep your old hosting account active for 72 hours after switching DNS. If anything goes wrong, you can revert by switching DNS back. Check your site from multiple devices and locations after the switch.
The entire process typically takes 2-4 hours of active work. I usually do migrations on weekday mornings when traffic is lower and I can monitor the switch throughout the day.
Server Location Matters
Your server’s physical location affects latency for every visitor. Light travels fast, but not instantly. A request from Mumbai to a server in Dallas takes 200-300ms for the round trip, just from physics. That’s added to your TTFB on every uncached request.
Choose a server location near your primary audience. If most of your traffic comes from the US, use a US-based server (New York, Dallas, or San Francisco are common options). If your audience is primarily in Europe, use a European data center. If you serve a global audience, pick the location where the largest chunk of your visitors are, then use a CDN to handle the rest.
You can check where your traffic comes from in Google Analytics (Reports > Demographics > Country). This takes 30 seconds and informs a decision that affects every page load for every visitor.
CDN solves the distance problem. A Content Delivery Network caches your static content (and sometimes full pages) on servers worldwide. When a visitor in Tokyo requests your page, they get it from a server in Tokyo instead of your server in Dallas. This drops TTFB for distant visitors from 300ms to 30ms.
Cloudflare offers a free CDN that’s good enough for most blogs. Cloudways includes Cloudflare Enterprise for free, which is even better. Rocket.net runs entirely on Cloudflare’s network, so CDN is built in.
PHP Version: The Easiest Speed Win
This is the simplest performance improvement you can make, and it takes about 5 minutes.
PHP is the programming language WordPress runs on. Each new PHP version is significantly faster than the last. The benchmarks are dramatic:
PHP 7.4 to PHP 8.0: 10-15% faster WordPress execution.
PHP 8.0 to PHP 8.1: 5-10% faster.
PHP 8.1 to PHP 8.2: 5-8% faster.
PHP 8.2 to PHP 8.3: 3-5% faster.
Adding those up: PHP 8.3 executes WordPress code roughly 25-35% faster than PHP 7.4. On a site where PHP execution takes 300ms, that’s 75-100ms saved on every single page load. For free. Just by changing a setting.
To check your PHP version, go to your WordPress dashboard, then Tools > Site Health > Info > Server. If you’re on anything below PHP 8.2, log into your hosting control panel and switch to the latest version your host supports.
One important caveat. Test after switching. Some older plugins might not be compatible with PHP 8.2 or 8.3. This is rare with well-maintained plugins, but it happens. Switch PHP version, then check your site thoroughly. If something breaks, update the plugin or find a replacement. Don’t downgrade PHP to accommodate a broken plugin. That plugin is a liability.
I switched a client’s site from PHP 7.4 to PHP 8.3 last month. No code changes, no plugin updates needed. TTFB dropped from 340ms to 220ms. That’s 120ms saved from a 5-minute settings change. This is why I listed it as the easiest speed win. Because it genuinely is.
If your hosting provider doesn’t offer PHP 8.2 or higher, that alone is a reason to consider switching. It means they’re not keeping their infrastructure current, and outdated infrastructure almost always means outdated security and slower performance across the board.
Chapter Checklist
- [ ] Measured your TTFB at 3 different times of day
- [ ] Set up uptime monitoring (UptimeRobot or BetterStack, free tier)
- [ ] Checked your PHP version and updated if needed
- [ ] Identified your server location and compared it to your audience location
- [ ] Evaluated whether your current hosting meets the TTFB targets (under 200ms good, under 400ms acceptable)
- [ ] If switching: researched Cloudways and Rocket.net pricing for your traffic level
- [ ] If staying: confirmed your host supports PHP 8.2+ and has a CDN option
Chapter Exercise
Run the TTFB benchmark test. Test your homepage at three different times:
- Morning TTFB (8-10 AM your audience’s time zone): ___ms
- Afternoon TTFB (1-3 PM): ___ms
- Evening TTFB (7-9 PM): ___ms
- Average TTFB: ___ms
Now compare your average to the grading scale in this chapter:
- Under 200ms = Good (keep your hosting)
- 200-400ms = Acceptable (consider upgrading when ready)
- 400-800ms = Poor (start planning a switch)
- Over 800ms = Switch now
If your average TTFB is over 400ms and you’ve already confirmed you’re on the latest PHP version with caching enabled, your hosting is the bottleneck. No amount of front-end optimization will overcome a slow server.
Disclaimer: This site is reader-supported. If you buy through some links, I may earn a small commission at no extra cost to you. I only recommend tools I trust and would use myself. Your support helps keep gauravtiwari.org free and focused on real-world advice. Thanks. - Gaurav Tiwari