When to Upgrade from Shared Hosting: A Sizing Guide for Singapore SMEs

Your site ran smoothly at launch. Then a campaign, a bigger catalogue or a few extra plugins arrived, and pages began to feel slow. Before you pay for a bigger plan, it helps to know whether hosting is really the bottleneck. This guide shows how to tell, how to size the next step, and how to move without disrupting customers.

Signs your site may have outgrown shared hosting

Shared hosting places many sites on one server and divides its resources between them. That suits small, steady sites well. Look for a pattern rather than a single bad day.

• Slowdowns repeat at busy times. Pages are fine late at night but crawl during sales or email campaigns.
• Resource-limit or "temporarily unavailable" errors appear. Ask your host what each message means and which limit was reached.
• The admin area drags. Saving products, running imports or taking backups takes much longer than it used to.
• The site has grown. You now have more products, media, plugins or a larger database than when you chose the plan.
• Plan limits are close. Plans commonly cap storage, the number of sites or the number of files (inodes).
• You need more control. Your project needs server software or settings that a shared plan does not allow.

Rule out other causes first

Hosting is only one part of speed. A bigger plan will not fix a page that is slow for other reasons. Check these first:

• Heavy images and scripts. Oversized images and many third-party scripts slow pages on any server.
• Outdated software. WordPress recommends PHP 8.3 or greater and MariaDB 10.11 or greater (or MySQL 8.0 or greater). Confirm your plan supports current versions.
• No caching. Page caching can reduce the work your server repeats for every visitor.
• Unused plugins. Remove what you do not use. One heavy plugin can cost more speed than a plan tier gains.

Then use published benchmarks. Google's web.dev guidance gives time to first byte (TTFB) as a rough guide: 0.8 seconds or less is good, and above 1.8 seconds is poor. TTFB is not a Core Web Vital, but a consistently high figure, especially at peak times, points towards the server side.

For overall experience, the Core Web Vitals "good" targets are Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less, measured at the 75th percentile of page loads. Layout shift is usually a front-end issue, so a bigger server rarely fixes it.

Measure for two weeks before you decide

A short baseline turns a hunch into evidence. Test the same key pages, such as your home, product and checkout pages, at the same times each day.

Choose the next step: three paths

If the evidence points to hosting, you have three common options. The right one depends on your platform and how much server work your team can take on.

How Z.com's higher web hosting tiers compare

Z.com's web hosting comparison page lists the following for its upper tiers at the time of writing.

Z.com also offers WordPress Hosting, which lists a web application firewall and a staging site on all plans, and a Cloud VPS described as self-managed with full root access. Confirm current SGD pricing, GST treatment and renewal terms on the plan page before you order.

Size for your busiest week plus some headroom, not for an average day. Paying for capacity you use only twice a year is rarely necessary, so ask what a later plan change involves.

A realistic example

This is an illustrative scenario, not a customer case. A Singapore online seller runs a WordPress shop with a growing catalogue. Each year-end sale, checkout slows and the dashboard lags while staff upload products.

The team records response times for two weeks, compresses images, updates PHP and turns on caching. Peak-time slowdowns remain, and the host confirms that the account is reaching a resource limit. Only then does a plan with more listed CPU and memory make sense. They schedule the move for a quiet week, not the week before the sale.

Plan the move to keep downtime low

1. Back up your files, database and email, and keep a copy away from the server.
2. Choose a quiet window well before your next campaign.
3. Lower your DNS TTL a day or two ahead so the switch spreads sooner.
4. Copy the site to the new plan and test it on a temporary address or staging site before changing DNS.
5. Switch DNS, then check forms, checkout, logins and email.
6. Keep the old plan until you are sure everything works.

Z.com's hosting transfer page explains how to move a site to its cPanel-based hosting, including staging, DNS and email steps. It notes that domain transfer is separate from website migration, and that DNS propagation cannot be expedited and can take up to 48 hours.

Questions to ask before you pay

Ask these of any provider, and get the answers in writing where they matter to your business.

• Which resource limits apply (CPU, memory, disk activity, processes, files), and what happens when I reach one?
• How often are backups taken, and how do I restore one?
• Which support channels are available, and during what hours?
• Where will my data be hosted, if my contracts or customers require that to be known?
• What is the renewal price after the first term, and is GST included or added?

Common mistakes to avoid

Frequently asked questions

This guide is educational. Plan details and prices change, so confirm them on the provider's pages before you buy.