Translated from 日本語 • View original This is a memorandum from when I was building a multilingual site with WordPress, and I was doing performance tuning for the entire construction site when the integration test was almost over.
The target site was not that large, so I was building it on an AWS m3.medium instance, but the overall performance of the site deteriorated from the middle of development, and it became a much heavy site. Site performance verification Looking at the report on "GTmetrix", the only result is that the response of the images used in the site is latency, so for the time being, we optimized the images as much as possible, and the front-end performance improved considerably, but the WordPress admin screen remained heavy. GZIP compression of static content on the WEB server side, . I tried various measures such as migrating settings to httpd.conf without using htaccess, but it was ineffective. I also tried verifying and tuning the DB settings with MySQLTuner, but there was no particular change.
Hmm~m, if you look at CloudWatch, the CPU usage is extremely large, so it may be due to the incompetence of the AWS instance... In that case, it may be necessary to change the instance from the m3.medium instance to the c3 system in the end... I was thinking, but there must be another fundamental factor that the management screen is heavy on the site under development and is accessed by only a few people in the company. The only thing that is related to the entire site is a theme or a plugin. So, when I verified the performance of the plugin I was introducing, I found that Bingo! … The cause of the performance drop was the plugin.
This time, we used "P3 (Plugin Performance Profiler) to verify the performance of the plugin". " is. It's weird to put another plugin in to verify the performance of a plugin, but this P3 plugin is pretty good at scanning and reporting on the performance of plugins and themes on your WordPress site down to the smallest detail. It is easy to install, and once you download and activate the plugin, you can always perform a performance scan from the "Tools" section of the management menu.
The result of scanning with this P3 plugin is as follows.
You can see that the multilingual plug-in "Polylang" and the custom post type plug-in "Types" are putting pressure on the runtime. As expected, it is a multilingual site, so "Polylang" cannot be missed, but there are many similar plugins for custom post types, so they can be replaced. "Types" is a plugin that officially supports "Polylang", so I used it, but it is not easy to use because it takes up so much runtime just by extending custom posts.
Therefore, I removed the "Types" plugin and introduced the "Custom PostType UI" plugin that I am familiar with in the same system.
The runtime occupied by "Types" has been removed, and the plug-in load time and plug-in impact have been improved. The perceived speed of the management screen has also been improved dozens of times, and the original UX that allows for crisp editing has been revived. I wonder how a single plug-in can change performance so much... I was able to realize that.
From this incident, I personally thought that when creating a WordPress site in the future, it would be better to focus on performance rather than plugin functionality. This is because you can add as many things as you want later that are missing in the plugin's functionality, but it is very difficult to modify the performance that depends on the plugin's core.
In particular, if the management screen is heavy, the motivation of the web person in charge of operating the site will drop considerably, so I think it would be more pleasing to have a management screen that can be operated without stress even if it lacks a little functionality.