Category Archives: WordPress hosting

Hosting a WooCommerce store is a different job from hosting a website. Every host will tell you they support WooCommerce, because technically it’s a plugin and it installs. Whether the store stays fast on the Monday after a sale email goes out is another question entirely.

If you’re comparing WooCommerce hosting in NZ, here’s what actually separates one host from the next, and the questions worth asking before you hand over a card.

Why a shop breaks ordinary hosting

A brochure site on ordinary managed WordPress hosting can be cached almost entirely. The server builds each page once, stores the result, and hands out copies. That’s why a small business website runs happily on cheap hosting.

A store can’t work that way. The cart, the checkout and the account pages are different for every single shopper, so they have to be built fresh on every request. Add a few dozen people browsing at once and the server is doing real work continuously.

That’s the gap. General hosting is sized for handing out copies. A store needs a platform sized for building pages.

1. Caching that understands a cart

Ask what the host’s page cache does with WooCommerce. The answer you don’t want is “we exclude the cart, checkout and account pages”, because that’s the bare minimum and it means the rest of your shop is being handled by a cache that doesn’t know a shop from a blog.

Better answers involve caching built specifically for WooCommerce, where product and category pages stay cached even for a shopper who has items in their cart. That’s where the speed lives, because catalogue browsing is most of your traffic.

2. What they do about cart fragments

This one is worth learning even if you never move hosts.

WooCommerce keeps the little cart counter in your header accurate by firing a background request on nearly every page load. It’s called cart fragments, it goes to admin-ajax.php, and it can’t be cached. So every visitor browsing your catalogue quietly generates a second uncacheable hit for every page they look at.

On a quiet store you’ll never notice. On a busy one it’s the single most common reason a shop goes slow at exactly the wrong moment. Ask the host what they do about it. If they’ve never heard of it, you have your answer.

3. PHP workers, not “unlimited bandwidth”

Bandwidth is a marketing number. The figure that decides whether your store survives a busy hour is how many PHP processes can run at the same time, usually called PHP workers.

Each uncacheable request, so each add to cart, each checkout, each logged-in page view, occupies a worker until it finishes. Run out and the rest queue up. Queueing looks like a slow site, and then a site that times out.

You don’t need to become an expert in it. You do need a host that can tell you the number and what happens when you hit it.

4. An object cache

Every WooCommerce page runs a pile of database queries: prices, stock, variations, tax rates, shipping zones. A persistent object cache such as Redis or Memcached keeps the answers in memory so the database isn’t asked the same question a thousand times an hour.

On a store with a few hundred products and any real traffic, this is one of the largest single speed differences between hosts. Ask whether it’s included or an upgrade, and check that against the plan you’re being quoted.

5. Backups you’d actually trust with orders

Products you can rebuild. Orders and customer records you can’t.

So the questions are: how often, how far back do they go, how long does a restore take, and can you restore just the database without flattening the files. Daily is the floor. Weekly backups on a store that takes 20 orders a day means a bad day can cost you 20 orders.

Test it. Ask them to restore something to a staging copy before you need it in anger.

6. Staging, and knowing how to use it on a live store

A staging site is where plugin updates and theme changes get tested before they go anywhere near customers. On a store it’s not optional, because a broken checkout is invisible until someone complains.

One trap that catches people: never push a staging database back to a live store. Orders placed while you were working on staging live in the production database, and pushing over the top erases them. Push files, never the database, and any host who lets you do it without a warning is one to watch.

7. Order emails that reach the inbox

Receipts, order confirmations, shipping notices, password resets. Sent by default straight from the web server, which is the least trusted way to send email there is, and a good share of them land in spam or vanish.

The fix is a proper transactional email service such as Amazon SES, with SPF and DKIM set up for your domain. Ask whether the host configures that for you or leaves it to you. Most leave it to you and don’t mention it.

8. Support hours that overlap your trading hours

Plenty of hosting sold in New Zealand is answered from the other side of the world. “24/7 support” often means a ticket queue where the person who can actually help starts work as you’re going to bed.

Checkout breaking at 10am on a Thursday is the scenario to plan for. Work out who picks up the phone then, and whether they know WooCommerce or just servers. For an Auckland business, local support in NZ hours is the difference between a fix before lunch and a fix overnight.

9. Server location, honestly

Distance costs milliseconds, so a server in Australia answers an Auckland shopper faster than one in Texas. Worth having. Also frequently oversold.

