Peak-Season Website Readiness for Singapore Online Sellers (11.11 to Year-End)
The busiest weeks of the retail year are close. In 2026, 11.11 falls on a Wednesday, Black Friday on 27 November and 12.12 on a Saturday. If you sell through your own website, the question is not only whether traffic will arrive, but whether your site can turn it into completed orders.
This guide is a dated runbook for founders, e-commerce managers and the IT leads who support them. It assumes you already have a live store and want to avoid surprises, not choose a platform from scratch.
Table of contents
- Executive summary
- Quick answer
- Build a peak calendar from your own data
- A timeline you can copy
- Two weeks out: reduce weight and test the buying path
- One week out: get ready to recover
- Three days out: freeze changes and brief the team
- Check capacity before the campaign, not during it
- During the campaign: watch, do not tinker
- If the site slows down mid-sale
- Common mistakes to avoid
- Frequently asked questions
- Key Takeaways
- Compare hosting plans before the peak
- Related articles
Executive summary
A peak sale rarely breaks a site in one dramatic moment. Slowdowns usually trace back to heavy pages, caching set up the wrong way, a checkout step nobody tested, a late plugin update or a backup running at the wrong hour.
Use the next two weeks for four jobs: cut page weight, test the full buying path, take a backup you have restored once, and freeze changes. Then agree who watches the site on each campaign day.
Quick answer
Start two weeks before your first campaign day. Test the whole path from product page to payment confirmation on a phone, take and test a backup, stop non-essential changes about three days before launch, and monitor uptime and orders while the campaign runs. Treat a hosting upgrade as one option, decided with measured evidence rather than as a last-minute fix.
Build a peak calendar from your own data
Start with dates, then add your own history. Dates worth placing on your plan for 2026 are 11.11 (Wednesday 11 November), Black Friday (Friday 27 November), Cyber Monday (Monday 30 November), 12.12 (Saturday 12 December) and the Christmas period. Add every email blast, influencer post or marketplace campaign of your own, because these create the real spikes.
Next, open last year's analytics. Note your busiest hour, your mobile share and the pages where visitors left. If you have no history, write down a conservative estimate from your campaign plan. A target you can test against, such as "checkout stays responsive when three times our usual daily visitors arrive in one hour", is more useful than a feeling that the site should cope.
If you are unsure whether your current plan can carry that load, our guide on when to upgrade from shared hosting explains how to measure first.
A timeline you can copy
| When | What to do | Done when |
|---|---|---|
| Two weeks out | Audit page weight, plugins and third-party scripts. Test the full purchase path. | Key pages load acceptably on mobile and test orders complete. |
| One week out | Apply updates, take a backup, test a restore and confirm caching rules. | A restore has worked once in an isolated environment and updates are tested. |
| Three days out | Freeze changes, set up monitoring and share a contact sheet. | No new plugins, themes or checkout changes are pending. |
| Campaign days | Watch uptime, orders and error messages. Pause heavy admin jobs. | A named person owns each shift. |
| After the peak | Review slow periods, failed payments and support tickets. | A short written review exists before January. |
Two weeks out: reduce weight and test the buying path
Before you spend anything on hosting, check what the site itself asks visitors' browsers to load.
- Compress and resize images. Large banners and uncompressed product photos are a common cause of heavy mobile pages. Use modern image formats where your platform supports them.
- Review plugins and third-party scripts. Remove what you no longer use. Every chat widget, tracking pixel and pop-up adds requests, so keep what supports sales and test the rest.
- Check caching rules. Public pages such as the home page and category pages can usually be cached. Cart, checkout and account pages should not be served from a shared cache. Confirm the correct settings in your platform's documentation.
- Place test orders on a phone using mobile data. Try each payment method you offer, such as cards or PayNow, along with discount codes, delivery options and the confirmation email.
- Check how prices display at checkout. If you are GST-registered and display prices to the public, show GST-inclusive prices. Where you also show GST-exclusive prices, the inclusive price must be at least as prominent. Check that this holds across product pages, discounts, delivery charges and checkout, through to the receipt. See IRAS guidance on displaying and quoting prices.
- Measure on mobile. Google's Core Web Vitals guidance treats a Largest Contentful Paint of 2.5 seconds or less, an Interaction to Next Paint of 200 milliseconds or less and a Cumulative Layout Shift of 0.1 or less as good, assessed at the 75th percentile of visits.
One week out: get ready to recover
Preparation here is about two outcomes: the site stays stable, and you can return to a known good state quickly if something fails.
- Update early, then stop. Apply pending core, plugin and theme updates a week out so there is time to test. Updates on the eve of a sale are a common source of avoidable faults. Our website security checklist covers logins, permissions and update routines.
- Take a full backup and restore it once. Keep dated copies of files and the database away from the live server. A backup you have never restored is an assumption, so test the restore in an isolated environment, such as a staging copy, never over the live store. Restoring an older production database would also lose newer orders, payment records and stock changes, which then have to be reconciled. Z.com's web hosting plans list free automated backups, and the plan page also advises keeping your own manual copies.
- Use staging for changes. If your plan includes a staging site, use it. Otherwise test on a copy of the store, never directly on the live checkout.
- Protect order emails. Order confirmations and password resets must reach customers' inboxes. Recheck your records using our SPF, DKIM and DMARC guide.
- Avoid migrating now. Moving hosts during peak season adds DNS and email risk. If a move is already planned, finish it before your freeze or schedule it for January, using the website migration checklist.
Three days out: freeze changes and brief the team
Agree a change freeze. No new plugins, theme edits, checkout experiments or pricing-structure changes unless you are fixing a fault. Involve marketing, because campaign pages and banners count as changes too.
Share a one-page contact sheet. It should list who watches the site on each campaign day, who can contact the host, where backups are stored, where your payment provider's status page and support contact are, and what to check first if the site goes down.
Set up uptime monitoring with alerts that reach more than one person, by SMS or app notification. Then trigger a test alert so you know it works.
Check capacity before the campaign, not during it
Ask your host now what resource limits apply to your plan, such as CPU, memory and concurrent processes. Also ask how a limit error appears, how quickly you can upgrade, and whether load testing is permitted. Do not run a load test against a live site without checking the host's policy, because it can look like an attack or breach the terms of service.
On Z.com Singapore, the Business web hosting plans list resources of 2 GB RAM and 2 vCPUs (Launch), 4 GB and 2 vCPUs (Grow), 8 GB and 4 vCPUs (Scale) and 16 GB and 8 vCPUs (Thrive). Plans also list a free SSL certificate. More resources will not repair heavy pages or an untested checkout, so complete the earlier steps first. Review current SGD pricing, how GST is shown and renewal terms on the hosting comparison page before you buy.
During the campaign: watch, do not tinker
- At the start of each campaign day, follow the buying path on a phone up to the payment step.
- Watch uptime alerts, order counts, payment failures and customer messages. A sudden drop in orders with normal traffic can point to a checkout fault even when the site appears to be up.
- Pause heavy background jobs such as product imports, bulk edits and large reports during the busiest hours. Reschedule heavy full backups to quieter hours, and keep order data protected at a frequency that matches how much data you can afford to lose.
- Record the time, page and error message each time a problem appears, so your host can investigate.
If the site slows down mid-sale
Work through these steps in order, so you fix the cause instead of guessing.
- Check whether the problem is on your site, with your payment provider or on a marketplace, using their status pages.
- Review what changed in the last 24 hours.
- Pause heavy jobs and non-essential scripts, if you can do so safely.
- Contact your host with times, URLs and error messages, and ask whether a resource limit was reached.
- Decide on an upgrade only with that evidence. If a limit was reached, upgrading may be right even mid-campaign, but retest the site afterwards.
Common mistakes to avoid
Caching the cart and checkout
Customers can see stale baskets or someone else's content. Cache public pages only and test as a guest.
Updating on the eve of the sale
A late update leaves no time to test or roll back. Update early, then freeze.
Testing only as a logged-in admin on office Wi-Fi
Logged-in sessions may bypass caches, so they are not representative of what customers experience. Test as a logged-out guest on mobile data.
Frequently asked questions
How early should I make hosting changes before 11.11?
Aim for at least a week, and ideally two, so there is time to test and roll back. Avoid structural changes in the final three days.
Do I need to load test my store?
A simple test of your main journey is useful, but only with your host's permission, and ideally against a staging copy. If that is not possible, ask several colleagues to browse and check out at the same time while you watch response times.
What should I check first if checkout is slow?
Start with your payment provider's status page and any recent changes. Then check for heavy background jobs, and ask your host about resource usage.
Key Takeaways
- Set a testable peak target from your own analytics and campaign calendar.
- Fix page weight, caching rules and checkout problems before considering an upgrade.
- Restore a backup once, update early and freeze changes three days out.
- During the campaign, monitor orders as well as uptime, and keep changes to a minimum.
Compare hosting plans before the peak
If your preparation shows that your current plan may be close to its limits, compare the resources, backups and SSL listed on each Z.com Singapore plan while there is still time to test.