I happened to inherit a Wordpress site for a project I was working on. When I received it, it was in an ok state, it wasn’t that well optimised but it was ok. To get it working a bit faster I did some work on the site to optimise the network usage and reduce the asset sizes.
The site is multilingual, and one of the jobs I had to do was add the translations for a new language. Is used a plugin called WPML, and this is really where all the problems started. Entering the new language and updating some content in all languages was so problematic, I was left with no choice to rebuild the whole site using our custom framework, I had planned to do this at some point in the future, so this just moved it up the timetable.
This left an interesting situation, here I have 3 versions of the same website:
- The original Wordpress site
- An optimised version of the Wordpress site
- A custom built version
For this article, I thought it would be interesting to compare the performance of them, to document some of the optimisations I performed and the issues I encountered.
Optimising Wordpress
The site as it arrived wasn’t too bad, it loaded in just under a second, but the homepage weighed in at 2MB. It scored 59 on lighthouse for the performance test.
The first optimisation I performed was to add my Wordpress plugin Torque to the plugins list. This combined and minified the CSS and Javascript, and minified the HTML, reducing the size and number of requests. It also sets some headers to optimise subsequent page loads.
There was a rather large block of inline CSS that was loading into every page, so I moved this into an external stylesheet. The theme had a custom interface to set some other settings, which I used to reduce the size of the icon bundle. The fonts that were used were included externally from Google fonts, but it had the option to upload them locally so I swapped those out too.
Deciding to Rebuild
A little more detail on the issue that led me to rebuilt the site from scratch, this website now contains over 20 languages, I am not sure how the original developers managed to enter all the content in the languages it had when I inherited it, but I am guessing that the one I entered just tipped it over the edge.
The simple fact is that the language plugin beats Wordpress into doing something it was simply never designed to do (and quite frankly something it should do out of the box). This plugin invades almost every interface of Wordpress to enable you to do the same thing once for every language.
Having looked in the database, for a page it creates one post for every language, and then hides the pages except the one for the language it is currently showing and has some obfuscated JSON blob within each page that enables it to be tied all together.
Where it fell down was that I was unable to make an edit to a page in existing languages, I was only able to edit it in English. Also the menu synchroniser was so buggy I couldn’t link my menu in the new language, I ended up assigning 2GB RAM and 10 minutes of time to it, but it just sat there spinning until it timed out.
Building the Custom Site
The new site was built with our custom PHP framework, the base setup has a login and CMS, the pages are constructed with content blocks that can contain applications. The applications for this site were a prebuild FAQ application, and a custom-built partners list, as well as a number of different content layouts, and a carousel.
CSS is compiled from SCSS files, using some framework files, and some custom files to implement the design and site layout. Javascript the same using ES6, my jQuery clone library Dabby.js, and Rollup.
Copying the content over was really what took the time, even though the site only has 7 pages, with 20 languages, some of them right to left, I had to make some upgrades to our language system to support them, and then there was a LOT of copying and pasting to get all the content over.
Wordpress vs Optimised Wordpress vs Custom Build
So let’s compare the performance of all three sites:
Client-Side Assets
| Wordpress | Optimised | Custom | |
|---|---|---|---|
| HTML Size | 211kb | 120kb | 47kb |
| HTML Size Brotli | 90kb | 20kb | 11kb |
| CSS Size | 520kb | 462kb | 179kb |
| CSS Size Brotli | 88kb | 76kb | 20kb |
| Javascript Size | 845kb | 492kb | 27kb |
| Javascript Size Brotli | 229kb | 134kb | 10kb |
| Assets Size | 473kb | 571kb | 247kb |
| Assets Size Brotli | 473kb | 478kb | 185kb |
| Total | 2.05mb | 1.62mb | 499kb |
| Total Brotli | 888kb | 710kb | 227kb |
Whilst the optimised version showed an overall reduction in download size of 21%, the custom version smashed both with a reduction of 76%.
The HTML size reduced significantly from the base to the optimised site (-43%) as there was 3 huge blocks of Base64 encoded Figma code commented out in the body. Also I moved some CSS from inline to the external stylesheet. But the custom site enabled the HTML to be much leaner (-78%) as it was designed specifically for purpose, and didn’t have extra bloat of the generalised block builder.
The reduction in CSS and Javascript sizes between the base and optimised version showed that the base site was not that well optimised, the removal of unneeded plugins and combine/minify of the assets enabled a 30% reduction in size.
The CSS on the custom site was 65% smaller than the base site, even though it contained all the styles for the admin system which the other two sites have in a separate stylesheet. Including Javascript the reduction was 85%. Developing the styles and Javascript of the website specifically for this site meant that there wasn’t much bloat, leading to a drastically smaller size, and less work for the browser to do to consume it.
The asset size of the optimised version went up due to the external fonts being counted as Javascript in the base site, but overall the size was reduced. Whilst the same assets were used in the base and optimised sites, I ran the PNG’s through a PNG optimiser, and minified the SVG’s.
On the custom site the assets were 48% smaller than the base site, this is because I remade some of the bitmap images as SVG’s, and I trimmed a load of whitespace out of the other PNG images.
Performance Metrics
| Wordpress | Optimised | Custom | |
|---|---|---|---|
| Lighthouse Performance | 59 | 66 | 100 |
| First Contentful Paint | 2.5s | 2.0s | 1.1s |
| Time to Interactive | 5.5s | 5.6s | 1.1s |
| Largest Contentful Paint | 5.9s | 4.6s | 1.7s |
| Total Blocking Time | 390ms | 320ms | 0ms |
| Cumulative Layout Shift | 0.084s | 0.084s | 0s |
Optimising the Wordpress site improved most metrics across the board, the performance score was 7 points higher, and page draw times reduced. The time to interactive was slightly higher, this may be to do with moving the fonts to local, meaning whilst it had one less domain to lookup and connect with, it couldn’t download as many assets in parallel.
Due to the size of the HTML/CSS/Javascript on both Wordpress sites, the performance score was always going to have a ceiling, the size of those assets not only increasing the download time, but more importantly making the browser have to work much harder to process them. The custom site with its leaner assets gained a perfect score of 100, a 69% increase.
The render metrics were also significantly better across the board, a result of the reduction in work the browser has to do to render the page.
Server-side Assets
Whilst this doesn’t matter so much to users, I thought it would be interesting to compare some metrics from the server-side.
| Wordpress | Optimised | Custom | |
|---|---|---|---|
| Website File Size | 746mb | 258mb | 9.45mb |
| Page Generation | 0.5062s | 0.7251s | 0.0318s |
| Peak Memory Usage | 21.7mb | 25.5mb | 1,014kb |
Here we can see the size of the website code and assets, there was a fair amount of leftover junk from some plugins that weren’t being used that caused the reduction of 488MB (65%) from the base site to the optimised. The custom version is way smaller at 9.45MB, a reduction in size of 736MB (98.7%).
When running the sites, the optimised version takes longer and uses more memory than the base version, I think this is down to the fact that I tried to add another language to the optimised version, and this seems to increase the generation time and memory usage.
The custom version absolutely annihilated both Wordpress versions using 95% less RAM, and generating the page 1,592% faster.
Database
The database is a critical component to the functioning of a dynamic website, and here both Wordpress sites and the custom site use MySQL (Specifically MariaDB).
| Wordpress | Optimised | Custom | |
|---|---|---|---|
| Database Size | 155mb | 181mb | 12.5mb |
| Database Tables | 71 | 45 | 25 |
| Database Rows | 139,589 | 70,825 | 700 |
| Queries | 151 - 221 | 175 - 243 | 6 |
| Query Time | 0.0453s | 0.0526s | 0.0058s |
I managed to cut down the number of tables used in the optimised site as many were used in plugins that were no longer active or needed. Interestingly whilst the number of records in the optimised site was half that of the base site, the size actually went up, as did the number of queries to generate the homepage. Again I attribute this to the extra language I added to the optimised site.
The custom site’s database is 92% smaller, with 99.5% less rows. In terms of queries, the homepage generates around 96% - 97% less queries. I have expressed the number of queries for the Wordpress site as a range as it changes on every page load, something to do with caches or plugins writing back to the database.
In terms of query time the optimised site was 16% slower due to the larger number of queries, whereas the custom site completed its queries 87% faster.
Conclusion
First to reiterate, I have dealt with a fair few Wordpress sites in my career, and this one was one of the better ones. It’s problems were not down to what the website developers did, it was a product of Wordpress, the language plugin, and the demands of the site. For example, the language plugin generated 136 database queries (55%), whilst the theme’s block builder generated 76 queries (31%).
The point of this article is to show how much more a website can be optimised by building to exact specifications, and also to show how problematic Wordpress can be when you want to get everything working really well.
Clearly the custom built website was better on all metrics, the homepage was 89% smaller than the original website, the server-side assets were 98% smaller, generating the page 1,592% faster, with 95% less RAM. It’s performance metrics were also significantly better. The result is that for users the site feels more responsive and requires less of their resources.
On the server-side, the custom built site had a footprint that was 95.5% smaller than the optimised site (including database), and should be able to handle ~16x the number of page requests on the same hardware, and with RAM to spare (based on the numbers here and without stress testing the sites).
The database size/load/queries were all over 90% less than the Wordpress sites, as database resources can be the bottleneck to a growing website, this allows a lot more room to scale in the future.
Wordpress is so popular because it is easy to get going, there are a lot of plugins, it is cheap, and there are a lot of developers out there who develop for it. The penalty for this is without the support of good plugins or suitable plugins, you don’t always get exactly what you want, and the base code and plugin architecture are very generalised, meaning it won’t be very well optimised for your specific website.
My experience is that plugins tend to add bloat quite readily to your pages, don’t offload CSS/Javascript to external files, or they try to do too much, and aren’t optimised at all well for delivery of the page.
I should also mention hidden costs, apart from your hosting bill, which if this example is anything to go by, will likely be much higher, but unoptimised back-end processes cost you money every time they are used if they are inefficient, taking longer to complete than they would if the process has been designed specifically for your needs, often annoying staff who find the laborious processes frustrating.
On the flip-side, with custom development you get exactly what you want, but it takes longer, will cost more and any architectural changes you want to make will likely need a developer. It also relies on having a good developer who knows what they are doing, and has a bank of trusted software, such as a CMS that they can tailor to your needs, and finding good developers these days can be challenging.
But when you have the right people, you will get a lean mean website that will trounce most off the shelf platforms on just about every metric, enabling you to do things that may not be possible to do or do well with something like Wordpress. It will oil your entire business with efficient and automated processes that are a pleasure to use, ultimately pushing it forward rather than holding it back.
Top comments (1)
Nice post and good job on the performance improvement!