Once a CDN is in front of the site, your images and cached pages come from an edge location near the visitor anyway. Where the origin server sits matters most for the uncacheable requests, which on a store is the cart and the checkout. So it counts, and it counts less than the caching and worker questions above.

Be careful with claims here. A host advertising a New Zealand data centre should be able to name it. Plenty of “NZ hosting” is a New Zealand company reselling infrastructure in Sydney or Singapore, which is fine, as long as they say so.

10. NZD billing and GST invoices

Small, but it shows up every month. Hosting billed in US dollars moves with the exchange rate, and an invoice without GST on it is an annoyance for your accountant and a bit of tax you don’t get back.

The short version to send a host

Copy these into an email and see how the replies compare:

1. How does your page cache handle a WooCommerce store, beyond excluding the cart and checkout?
2. What do you do about WooCommerce cart fragments?
3. How many PHP workers does my plan get, and what happens when they’re all busy?
4. Is Redis or Memcached included?
5. How often are backups taken, how far back do they go, and how fast is a restore?
6. Is staging included, and can I push files without overwriting orders?
7. Do you set up transactional email, or is that on me?
8. Where is the server, and who answers support at 10am New Zealand time?
9. Do you migrate my store for free, orders included, with no downtime?

A host that answers all 9 clearly is a host that has hosted stores before.

Where PrestoWP sits

We built WooCommerce hosting in NZ around that list. WooCommerce-specific caching and a replacement for the cart fragments script are switched on for every store rather than sold as an eCommerce tier. Daily backups include your orders, staging is included, and we set up Amazon SES so receipts arrive.

The platform underneath is WP Engine’s Sydney region, the closest to New Zealand, with a global CDN in front. PrestoWP itself is NZ-owned and operated, support is Auckland-based and works NZ hours, and you’re billed in NZD with GST invoices.

Worth reading next: managed versus shared hosting for NZ businesses if you’re still on a cheap plan, or the hosting plans if you know what you’re after. Moving an existing store is free and handled by us, products, orders and customers included, and here’s how a migration runs without downtime if you want the detail first.

A slow website is usually blamed on the website. Too many plugins, images that are too big, a theme doing too much. Often that’s fair.

Sometimes though, you’ve done the work. The images are compressed, the plugin list is short, caching is on, and the site is still sluggish. At that point the problem is underneath you, and no amount of tidying your own site will fix it.

Here are the signs that it’s the hosting, how to check in about 10 minutes, and the honest list of things that aren’t your host’s fault.

7 signs it’s the hosting

1. wp-admin is slow while the front end looks fine

This is the clearest tell there is. Your public pages are served from a cache, so they can look quick on almost any host. The admin can’t be cached at all, so every click hits the server and the database directly.

If saving a page takes 8 seconds and the media library crawls, you’re seeing what your server is really like without the cache hiding it.

2. Time to first byte over about 600 milliseconds

TTFB is how long the server takes to start answering. It’s the one number that points squarely at the platform rather than your design, because it’s measured before a single image or script has loaded.

Under 200ms on a cached page is good. Around 500ms is ordinary. Consistently over 600ms on a cached page and something is wrong with the server, the stack or the distance.

3. It’s fast at 6am and slow at 1pm

Your site’s own code doesn’t change during the day. What changes is how much of the server other people are using.

On shared hosting you’re on a machine with hundreds of other sites. A neighbour running a big import or getting a traffic spike takes the resources you were relying on. Time of day dependent speed is a shared hosting signature.

4. Resource limit emails, 503s, and mysterious 5 minute outages

“You have reached your CPU limit.” “Entry processes exceeded.” A 503 or 508 error for a few minutes and then it’s fine again.

Those messages mean your plan has run out of headroom and the host is throttling you. They’ll suggest an upgrade. Sometimes that’s genuinely the answer, and sometimes the plan you’re on was never sized for a site that does anything.

5. Uploads and updates time out

A 3MB image that fails to upload. A plugin update that hangs and leaves the site in maintenance mode. An import that dies halfway.

Those are server limits set low and left there: PHP memory, execution time, upload size. A good host sets sensible values and can raise them when you ask.

6. The backup plugin slows the site down

If your nightly backup makes the site unusable while it runs, that tells you how little spare capacity you’re working with. On managed WordPress hosting backups happen at the server level and visitors never feel them.

7. Support takes 2 days and tells you to disable your plugins

The reflex reply. Sometimes a plugin genuinely is the culprit. A host who can’t look at their own server metrics and tell you whether the slowdown is yours or theirs isn’t looking.

