Case Study: How I Reduced My Website Size by 90% and Cut My Page Loading Time in Half
In this post you are going to learn how I reduced my page size by a staggering 90% and cut my page loading time in half.
I wrote it as a follow up to Make Your Website Better with These 7 Improvements.
After writing tips on how to optimize websites, I decided to take a closer look at my own new site.
This site.
I had already applied some basic optimizations, but when it came to website speed and load size, my site still sucked.
This is the full case study of how I reduced my load time from 3.06 seconds to 1.41 seconds, and page size from 12.9 MB to just 1.2MB.
Starting with a baseline
I decided to test one of my blog posts with a fair amount of text and images: How To Get 118,098 Visitors By Clicking a Big Red Button. The post has 2878 wordsand 7 images.
My starting point for this case study was the following:
PageSpeed Insights by Google gave my website Low (44/100) on optimization and couldn’t tell my website speed.
Test Your Mobile Website by Google scored my 3G loading time as Fair (6 seconds) with estimated visitors loss of 24% due to loading speed.
WebPagetest scored my site as follows:
Pingdom Website Speed Test scored the following from NYC:
As a fun side-note, WebPagetest can also direct you to a site showing how much it costs to access your site using a mobile network.
Here are my results:
Yikes. My site is expensive!
I know these are just back-of-the-envelope calculations, but it’s interesting to see things from a different perspective.
A website score doesn’t tell you much about what your site is like to use in practice.
But when you see your site is so heavy it will cost more than a dollar to simply load it on a mobile device, you start to think.
If you want to know how expensive your site it, visit What Does My Site Cost? yourself and take the test.
Now let’s fix our issues.
Step 0: Optimizations already performed
Before I dive deeper into this case study, I should explain some of the things I have already done.
I have installed a caching plugin for WordPress to speed up my site. A caching plugin will help WordPress run faster by serving static HTML pages instead of always having to take a round trip to the database.
The caching plugin that I was using at the start of this experiment was WP Super Cache. But I’ll get to what I ended up using later.
I’m also using CloudFlare with some of their standard optimization settings.
You can read more about these initial tweaks here.
Step 1: Leverage browser caching
One of the things all speed tests complained about was the lack of — or short expiration time on — browser caching.
Browser caching means that you tell the browser (e.g., Google Chrome, Firefox or Internet Explorer) that it can save some of the website files and reuse them again.
This is a smart concept that can speed up website browsing for repeat visitors.
To fix this I set my Browser Cache Expiration to 8 days using Cloudflare’s cache settings.
Setting your cache expiration is a tradeoff between load speed and update speed.
Setting the expiration time higher means that it may take longer time for new updates to propagate to all users as they will be served old — cached — versions of your files.
Note that this kind of caching does not extend to HTML files, so if you change something on your page — like writing a new post or editing an existing one — it will show to your users.
The caching applies to more static files like your styles sheet (CSS), images (png, jpeg) and javascript (js). Files that you don’t change often.
You can see which file extensions CloudFlare caches here.
What does this mean for you?
If you are running a normal website using WordPress or another content management system, you are most likely going to do just fine with a cache expiration date of a week or longer.
I bet you aren’t changing your stylesheet or javascript files that often anyway.
However, a higher expiration time comes at a cost. Updates to the cached files will take longer to propagate to all users.
If you are really good at planning major updates, you can reduce the cache time before the update to let users get updated versions earlier.
Step 2: Optimizing images for website use
Images were the biggest issue affecting my load speed and website size.
And that’s because they hadn’t been optimized for website use.
I had downloaded most of the images from photographer communities like Unsplash and Pexels where the images are uploaded in the highest quality with no optimizations.
I didn’t realize this was such a big issue until I started looking at my page size and speed.
And upon further investigation, I found out that modern optimization strategies can reduce the size of images by a lot, while still maintaining great quality.
You simply pop your image into their optimization machine and out comes a perfectly great image, just smaller and better suited for websites.
It almost feels like a bit of a magic trick.
If you want all the technical details about image optimization, you can start here and here. Fair warning, these are very technical articles.
I’ll skip the tech stuff and simply show you how you can optimize your own website images.
You get three options. Use whatever suits you.
1) Manual optimization (Easy but tedious)
The simplest optimization you can do is take your images through some optimization method before you use them on your website.
This works no matter what type of website you are using.
If you are on Mac, ImageOptim is a tool that can do this for you. There are also Windows and Linux alternatives.
You can also skip the downloading of tools and simply use their online interface for png and jpeg images.
Input your image, click a button and you are done.
2) WordPress image plugins (Intermediate)
Manual image optimization will quickly get tedious and you’ll likely forget all about it in a couple of days from now.
If you are on WordPress, a better solution is to get a plugin to help you optimize your images as you upload them.
WP Smush is the most popular image optimization plugin at the moment. And it’s easy to see why. The plugin is simple to use and very effective.
3) Third party optimizations (Advanced)
A third party optimization is the most advanced technique you can use.
But it also gives you more room to maneuver and the optimization potential is higher.
Serving your images via a third party will reduce the load on your own servers and by using a content delivery network (CDN) for your images, they will also be delivered faster than your own server would be able to do.
So not only do you get better optimization, you also get faster delivery and reduced load on your server.
The downside is that using a third party may cost money and that using it can be a bit more complicated.
But not that much.
Cloudinary — the option I went with — offers a free tier for smaller websites and they even have a WordPress plugin to help you upload images directly from your website.
Several other CDN and image optimization platforms are listed here.
So how do you use an advanced image optimization platform with tons of tweaks, settings, and options to choose from?
I have no clue.
If you are looking for expert advice, you’ll have to go somewhere else.
But I do have a solution that will work more than fine for most websites:
Set everything to auto and let the experts do their job.
Cloudinary has auto options for image format and quality.
I simply use these two.
And then I resize the image to have the correct width for my use. After a bit of testing, I found that the max width of my current website theme is 740 px. So I simply resize images for that.
There’s no need to have a larger image as it will be resized to fit the maximum width anyway.
A larger size would only mean wasted bandwidth.
Step 3: Taking a closer look at WordPress caching
If you are using WordPress, you should have a caching plugin.
It is the easiest way to massively improve the performance of your site.
A note about this section: While working on improving my own WordPress caching I tried two different caching plugins WP Super Cache and Cache Enabler. I also researched several other plugins.
Here are my findings:
For a novice user, the difference in performance between these two is impossible to tell. If you want the easy and simple way out: use Cache Enabler and skip the rest of this section about WordPress caching.
To get started you pretty much just have to install and activate the plugin.
WP Super Cache has a lot more settings to tweak, but if you don’t know what you are doing, these settings won’t help you much.
An even if you have some clue as to what you are doing, the difference in performance is still next to impossible to spot clearly.
You have been warned.
Only read the rest of this section if you are interested in learning more about WordPress caching. If you just want a faster site, install Cache Enabler or any of the other popular caching plugins and use recommended settings.
How WordPress caching works
When WordPress serves a website page to a visitor, it has to go to your database and load your content from there.
You can think of the database as storing the content that a page displays. Things like posts, pages, settings, tags, categories, comments, users, etc., are all stored in your database.
Furthermore, WordPress will also have to do some computations and processing to load a page.
All of this — the database fetching and the processing — takes time and resources from your server.
The idea behind caching is that instead of doing this over and over — just to show exactly the same pages — WordPress will just store the page that was generated after the database loading and the processing.
So now WordPress can simply serve this static page to the next user, without doing any database calls or processing.
The result is a much faster website load time.
So, what is the downside to all of this? Why aren’t we just doing this with all pages, all the time?
I’m glad you asked.
Caching strategies
One of the downsides of caching is that a cached page is static.
The whole point is of course that the page is static so our server doesn’t have to dynamically compute anything. But this also means that if some change is made to the original page, WordPress will have to create a new static page and store it again.
So for pages that are changing fast, this can become an issue.
Another downside is that cached pages may take up space. WordPress has to store these static pages somewhere.
The default solution to these two problems is that WordPress will only cache a page when a user visits it.
The idea is that your most popular pages should be cached, while less popular ones may not need to as they will just take up empty space.
Popular pages will be cached and they will therefore load quickly while also sparing the server from generating the pages over and over.
The second part of the solution is that cached pages are thrown away after a period of inactivity, i.e., when they are not popular anymore.
Now here’s what all of this boils down to:
The default caching strategy is built for larger, traffic intense websites.
So if you have a small website with infrequent visitors, you won’t get much benefit from default caching as the pages will become invalidated before visitors arrive.
And with small sites I’m talking less than something in the order of 10,000 pages.
If all of the above made little to no sense, don’t worry. Here’s the important part: Your caching strategy should depend on your website size and traffic.
Unfortunately, there are no clear-cut best settings. If you want to maximize your results, you’ll have to experiment and tweak your numbers.
But if you just want something that works, follow the guidelines below and you are off to a good start.
I have two strategies for you:
1) Standard caching for sites with either a lot of pages or already well-established traffic.
2) A preloading cache strategy for smaller websites with little traffic.
Strategy 1: A standard caching strategy
The standard caching strategy works as follows: when a user visits a page, this page will be cached. The cached page will be kept for a limited time while it is freshand thrown away once it becomes stale.
How well the standard caching strategy works depends on how long you keep cached files fresh (Cache Timeout) and how often you clear these files (Garbage Collection).
What timeout to use depends on how much traffic you are getting and how critical pages updates are. If you have low traffic and no time-sensitive page updates, you can use a quite long timeout.
If you have time-sensitive information or very frequent updates, you may need to use a shorter cache timeout.
Garbage collection determines how often stale cache files are thrown away. Again, the more time-sensitive and frequent updates you have, the lower the time should be.
Strategy 2: A preloading cache strategy
The main issue with a small site is that you are not going to have enough visitors to benefit from a standard caching strategy.
You may have some visitor fetch one or more pages and then leave.
These pages are now in the cache.
But if no other visitors are going to use these pages in the short future, the cached pages will become stale and your caching plugin will throw them away.
One solution is to increase your cache timeout. This is actually a good solution if you have some consistent traffic.
But for smaller pages, you can do even better.
You can use a preload strategy.
The idea is here that the caching plugin will preload all your pages in the cache. So instead of being reactive, you become proactive.
You prepare for your visitors.
The reason this works for smaller pages is that your cache won’t be so big that generating it will become an issue.
For bigger pages, a reactive strategy may be the only option as a proactive one will take up too much space and too many resources to build.
WP Super Cache allows you to use the preloading strategy in the Preload tab:
Step 4: Optimizing HTML, CSS, and Javascript
Improving the website code that will be delivered to your visitors is a big topic of optimization too.
The code is HTML, CSS, and Javascript and there are many things that you can do to deliver it optimally.
I did some of the most basic steps as I’ll explain here.
Minify code
When a browser views code like HTML or CSS, it doesn’t care about unnecessary characters like whitespace or comments.
So sending code that is filled with these is a waste of bandwidth.
Instead, you can minify the code to make it as small as possible without changing the functionality.
I used the Auto Minify option from Cloudflare to do this:
There are also plugins that can minify code if you are not using CloudFlare. Like the one I’m just about to talk about:
Autoptimize
In my page speed reports I still had several issues with Javascript and CSS loading and caching.
I found a plugin that could solve a lot of these issues by optimizing how HTML, CSS, and Javascript is stored and served to my visitors.
This plugin will optimize your code and even cache it for faster delivery.
It didn’t fix all my issues, but it removed a great deal of them.
Rocket Loader™
After optimizing my code locally using the Autoptimize WordPress plugin, I also activated Cloudflare’s Rocket Loader™.
Activating this was a bit of a magic trick again.
The Rocket Loader™ promises to improve page speed by optimizing Javascript code. And I could actually see the difference in page load times when I ran a couple of tests immediately afterward.
The only downside to this thing is that it is rather intrusive and still in Beta stage.
Javascript is a beast to get right so the loader may cause some issues for you.
I have not experienced any issues, but my site is also fairly low-key on custom Javascript.
Step 5: Upgrading PHP to a newer version
While scouring the internet for website optimizations I came across a post about upgrading your PHP version by Yoast.
The post explains how WordPress is very conservative with PHP versions and how that may be a bad thing.
It also describes how newer versions of PHP are much faster than the old ones. Like… 400% faster.
As I have been with the same hosting provider for years, I decided to take a look at my PHP settings.
I discovered that this site was running PHP 5.4, an older version than the current stable 5.6 and the newest 7.0+.
I upgraded my version to 7.0 and immediately saw an improvement in my First Byte Time metric — a stat that gives you some indication of how well your server is running.
You can read more about PHP versions in the post by Yoast.
Case study results
Here are the results of tinkering with my website for several days:
WebPagetest:
and Pingdom:
I’m quite pleased with the optimizations for now, although there are always more things you can do better.
The page tests still have a couple of complaints about caching, but these are external scripts from Facebook, Google Analytics, and Google Fonts. The scripts do use browser caching. Their expiration time is just too low for the speed tests to be happy.
Over the course of this optimization adventure I have learned a few takeaways:
1) Optimizing images is key to a lighter site.
Optimizing my images was clearly the biggest factor to my improvement in page size and speed.
My page size went from 12.9 MB to 1.2 MB according to Pingdom. Most of it thanks to smaller images.
And I can’t even tell the difference in quality.
2) Use a CDN (e.g., Cloudflare)
A content delivery network (CDN) can deliver many of your static website files (images, CSS, javascript, pdf) much faster than your own server.
These networks are built for speed.
I can recommend Cloudflare, which is much more than just a CDN.
It’s a platform that can improve your website performance, security, reliability and much more.
I haven’t tried other solutions like Cloudflare so I may be extremely biased. All I can say is that I haven’t had a reason to look for other options so far.
For my images, I use the Cloudinary CDN as Cloudflare requires an upgraded plan for their image optimization. (I’m still on free tiers for both Cloudflare and Cloudinary.)
3) Know when enough is enough
I like technical challenges.
So it’s no surprise that I went almost all in on trying to improve my website speed.
However, this meant turning on and off plugins for a couple of days, running tests on tests from several speed testers, and even fiddling inside the core WordPress config files at one point.
And most of that work barely made a difference in the final result.
Optimizing your website has diminishing returns.
When I optimized my images, used a CDN and started caching properly with WordPress, my speed drastically improved.
The rest of my minor tweaks and fiddles may have given me a slight increase, but they also meant spending much more time looking at Webpagetest results.
More website improvements
– Discover the 7 website improvements that started all of this.
– Too many website ideas? Here’s why having no plan is actually good for your website.
