How it Started

It started as most great discoveries start, with an anomaly. Something we were working on loaded faster than we thought it should, and when we looked at it closer, we realised we had made a mistake, and not only should it not have been loading so fast, it should not have loaded at all. We had made a typo and it should have been broken. Which made us realise that there was something here to be discovered. So, we decided to take a day out of our usual client work to drill down on that anomaly.

We knew that we would learn something that would improve loading times. But we expected a minor improvement, maybe a 0.2s reduction, for a medium inconvenience. Something we might tag for future exploration but not that ground-breaking. What we found was our first breakthrough, and it gave us a major 0.8s speed improvement for the same medium inconvenience.

Now, we already thought that we were at, or nearly at, the realistic loading speed of WordPress. Our new builds were averaging around 1.8s, and we thought that any subsequent improvement would only come with overclocked servers with new expensive hardware, or would require major sacrifices in usability.

The medium inconvenience was that we were going to have to extensively rework the framework that we used and rebuild how we do headers, menus and footers, something that might take a couple of weeks.

Which gave us a moral conundrum, now we knew that we could shave 0.8s off the load time we couldn’t in good consciousness sell a client a website built on the old framework. So, we suspended operations so we could focus on the update.

But since we were going to be rebuilding our existing framework anyway, we decided to take the time to research what else we could do to improve loading time. We had some crazy ideas and now was the time to test them. A lot had happened in 2024. We had upgraded all our servers to php8.3 and there had been 3 major WordPress performance updates, and AI, which is simultaneously a technical genius and extraordinarily incompetent, had resulted in wide changes.

So, in January 2025 we undertook a research project into load time optimisation which yielded breakthrough after breakthrough and which grew and grew. In total we made 13 significant breakthroughs and it took 7 weeks to complete the process and turn what we had learned into a new WordPress framework which was faster than anything we had ever seen before.

We made a common page layout, with the usual header and footer, with a large image and a medium image and a significant chunk of text, with custom non-web safe fonts and all the js libraries needed for carousels and modals and jQuery load in 0.262s.

We reduced our dependencies down so low that that discounting the images in the body, the entire frontend of WordPress was just 3 files. 1 html file, 1 js file and 1 css file, totalling a mere 230KB and we reduced our server response time down to as low as 28milliseconds.

Reference point: there are 1000 milliseconds in a second.

This is insane. In fact the hardest part of writing this article is going to be explaining how ahead of the curve this is. We struggled to find comparative data on any platform performing below 1s, let alone at a quarter of a second, and as you get closer to 0 each subsequent gain is exponentially harder.

Why Does this Matter?

Loading speed is one of the few things which is a universal good. It improves user experience, increases engagement, improves sales conversion and builds trust. But it is also one of the only Search Engine Optimisation (SEO) factors where Google has broken its code of silence and come out and said that it is a major factor in deciding Google rankings.

Source: https://developers.google.com/search/blog/2010/04/using-site-speed-in-web-search-ranking.

Key Concepts

Note: This is a bit of a long section, that not everyone needs to read, feel free to skip past it to the data and visuals.

For readers who don’t already know I need to explain a few key concepts and some of the jargon, otherwise this is going to be confusing.

There are 6 loading time measurements:

• TTFIB (Time to First Byte): How long the server takes before its response starts. You might think of this as thinking time. This is really a measure of the quality of the server and of the cache.
• Onload time: How long it take to download all the files needed to build the site.
• First Contentful Paint (FCP): When the website starts to create the visuals the user sees.
• Largest Contentful Paint (LCP): When the website has finished loading the visuals on the initial fold of the screen and the website looks complete. LCP is what most developers refer to when they measure page loading time and is what most analysis measures.
• Time to interactive: How long it takes before everything actually works.
• Fully Loaded: When everything has finished loading.

The most important metric is Largest Contentful Paint (LCP) and this is what most research uses to define loading speed.

You also need to be aware of a few other key concepts:

• Page Requests: A website is made up of many files and this number is the number of ‘page requests’. The average page is made of around 100 files. Usually including stylesheets, font libraries, images, scripts libraries, and 3^rd party dependencies (such as spam filters). Every additional bit of software installed on a site will load a handful of files, so page request volume escalates rapidly. Each file needs to be individually requested from a server, not always the same server, the server needs to think about the request, and then send the required file, and then the users’ device needs to check the integrity of the file and then run that file and make computations based on it. Sometimes the website needs one file to load before it can load the next. There is a delay in your device working out what it needs to request, a delay in those servers working out how to reply to the request, but once in transit download speeds increase rapidly, so the number of files is actually a bigger factor than the size of those files.
• Total Page Size: This is pretty simple. This is just the total size of the data on the page. Whilst it is an important factor, we don’t want to transmit unneeded data, its actually a smaller factor than you might expect.
• Conversion rate: What percentage of people visiting the site did the thing you wanted them to do. Such as fill in the contact form, make an appointment or buy a product.