How to check it yourself in 10 minutes

You don’t need tools you have to pay for.

• Measure TTFB. Open your site in Chrome, press F12, go to the Network tab and reload. Click the first request in the list and read the “Waiting for server response” figure. Do it 3 times, ignore the first.
• Run PageSpeed Insights. Look at the mobile score, and specifically at Largest Contentful Paint and “Initial server response time”. Google flags a slow server response separately from your page weight, which is the distinction you’re after.
• Test at 3 different times. Early morning, midday, evening. Big swings point at a shared server.
• Compare logged out with logged in. Logged out you get the cache. Logged in you get the raw server. A huge gap means the cache is carrying a slow platform.
• Install Query Monitor for an hour. Free, and it shows page generation time and slow database queries. Over about 1 second of server generation time on a normal page is worth investigating.

Write the numbers down before you change anything. Otherwise you’ll never know whether the fix worked.

What isn’t your host’s fault

Fair is fair. Plenty of slow sites are slow for reasons no hosting can rescue:

• Uncompressed images. A 4MB hero photo straight off a phone camera will be slow on any server on earth.
• 40 plugins. Every one adds queries and scripts to every page load. Half of them are usually doing a job a few lines of code could do.
• Page builder bloat. Drag and drop builders generate deeply nested markup and load their whole framework on every page, whether the page uses it or not. They’re one of the most common reasons a site feels heavy.
• No caching at all. If nothing is cached, the server rebuilds every page for every visitor.
• Third party scripts. Chat widgets, tag managers, tracking pixels, embedded video, review widgets. They load from someone else’s servers and you inherit their bad days.

Sort your own side first. Then the numbers tell you the truth about the platform, and you’re not paying to move a bloated site onto a faster server.

What good actually looks like

Rough targets to hold a host to, measured on a real page rather than the homepage of a demo site:

• TTFB under 200ms on a cached page from a New Zealand connection.
• Largest Contentful Paint under 2.5 seconds on mobile, which is Google’s threshold and part of how you’re ranked.
• wp-admin that feels immediate.
• The same speed at 1pm as at 6am.

If your own site is tidy and you can’t hit those, the hosting is the ceiling.

Running a shop? The bar is higher again, because most of a store can’t be cached. What to look for in WooCommerce hosting goes through the specifics, and WooCommerce hosting NZ is how we handle them.

If it is the hosting

Moving is less painful than most people expect, and it doesn’t have to take the site offline. We wrote a full walkthrough of how to migrate a WordPress site without downtime if you want to do it yourself.

If you’d rather not, that’s what we do. PrestoWP is managed WordPress hosting from an NZ-owned business, running on WP Engine’s Sydney region with a global CDN, server-level caching and daily backups. Support is Auckland-based in NZ hours, we host WordPress sites right across New Zealand, and billing is NZD plus GST.

Still weighing it up? Managed versus shared hosting covers where the line sits, the plans are here, and migrations are free on all of them.

Or send us the address and we’ll run the numbers by hand and email you what’s actually slowing it down, whether or not you move to us. Ask for a speed check.

Most people stay on bad hosting for one reason. They’re frightened of the move. The site is earning, the phone rings when it’s down, and nobody wants to be the person who broke it on a Tuesday afternoon.

Here’s the thing worth knowing before you start: a WordPress migration doesn’t have to take the site offline at all. Done properly, the old site keeps serving every visitor right up until the moment the new one takes over, and nobody outside your business notices anything happened.

This is how that works, and where the downtime actually comes from when a move goes wrong. If you’re still deciding whether the hosting is even the problem, start with the signs your current host is slowing down your site.

The 2 kinds of downtime

The obvious one is the site being unreachable. Someone deletes the old copy before the new one is ready, or points the domain at a server that isn’t finished, and visitors get an error page.

The sneaky one is worse. Your site stays up the whole time, but for a few hours some visitors land on the old server and some land on the new one. Both are live. Both accept orders. Then you switch off the old host and 6 orders, 4 enquiries and yesterday’s blog post vanish with it.

Nobody logs that as downtime. It costs a lot more than downtime does.

The rule that prevents both

You never turn the old site off. You build a complete copy on the new host, test it properly while the live site carries on as normal, then point the domain at the copy. The old site stays running for weeks afterwards as your rollback.

Everything below is in service of that.

Step 1: Take stock before you touch anything

Write down what you actually have. PHP version, WordPress version, plugin and theme list, database size, how big the uploads folder is, any scheduled jobs, and anything custom that a previous developer bolted on.

