Learn how to avoid the dreaded “503 Service Unavailable” error when you run an Ad Campaign and your busy WordPress/WooCommerce site crashes.
What does 503 Service Unavailable mean?
The main point to take away from this is that the 503 Service Unavailable error doesn’t usually mean your site has “crashed”. It literally means the back-end PHP engine is not reachable by the HTTP server (Apache/Nginx/LiteSpeed) for some reason.
Most website hosting companies allocate a number of PHP workers to each website and each PHP worker can process one incoming requests at-a-time. So if your hosting package gives you 6 PHP workers, and it takes one second to generate a WordPress page, you can process six requests per second.
If all six PHP workers are busy and a seventh request comes in to the HTTP server, it will wait until the next PHP worker becomes available. If no PHP worker becomes available in a reasonable time, the HTTP server returns a 503 Service Unavailable.
When people blame high traffic for a website crashing, they really mean their hosting package cannot handle enough incoming parallel requests – there is a “bottleneck”.
Key points
- Cheaper hosting packages will allocate fewer PHP workers, perhaps only one. You get what you pay for.
- If a page-load uses JavaScript Ajax call-backs, each of those will need a PHP worker too.
- Even if a WordPress page is cached, we still need a PHP worker to find the correct cached HTML and return it. This happens very quickly (just a few milliseconds) compared to 1+ seconds for uncached pages.
- Using the WordPress/WooCommerce admin area consumes PHP resource. So if you have multiple admin-area tabs open, or multiple staff members using the admin-area, there will be fewer PHP workers available for your customers.
- Website marketing campaigns typically generate very high spikes in traffic that tail off quite quickly. It might be that your website usually serves 5-10 customers an hour. But sending out 2,000 emails in one hit might result in 50 visitors trying to access your landing page at the same time.
Optimise your page’s PHP requirements
Here’s the technical bit…
We need to figure out how many PHP workers it takes to render the landing page. To do this, we’re going to look at the site’s page-load waterfall. I use GTmetrix for this – they have a free plan and the tools are clear and easy to use.
Here’s a report from https://headwall-hosting.com/website-hosting-and-email/
The top row is the response for the initial HTML – this always has to go via a PHP worker. The response is only 46ms because the page is cached and the hosting is solid. That looks OK.
Important: Make sure you’ve configured page caching on your site. The initial HTML response should always be less than 100ms. Your web developer or hosting provider can help you with this.
The next four PHP requests:
- POST search: This is the Independent Analytics plugin sending anonymous visitor metrics back to the site. It’s like a self-hosted Google Analytics, and it needs to use a PHP worker so it can access the database.
- schema: Contact Form 7 is getting the schema for the form that’s embedded on the page.
- POST ?wc-ajax… : This is WooCommerce fetching information on the contents of the visitor’s cart so it can update the mini cart.
- refill: Another Contact Form 7 request that relates to the customer-enquiry form that’s on the page.
Reduce server load
What we need to do is reduce the number of Ajax calls on the page. In the above example, I’m going to get rid of the contact form and replace it with a link to the site’s contact page. That will completely remove the “schema” and “refill” call-backs.
After replacing the contact form with a link/button and running a new test, we get this:
In both cases the pages takes about 1.2 seconds to fully load (around 750ms LCP) so the page-speed tests will look the same during normal-traffic periods. But the updated page uses 1 PHP worker to serve the HTML and only two PHP workers in parallel to run the analytics and Ajax cart. This is an improvement on the original version that required four parallel PHP workers to process those Ajax call-backs. This means we should be able to serve about twice as many customers at the same time without increasing our hosting resources – win 👍
Running a WooCommerce marketing campaign
Running an email marketing campaign for a WooCommerce site generates a large spike in traffic that lasts for a few minutes. Traffic will fall reasonably quickly but still be higher than usual, then it will taper off over a few hours and return to normal. It’s the initial big spike that causes problems for web servers if you don’t prepare properly.
Tips for surviving a website traffic spike
- Stagger your marketing emails to go out in smaller bursts over the course of the day.
- During very busy traffic spikes, close as many WordPress admin-area browser tabs as you can. i.e. if you have several staff members accessing the WooCommerce back-end ask them to log out for an hour.
- Reduce the amount of PHP resource your landing page needs by reducing the number of Ajax call-backs.
- Temporarily increase your website hosting capacity (add more PHP workers to your hosting package).
By making your landing page efficient and staggering your emails, most small-to-medium web shops will survive a marketing campaign. But if you think you need to temporarily increase your hosting capacity… look at how many PHP workers you need per page load, estimate how many visitors you expect to see every second for the first 10 minutes of your campaign, and tell your hosting provider. They will be able to allocate the relevant PHP workers to your hosting package – usually for a 24 hour period.
That’s it… with a bit of planning and testing, you can avoid the 503 error message.
Good luck with your website marketing campaigns 😎👍