WordPress is Old

The next thing we need to explain is that WordPress is old and inefficient. It was first released in 2003. It is based on PHP, a coding language which is even older and was first released in 1995. Rust, Golang, Node.js, Elixir and C++ are all newer and faster coding languages that can be used to build faster websites, and which all were developed to address PHP’s shortcomings.

Likewise, WordPress’s general architecture and database structure are inefficient. Newer Content Management Systems (CMS) were all developed to address WordPress’s shortcomings. CraftCMS, OctoberCMS, Statamic, Hugo, Jekyll, Ghost CMS, Grav CMS, Directus, Strapi and KeystoneJS are all technically superior and faster than WordPress.

WordPress is to websites what British Rail is to international train networks. We invented them, we built the first rail networks, we got all the first mover advantages, it powered our industrial revolution but everyone else learned from our mistakes and built better systems than us, and now 300 years later we have decrepit old rail stock whilst Japan has the bullet train.

We actually tried to replace WordPress with OctoberCMS in 2016 for this exact reason. We built maybe 15 websites in OctoberCMS and they were technically superior to WordPress and we even had one OctoberCMS site reach a load time of 0.9s. We thought that this was amazing and that all we needed to do was educate our clients on how much technically better OctoberCMS was and then they would want it over WordPress. But that’s not how things played out.

The first barrier we encountered was that marketing teams wanted something they and their staff, and anyone they might hire in the future already knew. And using a niche system meant extra training for staff, which was often then neglected, which resulted in site updates being neglected. Which resulted in marketing being neglected.

The next barrier was that 3^rd parties didn’t know how to work in it. Clients would hire SEO consultants or PPC experts to work on the site, and they didn’t know how to do that, so they didn’t know how to price the work, which lead to a lot of negative internal interactions.

Then there were the unexpectedly high ongoing maintenance costs. Every site develops problems that need fixing. In OctoberCMS individual problems tended to take more time and skill to solve. If you have a problem in a platform used by millions of people, then many others will have had the same problem, and discussed it in forums and will have had multiple solutions and then critiqued the various solutions, and whilst the popular solution is not always the best, there is an easy narrative to follow, and that does most of the work. Whereas when we had an issue in OctoberCMS there were no forums on it, we had to research the issue in the code ourselves and do many experiments to uncover the variables and small fixes became big tasks, and that would have a knock on effect on workflow, and create conflicts in task priorities.

In 2016 we thought that the WordPress demand would split, with SMEs that could afford it choosing the faster and better modern CMSs preferred by professional developers and WordPress being used by startups and hobbyists. But that’s not what happened. In 2016 WordPress had a 25.6% market, but in 2024 it had grown to a 43.6% share and it’s still growing.

Source: https://kinsta.com/wordpress-market-share/

Knowing what I know about the WordPress architecture and database structure, and the limitations of PHP and having experience building sites in better CMSs, I did not think that an unmodified WordPress install could ever come close to 1s, let alone load in a split second.

This is what makes a WordPress load time of 0.262s so unbelievable. Its poor performance has been the primary driving factor behind the development of all these newer CMSs.

And to be frank I don’t see a place for these other more modern CMS’s in the market anymore. If WordPress can now load as fast as they can, they don’t really have a unique selling point that can be understood by anyone other than a developer.

Getting Some Context. Other People’s Statistics Relating to the Effects of Page Loading Speed and the Current Status Quo.

1. Google: Page load speed increases bounce rate by 123%

Source: https://developers.google.com/speed/docs/insights/v5/about

2. This data is based on mobile loading times. Since our data is based on desktop load times analysis from gtmetrix.com this is not an apples to apples comparison. So to help compare these data sets you need to know that ToolTester from Hubspot found that pages load 70.9% slower on mobile than desktop

Source: https://blog.hubspot.com/marketing/page-load-time-conversion-rates

3. In a comparison done by Portent they found that a B2B site with a load time of 1s had a conversion rate 5x higher than one with a 10s loading time.

Source: https://blog.hubspot.com/marketing/page-load-time-conversion-rates

4. Vodaphone improved their loading time by 31% and saw a sales increase of 8%.

Source: https://web.dev/case-studies/vodafone

5. Google defines a good loading speed as being an LCP of under 2.5s.

Source: https://developers.google.com/speed/docs/insights/v5/about

6. Here is Googles analysis of average page requests by industry. Reminder: page requests is the number of files needed to load a webpage.

Source: https://www.thinkwithgoogle.com/marketing-strategies/app-and-mobile/mobile-page-speed-new-industry-benchmarks/