Two things catch people out here. Hard-coded URLs sitting in theme files or plugin settings, and email. If your domain’s email runs through the same provider as your hosting, changing nameservers can take your mailboxes down along with everything else. Find out before, not after.

Step 2: Drop your DNS TTL a day early

TTL is how long the rest of the internet is allowed to remember your old server’s address. Set to the common default of 24 hours, some networks will keep sending visitors to the old host for a full day after you’ve switched.

Drop it to 300 seconds at least 24 hours before cutover. Now the switch propagates in minutes rather than a day, and your split-brain window shrinks from hours to almost nothing. Put it back to normal a few days later.

This single step is the difference between a clean move and a messy one, and it’s the one that gets skipped most often.

Step 3: Copy the site, don’t rebuild it

Files and database, complete, onto the new host. Rebuilding by hand on a fresh install introduces small differences you’ll discover weeks later, usually in the settings nobody documented. A copy means what you test is what you get.

When the URLs get updated for the new environment, they have to be updated with a tool that understands serialised data. A plain find and replace across a database dump will corrupt widget settings, theme options and half your plugin configuration, and the damage often doesn’t show up until a week later.

Step 4: Test on a temporary address

Every decent host gives you a temporary URL, or a staging site you can test against, or you can point your own machine at the new server with a hosts file entry so you see the new site on the real domain while the world still sees the old one.

Then behave like a customer, not like an admin:

• Buy something, or book something, all the way to the confirmation screen.
• Submit every form and check the notification email arrives.
• Log in as a customer and open the account pages.
• Open 10 pages at random, including a category page and a search result.
• Check images load from the new server rather than the old one.

If the site uses payment gateways, this is also when you confirm the gateway will accept requests from the new server’s IP address. Some do care.

Step 5: Get the SSL certificate issued before you switch

A surprising amount of what people call migration downtime is a browser security warning. The domain moved, the certificate on the new host hadn’t been issued yet, and for 20 minutes every visitor saw a red screen telling them your site isn’t safe.

Have the certificate in place on the new host first. Most platforms can issue one for a domain that isn’t pointing at them yet.

Step 6: Final sync, then switch

Between the day you copied the site and the day you cut over, real things happened on the live site. Orders, enquiries, a new post, a price change.

So on cutover day you stop editing the old site, run one last sync of the database and uploads, and switch DNS immediately after. Pick a genuinely quiet hour. For most New Zealand businesses that’s early morning; for a store selling to the northern hemisphere it might be the middle of your afternoon.

With a 300 second TTL, traffic lands on the new host within minutes.

Step 7: Watch the first 48 hours

Check that order and contact form emails are arriving, because transactional email is the thing most likely to break quietly on a new server. Check scheduled tasks are firing. Watch for 404s and mixed content warnings.

Leave the old hosting account alive for 2 to 4 weeks. It costs one more month and it’s the only real rollback you have. Take a full backup off it before you cancel.

Stores, memberships and anything that writes data

If you run a WooCommerce store or a membership site, the split-brain problem is the whole game. A visitor whose network still resolves to the old server can place an order on a database you’re about to abandon.

Three ways to handle it, in order of preference. Cut over in your quietest hour with a short TTL, which keeps the exposure to minutes. Or hold new orders for that window with a brief maintenance notice. Or sync the order tables across once more after DNS has settled, which needs someone who knows what they’re doing with a live store.

Whichever you pick, decide it deliberately. A store migration that ignores this is where the “we lost 3 orders” stories come from. If you’re moving a shop, it’s worth reading what to look for in WooCommerce hosting before you pick the destination.

The mistakes that cause real downtime

• Changing nameservers before the new site exists, which points the domain at nothing.
• Changing nameservers without copying the MX and TXT records across, which takes email down and breaks SPF and DKIM.
• Cutting over with a 24 hour TTL still in place.
• Cancelling the old host the same day.
• Testing only the homepage while logged in as an administrator.

Or let someone else carry the risk

This is all doable yourself if you enjoy that sort of thing, and it’s the natural moment to ask whether you want to stay on the same kind of plan at all. Managed versus shared hosting covers where that line sits, and the benefits of managed WordPress hosting covers what changes once you move.

It’s also the kind of job that goes badly once and teaches you an expensive lesson. We do free WordPress migrations on every plan: we copy the site, test it, agree a cutover time with you, and handle the DNS. Typically 24 to 48 hours from your go-ahead, and your site stays up the whole way through.

