From site health warning to all green customs clearance
1. Discover problems
Recently, in Tools → Site Health in the WordPress background, I found a ‘critical problem’:
Page cache is not detected, and the server response time is slow
As shown in Figure 1, site health directly suggests that this is a problem that may have a major impact on performance or security and needs to be addressed first.
- The median response time of the server is 656ms, and the recommended critical value is 600ms, which has exceeded the standard.
- Page cache plugin not detected.
- The client cache response header is not detected.
This means that every time a user accesses, the server has to dynamically generate pages, which is both slow and resource-intensive. I decided to fix it completely.
Learn more about page caches (open in new window)https://developer.wordpress.org/advanced-administration/performance/optimization/#cachingas shown in Figure 2
The cache plugin is easy to install and caches your WordPress articles and pages as static files. These static files are then provided to the user, reducing the processing load of the server. This can improve performance hundreds of times for relatively static pages. You can get a list of related plugins by searching for ‘cache’ in the plugin directory.
2. Selection plan
I started researching various cache plugins. I searched for the result of ‘cache’ in the WordPress plugin library, and there are many options.
After comprehensive comparison, I locked three mainstream plugins:
| plugin | Advantage | Shortcoming |
|---|---|---|
| wp super cache | Simple and lightweight, suitable for beginners | relatively single function |
| LiteSpeed Cache | Extreme performance, but rely on LiteSpeed server | My Alibaba Cloud ECS is an Nginx environment and cannot give full play to its greatest advantages |
| W3 Total Cache | Comprehensive functions, support Redis/Memcached, the favorite of technology enthusiasts | The configuration is slightly more complex, but the playability is high |
Figure 15 is the screenshot of the interface where I finally chose the W3 Total Cache. Its function covers page cache, database cache, object cache, browser cache, CDN, etc., which is very in line with the needs of my subsequent writing performance optimization series of articles.
3. Installation and basic configuration
3.1 Install the plugin
Install and activate the plugin, W3 Total Cache, as shown in Figure 4 is the activation welcome interface, it provides a ‘Settings Guide’ wizard, which is very friendly.
3.2 Page Cache Engine Test
The first step in the wizard is to test the storage engine of the page cache. Figure 5 is the test result:
| storage engine | Delay (ms) | Relatively improve |
|---|---|---|
| No | 846.38 | – |
| disk: basic | 25.40 | -97.00% |
| Disk: Enhanced | 24.81 | -97.07% |
| redis | 28.84 | -96.59% |
Disk: Enhancement is not only the fastest, but also officially recommended. I chose it without hesitation.
3.3 Database Cache Engine Test
Figure 6 is the test result of the database cache:
| storage engine | Delay (ms) | Upgrade |
|---|---|---|
| No | 9191.75 | – |
| Computer disk | 293.43 | -96.81% |
| redis | 290.52 | -96.84% |
Redis is slightly faster than disk, and the plugin prompts ‘Redis or memcached’ is recommended, so I chose Redis.
3.4 Object Cache Engine Test
Figure 7 is the test result of the object cache:
| storage engine | Delay (ms) | Upgrade |
|---|---|---|
| No | 170.08 | – |
| Computer disk | 150.29 | -11.64% |
| redis | 38.26 | -77.50% |
Redis has a huge advantage, and the delay has dropped from 170ms to 38ms. No doubt, continue to choose Redis.
3.5 Picture conversion function
Figure 8 is the interface of Image Converter. I chose not to enable for three reasons:
- It is a third-party remote conversion (depending on w3-edge.com’s API) with very little free quota (100 times/hour, 1000 times/month).
- The picture needs to be uploaded to someone else’s server, there are privacy concerns.
- Local conversion plugins (such as eWWW, IMAGIFY) are more free and unlimited.
3.6 Delayed loading images
Figure 9 is the setting interface for delayed loading. I checked ‘Enable Lazy Loading’ and keep the default options.
Then view the source code of the web page, as shown in Figure 11, the image label appears class='lazy', which means that the W3 Total Cache successfully added a lazy loading tag to the picture.
3.7 Complete the installation
Figure 10 is the summary page after the installation is complete, showing:
- Page Cache: Disk: Enhancement (ttfb increased -97.07%)
- Database cache: redis
- Object Cache: Redis
- Image conversion: not enabled
- Delayed loading: enabled
4. Functional compatibility test
4.1 Views Statistics
I am using the Post Views Counter plugin. Due to the existence of the page cache, I thought the PHP mode would be invalid (as shown in Figure 12).
Figure 13 is the count mode setting interface of the Post Views Counter.
I switched the mode from ‘php’ to REST API. Tests found:
- Views of the backend article list grew normally (from 60 to 66).
- But the foreground page is still 60 due to the cache.
Figure 14 is a comparison screenshot after emptying the W3 Total Cache page cache, and the front desk number is finally synchronized to 66. After observation every day, the number of views continues to increase, which proves that the REST API mode is working normally in the cache environment.
I actually tested it in PHP mode and found that the number of views will also grow. But I ended up choosing REST API mode.
4.2 Comment function
I personally posted a test review, as shown in Figure 16. The page displays new comments immediately after submission, and there is no delay or refresh exception, indicating that the mechanism of W3 Total Cache to process comment cache is very smart (will refresh the cache of the current page, or use AJAX comments).
4.3 Delayed loading images
With the developer tool’s Network panel scroll test (as shown in Figure 17), I confirmed:
- The first load is only requested for the first screen image.
- When scrolling down, new pictures appear in network requests one after another.
Delayed loading works perfectly.
The final result
Entering Tools → Site Health, the previous ‘1 critical issue’ has disappeared and the status has become ‘Good’. As shown in Figure 11.
6. Summary and next step plan
Through this optimization, I deeply realized that page cache is the first productivity improvement of WordPress performance. The combination of W3 Total Cache + Redis performed extremely well on Alibaba Cloud ECS.