7. Tooltester did a useful comparison of the performance of different website building tools based on Desktop Time To Interactive (TTI). This is slightly different to the usual LCP measurement and for reference the TTI for minimal is 0.293s.

Source: https://www.tooltester.com/en/blog/website-loading-time-statistics/

And here is the same statistics for mobile loading times:

Source: https://www.tooltester.com/en/blog/website-loading-time-statistics/

So you will have gotten the gist now. Page speed improvements lead to real business improvements.

The key takeaways are:

• A faster website will make you rank better in Google.
• A faster website will increase your website traffic.
• A faster website will improve your conversion rates.
• The average WordPress loading speed is 2.57s.
• The global average is 2.18s.
• The best in class loading time is 1.1s.
• The average website has approximately 100 Page Requests.

Lets Dive into Minimal’s Loading Data

To realistically anticipate what you can expect from Minimal we need to measure it under different scenarios. Most sites will need some extra functionality that will have an impact on loading.

Disclaimer:

• • Fluctuation can be expected and are normal. This data is a snapshot in time.

  • When measuring anything you need to keep in mind that every tool has its own margin of error and as measurements become smaller that error margin becomes comparatively bigger. For this we will be using gtmetrix.com and we do not know what its error margin is, but we can expect that the smaller the time unit we are discussing the larger the error margin. A unit of 10ms will fluctuate more than a unit of 100ms.

  • We are measuring this using gtmetrix.com’s London server. Our servers are also in London, so there is a geographical advantage.

The Core

So, let’s start off with the elements that every single page require. The core is the header and footer of the site and the code libraries needed to run the site. Assets here would include the stylesheets, the logo, the favicon, the fonts, bootstrap, the js needed for a carousel, the menus and any icons. This is our starting point before we start adding any page content.

Note the Total Page Requests. We have reduced all the dependencies down to only 3 files. The HTML file for the page itself, a single minified CSS file, and a single minified JS file. All of our dependencies, bootstrap, our carousel software, lightbox software, jQuery, our custom js, our custom fonts, our icons, favicons and logos are all contained within these 3 files. And all this software comes to a mere 255KB.

And this is the waterfall. A waterfall is the graphic that shows you the order files are loaded and it explains the loading process. What you see here is that ’empty-page’ which is the html of the page is loaded first and then that tells the device that it needs the css and js files and then those files are loaded simultaneously. Note: downloading the files is completed in the first 40% of the total load time. This runs so fast that computational time of the device is a larger time factor than downloading the core.

A Common Page

Now lets start adding some content so we can see some real world examples. Here is a simple internal page layout. There are two medium size image and some text. Note: minimal utilises lazy loading on image assets, so images below the first fold will not be loaded in the initial page load.

So here we have actually gotten a faster loading time than the previous example. I think this just shows that when a site is loading this fast small variations and the margin of error of the measuring tool are an outsized variable.

And if we look at the waterfall you can see that once the html file is downloaded the other files are loaded simultaneously and that small images have a negligible effect on loading time.

A Homepage

What about bigger imagery? For this demo we have added one large fullscreen image, three medium images and some body copy, similar to what you would get on a standard homepage. But like the above example this is all static content and wont require much computation.

The larger image has had a small impact on the loading time but we are still getting a really impressive load time.

And if we examine the waterfall you can see that in addition to the 4 images there is a blank.gif file that our cache adds as a placeholder whilst its lazy loading images.

A js heavy page

Now lets add some elements that require frontend computation. We have replaced the hero image with a carousel of images, and replaced the medium images with a carousel ribbon.

So here you will see that we are starting to get ‘Blocking Time’. This is time that the device needs to do computations to work out how to handle the layout. This is because both carousels require js libraries to function. Basically using js to handle layouts is a little like cheating. The elements themselves don’t have inherent layout rules so the device can’t immediately calculate how they should look, it needs to load some software that tells it how to act, and that software needs to make calculations based on other bits of the site that may not have loaded yet, so if it loads immediately then it might gets some of its inputs wrong and come to the wrong output, so it waits until everything is loaded and then makes the js computations last. For this reason we normally try and avoid having js elements above the fold and try to use them sparingly.

Also note that we are starting to get a ‘Cumulative Layout Shift’. This is when the layout jumps during the load process, and if you look closely you can see that in frame 2 of the loading screen the second image of the carousel is momentarily visible before the js carousel triggers.

Note: Cumulative Layout Shift gives a negative user experience and it is measured by Google so we can assume that this is a factor in their calculations.

And looking at the waterfall you can see that the extra time is computational time on the device.

Contact Form 7