PrestoWP is managed WordPress hosting for New Zealand businesses, NZ-owned and operated, with support from Auckland in NZ hours and billing in NZD plus GST. Have a look at the hosting plans, check the hosting FAQs, or tell us what you’re running and we’ll tell you honestly whether moving is worth it.

Every New Zealand business with a WordPress site runs into this decision sooner or later. The cheap hosting you signed up for at launch starts to creak, someone mentions managed hosting, and suddenly you’re comparing 2 products that sound identical and behave nothing alike.

This is the practical version. What each one is, where the differences bite, and how to tell which side of the line you’re on.

What shared hosting actually is

Shared hosting puts your site on a server alongside hundreds of others. Everyone draws from the same pool of memory and processing power, which is exactly why it costs so little. The host sells the same machine over and over.

For that money you typically get a cPanel login, a one-click WordPress installer, some email accounts, and not much else.

None of this is a scam. For a brochure site with light traffic, shared hosting does the job. The problems show up once your site starts earning: a busy neighbour slows you down, a hacked site 2 doors over gets the server’s IP blacklisted, and when something breaks, the support queue treats a down website with the same urgency as a forgotten email password.

What managed WordPress hosting does differently

Managed WordPress hosting runs one thing: WordPress. Because the platform never has to accommodate anything else, everything is tuned for it. Server-level caching, a CDN in front, firewall rules written for WordPress attack patterns, and PHP versions kept current.

The bigger shift is who carries the responsibility. On shared hosting you’re the one patching plugins, taking backups and hoping an update doesn’t break checkout. On managed hosting the platform takes daily backups automatically, updates WordPress core for you, scans for malware, and gives you a staging site so changes get tested before they touch the live site.

Speed is the difference visitors notice. The gap between a crowded shared server and a tuned managed stack is routinely measured in seconds, and Google measures it too.

Side by side

	Shared hosting	Managed WordPress hosting
Cost	A few dollars a month	More, priced for what it takes off your plate
Speed	Depends on your neighbours	Tuned stack, server caching, CDN
Backups	Often manual, sometimes a paid extra	Daily and automatic
Staging site	Rare	Included
Security	General-purpose	WordPress-specific firewalls and malware scanning
Core updates	Your job	Handled for you
Support	Generic hosting helpdesk	People who work in WordPress all day

When shared hosting is the right call

Genuinely, sometimes it is.

• The site is a brochure. If it went down for a day, you’d shrug.
• The site doesn’t take orders or bookings, and leads come from elsewhere.
• You like the tinkering and you’re comfortable in cPanel.
• The budget truly is the budget.

If that’s you, stay put and spend the difference elsewhere. Just take your own backups.

When managed hosting earns its keep

• The site makes money. WooCommerce, bookings, or leads that turn into invoices.
• Downtime costs more than hosting does. Do the maths on 1 lost day of orders.
• Nobody in the business wants to be the sysadmin. Updates, backups and security patches don’t happen on their own.
• You’ve been burnt before. A plugin update took the site down and there was no staging copy to catch it.

Most of the NZ businesses we talk to are past the shared-hosting stage without realising it. The site quietly became the main sales channel while the hosting stayed the same.

Does server location matter?

Some. Less than the marketing implies.

Distance adds latency, so a server in Sydney answers an Auckland visitor faster than one in Dallas. But once a site sits behind a CDN, cached pages are served from edge locations much closer to the visitor, and the origin server’s location matters mostly for uncached requests like checkouts and logins.

PrestoWP runs on WP Engine’s Sydney region, the closest one to New Zealand, with a global CDN in front. We’ll publish a full post soon on latency and what it does to load times for NZ visitors.

Where PrestoWP sits

PrestoWP is managed WordPress hosting from an NZ-owned and operated business. The platform underneath is WP Engine, the same infrastructure behind roughly 1.5 million sites worldwide. Support is Auckland-based and works NZ hours, and billing is in NZD plus GST, so there’s no card surprise when the exchange rate moves.

Have a look at our managed WordPress hosting plans and pricing, or read more about WordPress hosting for Auckland businesses and WordPress hosting across New Zealand.

Already on shared hosting? Moving is easier than you’d expect. We do free WordPress migrations with no downtime, and we handle the whole thing. If you want to see how that works step by step, read how to migrate a WordPress site without downtime.

Not sure whether your current setup is holding you back? Run through the 7 signs your host is slowing down your site first.

Still unsure which side you’re on? Tell us what the site does and we’ll give you a straight answer.