After adding WooCommerce to the reikaxubia.com website, things started falling apart. The EC2 server, which had been running smoothly after the image migration fix, began experiencing frequent crashes again. Pages would take forever to load, and the site would go down entirely under even modest traffic.
The Problem
WooCommerce is a powerful e-commerce plugin, but it's also resource-intensive. Every page request was triggering significant server-side processing — database queries, PHP execution, dynamic page generation. The server simply couldn't keep up.
I upgraded the EC2 instance to 2 vCPUs and 8GB of RAM, which is a substantial amount of resources for a WordPress site. But the crashes continued. The extra hardware helped, but it wasn't addressing the root cause.
The Clue
The WordPress Health Screen provided the answer, just as it had with the disk space issue. This time, it warned about a missing page cache. WordPress was regenerating every page from scratch on every single request — querying the database, executing PHP, assembling the HTML, and sending it to the browser. For pages that don't change between requests (which is most of them), this is enormously wasteful.
The Solution
I installed the WP-Optimize plugin and enabled page caching. That's it. It takes less than a minute to do.
With page caching enabled, WordPress generates each page once and then serves the cached version to subsequent visitors. Instead of running dozens of database queries and PHP operations for every page view, the server simply sends a pre-built HTML file. The difference in performance was dramatic and immediate.
The server stopped crashing. Page load times dropped significantly. The site could handle far more concurrent visitors without breaking a sweat. All from enabling a single setting in a free plugin.
Update: September 4, 2024
After running with page caching for about a month, I had some additional observations. The cached pages performed extremely well — static content was being served quickly and efficiently, and the server had no trouble handling normal traffic loads.
However, dynamic processing still required real resources. Things like user login, WooCommerce cart operations, and admin panel access couldn't be cached (and shouldn't be — they need to be dynamic by nature). These operations still demanded CPU and memory.
With this in mind, I decided to test whether the server could sustain the workload on a smaller instance. I reduced the server from 2 CPUs and 8GB of RAM down to 2 CPUs and 4GB of RAM. The goal was to find a sustainable balance between performance and cost. Since the vast majority of page loads were now served from cache, the reduced resources only needed to handle the occasional dynamic request.
So far, this configuration has held up well. It's a good reminder that throwing more hardware at a problem isn't always the answer — sometimes the right software optimization can save you both money and headaches.