Contact form 7 has been our go to contact form software in the past, and we have integrated it with a lot of 3^rd party platforms and built some clients some complex contact forms using it. Unfortunately its loading process is not as optimal as we would like and it has a number of 3^rd party dependencies that we are unable to speed up, so in the future we will likely be building our forms in something else.

You will see that whilst the Largest Contentful Paint is a mere 339ms the Fully Loaded Time has jumped to 1.6s.

And if you look a the waterfall you will see why. Our assets from our server are in the green box. They are loaded the same as above. But then Contact Form 7 goes to Google’s servers and gets files from there and they load slowly and there is not a lot we can do about it. We could block the requests and internalise the files but then we would have a version control issue when the plugin updates. Back when our sites were slower this loading time was hidden. 1.5s is still an excellent loading time far ahead of the 2.6s average but clearly its not a practice that we can continue. And this is a great example of how adding a single plugin to a website can totally ruin its performance.

Gravity Forms

Gravity Forms is our new preferred contact form software. It’s principal benefit over Contact Form 7 is that it’s dependencies are internal and loaded in such a way that we can compile them into our dependencies file, keeping our page requests low whilst Gravity Forms can still update them.

So you can see that there is a 100ms delay over loading the core but its still an excellent loading time.

And in the waterfall you can see that we have an extra js file. This handles the form and the spam filter and is a file handled by Gravity Forms so they can update it.

Note: from this visual it might be confusing that the .js files have the same name and at first glance look the same, but a quirk of our cache software is that it gives cache version files the same file name but different parent folders. This makes more sense when you realise that there will be many versions of a file in that folder and that the name allows you to easily cross reference versions of other files in other folders that are from the same version on the cache.

WooCommerce

WooCommerce is our go to ecommerce system. It is a complex system and comes with a lot of dependencies.

We are taking a pretty hefty hit to our load time. It is also loading a js carousel for the images. But if you reference the CMS loading time comparison table above you’ll see that WooCommerce has the worst performance score and loads in 3.06s, and yet here we have is loading 4.8x faster in 640ms and still soundly beating first place GoDaddy score of 1.1s.

And if you look at the waterfall you’ll see that we now have a lot more files being loaded and these aren’t as efficiently structured. For example WooCommerce loads 4 seperate css files.

Fullscreen Autoplay Vimeo Hero

We do a lot of websites with fullscreen videos. We always load these videos via our Vimeo account. Our servers can’t deliver video content as fast or as intelligently as Vimeo and for a small fee we can shift that server load to them. Whilst video is ‘streamed’, which basically means that the usual integrity checks are skipped and so the loading process requires vastly less computation, videos are massive files.

The site and its fallback image loads in a fairly fast 667ms but the video itself doesn’t start to play until 2.9s. And you can see that the page size is now 11.3MB, which is huge.

And if we look at the waterfall you can see how many assets Vimeo needs to load the video. Vimeo loads 27 files and is working hard for the whole 3s.

Which basically is to say that if you want a video loading page you are going to take a big performance hit.

Google Maps API

The Google Maps API is just slow and there is not a lot that we can do about this. It is external to our website and there is nothing we can do to speed it up. We just have to accept that any application using Google Maps will be slower.

This is especially bad as the Google Map is above the fold so the Largest Contentful Paint isn’t completed until its fully loaded.

And if we examine the waterfall we will see that it adds so many files that we can’t fit them on one screen. And if you look at the three lines at the bottom you will see that the blue line, which is data transferred is actually low throughout the process and that the red line, the CPU is high throughout it, which says that the delay is primarily computational on the device, which is not something we can do a lot about.

So the takeaway here is that if you want an interactive Google map then you will take a performance hit.

Conclusion

This has been an insane journey of discovery for us. 13 times we discovered how changes in technique significantly improved loading times. Three months ago we would have considered getting WordPress to load in under 1s as only possible with expensive overclocked servers, or by cutting it up into a headless build, which is basically using something other than WordPress for the front end. The idea that we can now load a page in 0.27 seconds is insane. Going forward we will be using our new framework and our new methodology on all projects. This will also increase the time it takes us to build websites. We have made these performance enhancements by removing all the usual convenient shortcuts that sacrifice performance to save development time, and there are now additional processes, such as converting all visuals to svgs, then reformatting them into an inline style, so the Adobe InDesign rules on one svg don’t impact other svgs, and loading them in css or html, and the conversion of fonts from their usual .oft format to inline base64.

But this an exciting time. Now that we are able to break through to a loading time previously reserved for websites with budgets above £100k, our clients will see significant increases in sales and user satisfaction, and it will reflect well on our clients. And from a design perspective it opens up new possibilities in terms of animation. We avoided load in and load out animations before becasue they make sites look slower. But now that our core has a world class loading time, we have time to play with and can create more impressible visuals that will help our clients in experiential business sectors.

This is exciting. We are eager for each new build.