WordPress Site Speed, Perfected—Ask Me Anything

[Nick M.]

Let's Make Your Site Perform At It's Peak​

Ok, so many of you probably bring in business through your website. So obviously, you want to make your site as effective and efficient as possible.

After all, a better website means a better business.

One of the easiest and most effective ways to make sure your website performs at its best is to make it fast.

How fast? Or should we ask, how fast is fast enough? 5 seconds? 3 seconds? 1 second? Well, the answer is that unless your website feels instantaneous, it's not fast enough for your users.

You can test your site with Google:

How speeding up your mobile site can improve your bottom line

Google's Official Digital Marketing Publication. Discover helpful mobile tools and resources to optimize your site or app, check page speed, and more.

www.thinkwithgoogle.com

Even if your site is already "fast" (3 seconds), just a 1 second increase can mean a $73,960 annual increase in revenue!*

*10,000 monthly page views, 3% conversion rate, $300 average order value

Basically, you want your site to be as fast as possible! Anything slower is hurting your business.

Much of what you know about site speed is probably wrong​

I've spent hundreds of hours testing and dissecting how to make websites actually fast, not just scoring high on popular tools.

So in this thread, we're going to look at how to speed up your business's website. Though all the ideas and concepts are going to work with most sites, we're going to go into detail with WordPress sites. Partly because that's my specialty, and partly because that's what most sites use.

This thread is NOT for you if:

• You own an offline business
• You have no control over your site's mechanics
• You don't care about growing your business
• You aren't willing to take the time to learn
• You believe your site is fast enough (and ignoring all the research)
• You haven't started a business yet (take action!)
• You've spent hundreds of hours rigorously testing for site speed

However, this thread is for you if:

• Your site is built on WordPress
• You're a business owner who wants to grow their business
• You're a web designer that wants better sites for your clients
• Your site is slow, duh!
• You run a Google Ads campaign (don't waste paid clicks!)
• You've spent time/money on SEO
• You run an ecommerce site
• You run a digital marketing agency

Because you can either hire someone like me for only a couple hundred dollars to speed up your site, or you can learn to do it yourself. Especially if your business involves site development, learning to do it yourself can have some advantages.

Technical knowledge is not required.​

Sure, we will go over how to do things without plugins or technical knowledge, but there will always be ways to get your site as fast without all the technical knowledge that many developers will have.

Of course, if you are a developer, we'll also dive into how to do pretty much everything you'll need without plugins.

So, without further ado, let's get started!

Table of Contents:

• The Basics
  • Top 5 Myths About Site Speed
• Caching
  • The Best WordPress Page Caching Solution
• The "Secret" Sauce
  • 4 "Advanced" Speed Optimizations You Didn't Know You Needed
• Other
  • The Best WP Rocket Alternative

And of course, questions are always welcome.

Note to mods: yes, most of these posts are taken from the blog on my website, but they are reposted here with the intent to help everyone here on the forum, not necessarily as a marketing strategy.

 

Dislike ads? Remove them and support the forum: Subscribe to Fastlane Insiders.

[Nick M.]

If there’s only one thing you do…​

…for your website, add caching.

There are a lot of myths about how to speed up your WordPress site. Many of them involve making sure you have the fewest plugins necessary, a lightweight theme, deleting unused posts/images, cleaning your database, or even deleting past post revisions. And all of those “suggestions” are garbage if you have a great caching system setup. The easiest way to do that is through a plugin.

In short, caching makes your site a lot faster.

How much faster? We’ll see below.

But not all caching plugins are created equal. Some are easier to use than others. Some are faster than others. And some are more flexible than others.

So let’s find out which is the best solution for you (spoiler alert: I use Cache Enabler). But first, what exactly is caching?

Caching Explained​

In essence, every time a visitor visits your website, a lot of code runs. The more feature-rich your site, the more code that will run.

Code takes time to run.

But what if we already know the output will always be the same? Couldn’t we just save the output and not run the code?

That’s what caching does! That’s the key to making your site faster.

Now there are four kinds of caching:

• Server Cache
• Page Cache
• CDN Cache
• Browser Cache

All four types of caching are crucial for a really fast site. But we’re going to focus on page caching, as that has the largest impact of the four. It alone could speed up your site by 0.5 – 8.0 seconds! (It depends on your site, though)

So the first time a visitor views your website, your host will run all the scripts and plugins to create the page the visitor sees. And it saves the output. Then, for every visitor after that, it just sends the saved output.

That’s page caching!

Let’s Find the Best Page Caching Plugin​

So for this test, I found every caching plugin I could find and tested the speed for each of them to see which was the fastest. Here’s what we’re looking for:

• Speed
• Consistency
• Ease of use
• Flexibility
• Works with NGINX

Ok, you may not know what NGINX is, but it’s the fastest configuration for your host. A proper host will have NGINX configured, but not all do.

Of the 15 caching plugins I found, only 11 worked on NGINX out of the box:

• WP Rocket
• Cache Enabler
• W3 Total Cache
• WP Fastest Cache
• WP Super Cache
• Cachify
• Simple Cache
• WP Optimize
• Hummingbird
• Breeze
• Powered Cache

Not even some popular plugins like Comet Cache worked on my NGINX setup by default. To fix it, you’d have to dive into the server configuration. Not good if you don’t know what you’re doing, and not the easiest thing even if you do.

Others, like Litespeed Cache don’t work on NGINX at all, so they’re out of the picture.

The Setup​

Ok, so there are many ways to test the speed for each of these caching plugins, but I wanted to isolate all variables possible to leave nothing up to chance.

So I hosted the site locally on my computer to eliminate all network variances. I chose a decently large and complex site which allowed us to see a difference from caching. And before running the tests, I did no other optimizations to the site and made sure that the plugin was in its fastest possible configuration.

For the tests themselves, I looked specifically at the time to first byte (TTFB). Which, in this setup, is only affected by page caching. I did 10 tests, took the average to find the speed, and took the standard deviation to find the consistency of the speed.

Finally, so you can see how much the caching made a difference, I had a control that had no caching whatsoever.

The Results​

Lower is better for both graphs​

Looks like the 3 fastest caching plugins are, Simple Cache, Powered Cache, and Cache Enabler. So let’s look at each of these in more detail because all of these are really close in terms of speed. So we have to take into account the consistency, ease of use, and flexibility to really determine which one is the best.

Simple Cache​

Obviously, Simple cache is the fastest plugin I tested, but not by much. It’s only 3 milliseconds faster than Powered Cache and 4 milliseconds faster than Cache enabler.

But by far, it’s the easiest to use. Let’s look into more detail:

• Just activate it to get ridiculous speed
• No complicated features
• Allows you to also set the cache expiry and GZIP compression
• No possibility to exclude urls or anything similar
• Incredibly consistent, tied with Cache Enabler for the best consistency
• Not a wide adoption (meaning updates aren’t as guaranteed)
• If you want to speed up your website a lot in less than two minutes without sorting through a ton of settings, then this is the plugin for you. Stop reading and install it right now!

To help you out, here are the settings I’d recommend.


If you know you won’t update your site often, you can choose a longer expire time. Just make sure it’s about how often your site will be updated.

Powered Cache​

This one is just slightly slower than Simple Cache, but has a lot more options. Of these three fast ones, it is by far the most flexible. However, if you don’t what you’re doing, it’s by far the most intimidating of the three.

• Not as consistent
• Allows every option you could use for a page caching plugin
• CDN integration
• CloudFlare integration
• Premium version
• Quite complicated
• Exact setup will depend on your site
• Not a 2 minute setup
• Could take a while to find the best options
• Not a wide adoption (meaning updates aren’t as guaranteed)

Ok, so if you’re a power user, have sped up many sites before, or are extremely proficient with the technical caching lingo, then this could be the plugin for you. And the fact that you can exclude certain urls from caching is a plus with Ecommerce sites.

Though with this plugin, every site will need different configurations, here’s what I’d recommend as a starting point.




For the rest of the settings, you’ll have to decide what works for you. And again, for the cache timeout, put that to how often your site will update.

Cache Enabler​

The third fastest plugin is Cache Enabler. It’s just as consistent as Simple Cache, and is a good middle ground between the flexibility of Powered Cache and easiness of Simple Cache.

• Still really fast
• Can setup in two minutes
• No complicated features necessary
• Allows for regex for exclusions
• CDN integration
• Automatic GZIP compression
• Wide adoption with over 70,000 active installs
• Multi-site support
• Custom post type support
• Supports responsive images
• Works flawlessly with Autoptimize
• Works on pretty much every site

Personally, I use Cache Enabler because it gets me the speed of a fast website, works on every site I’ve worked on since I adopted it, and gives me the flexibility I need when I need it.

Here are the settings I use as a default:



Again, change the cache expiry to however often you update your site.

What About Paid Caching Plugins?​

Simply put, why spend money for only a possibility of a maximum of 25 milliseconds faster loading time? It doesn’t make sense!

After all, out of everything I’ve tested, free was the fastest.

Most of the time, premium versions don’t make the cache any faster. They just give you more features.

So why pay money for a slower site?

What About WP Rocket?​

Whenever I tell people that I use cache enabler, every time they ask my thoughts on WP Rocket.

Because let’s face it, Cache Enabler isn’t a fair comparison to WP Rocket. Sure, the caching may be twice as fast, but WP Rocket has many more features. It’s not comparing apples to apples, it’s comparing apples to fruit salad.

The sort answer is that, well, it’s too slow for me overall.

For one site I worked on recently, I tried both WP Rocket and the equivalent version of my default setup. And I only replicated the same features that WP Rocket has. End result, my setup was twice as fast as the fastest WP Rocket configuration I could get… and it’s more flexible for doing advanced configurations. It was 2.9 seconds vs. 1.4 seconds.

That's just one recent instance, I've tried it many times in the past as well. Because I want it to be the best solution. It would make my job 10x easier.

Sure, if you have a slow website, WP Rocket can make it much faster. But even at 3 seconds to visually complete, you’re leaving a lot of money on the table. As we saw above, that can mean 5-6 figures lost revenue each year (or more)

It would be far better use of your time to either hire someone who knows what they’re doing or to stay tuned so you can make your site faster than WP Rocket yourself.

Because next time, we're going to look at what WP Rocket does, and how we can replicate everything it does…

…but better.

 

[Nick M.]

The Best WP Rocket Alternative​

I don’t use WP Rocket.

At this point, most people ask why. And well, my answer is that it’s too slow. Not using WP Rocket and speeding up sites normally typically yields faster results. And it’s cheaper.

Now it’s not that WP Rocket is bad. In fact, it does everything exactly as advertised with a simple installation. If you’re looking to make a really slow site faster the easiest way possible, WP Rocket is the way to go.

In fact, everything that WP Rocket does is good practice. Things you should do on your own site. So let’s see how to essentially replace WP Rocket and make your site even faster.

I should note that I’m not 100% sure why WP Rocket is slower because I’ve not looked at it’s source code. My guess is that simply the act of putting everything in one plugin makes it slower.

WP Rocket’s Features

• Page Caching
• Cache Preloading
• Sitemap Preloading
• GZIP Compression
• Browser Caching
• Database Optimization
• Google Fonts Optimization
• Removing Query Strings from Static Resources
• Lazy Loading
• Minification/Concatenation
• Defer JS
• CDN Integration (including CloudFlare)
• DNS Prefetching
• Mobile Detection
• Heartbeat Control

This is the list of features taken directly off their own website.

Everything else it does are just nice conveniences and compatibility features. Not things we need to focus on implementing ourselves. This may look like a long list, but it’s actually quite simple to do everything here.

In fact, if you’ve already read through the post on caching, you’ve already completed several of items.

Now let’s look at a brief overview of what I’d recommend we do. Note that I’m not going to get into any of the specifics in this post, we’ll cover just an overview of what plugins to use. And for those of you who already know code and how WordPress works, in those later posts we’ll go over how to do pretty much everything here without plugins, making your site even faster!

Autoptomize
With over 2 million active installations, Autoptomize is one of the go-to plugins for improving your site speed. We’ll be using it for:

• Lazy Loading
• Minification/Concatenation
• Deferring and asyncing JS
• Help with Google Font Optimization

It’s worth noting that Autoptomize does more than just that, but these are the features we’re using to replace WP Rocket.

Note: will require a code snippet for the functions.php file to async JS

Warm Cache
What good is having a caching plugin if the first user lands on an uncached page? We want every page to be cached all the time, even right after we clear the cache. Warm Cache allows us to do that. Some other caching plugins include cache warming (a.k.a. cache preloading), but none of our fastest 3 include it.

It fixes:

• Cache Preloading
• Sitemap Preloading

My Custom Functions
My Custom Functions will allow us to add code snippets to our functions.php file, while letting us update the theme without destroying our edits. For those that don’t know how to code, don’t worry, I’ll be providing all the snippets.

• Asyncing Autoptomize JS
• DNS Prefetching

Later on, we’ll dig into this file a lot more, because it means we can make the theme itself faster without worrying about creating a child theme. However, for many themes, creating a child theme is actually better.

OMGF
OMGF is a plugin that allows Google Fonts to be hosted locally. Which means fewer DNS lookups and you can get those better scores in GTMetrix for implementing browser caching (not that we care about the scores).

What this plugin does well is that it adds a cron job to always make sure you have the most recent version of the fonts installed, which is the number one reason why you should not load Google Fonts locally.

Kind of obvious, but this one solves:

• Google Fonts

CDN
So spoiler alert, I currently use StackPath because it’s the fastest CDN I’ve found. That could very well change in the future as web standards change (and they are going to change within the next year or two, I hope). However, even the free CloudFlare CDN does everything we’re going to need it to do to replace WP Rocket.

Our CDN will take care of many of these items for us:

• Browser Caching
• Database Optimization
• Removing Query Strings from Static Resources
• CDN Integration (it’s a CDN, duh)

And a lot more. Today, CDNs are no longer optional because of all the features (and security) they provide.

Overview
Let’s look back at this list from WP Rocket:

• Page Caching (Cache Enabler)
• Cache Preloading (Warm Cache)
• Sitemap Preloading (Warm Cache)
• GZIP Compression (Cache Enabler)
• Browser Caching (CDN)
• Database Optimization (Not worth a plugin)
• Google Fonts Optimization (OMGF)
• Removing Query Strings from Static Resources (CDN)
• Lazy Loading (Autoptomize)
• Minification/Concatenation (Autoptomize)
• Defer JS (Autoptomize)
• CDN Integration (CDN)
• DNS Prefetching (My Custom Functions)
• Mobile Detection (Not necessary with response themes)
• Heartbeat Control (Usually not necessary, but if needed WP Rocket made a free plugin)

There you have it. A simple guide on how to completely replace WP Rocket.

Actually, there’s several more reasons why I’m going to share with you this setup:

• Most of these plugins are compatible with most sites, including Divi and Elementor
• These plugins are compatible with most hosts, meaning that it can work wherever you host your site
• This setup does way more than WP Rocket or what I’ve let on here
• It’s easy to see how everything works and to test for the optimal configurations for your site

Occam’s Razor
Of course, simpler is always better. As I’ve noted, you won’t even need most of these plugins if you want to dive into the code more. So, we’ll work out way through that.

Until next time, may the speed be with you.



*that was a bad pun

 

[Nick M.]

4 “Advanced” Speed Optimizations You Didn’t Know You Needed​

There are many tools online to help you speed up your website. Yet, nine times out of ten, they simply tell you what’s wrong. Not what you could be doing better.

Perfect scores don’t mean perfect speed.​

So here are four musts for website speed that will make your site even faster, even if you’ve already done “everything”.

1. Specifying Character Sets
Let’s talk about how the browser has to render your webpage for a bit.

There are three overarching big steps:

Downloading: This is the act of the browser getting the correct source files. Minimizing download time are things like caching, using a CDN, minification, lazy loading, image optimization, etc.

Parsing: This is the browser interpreting the files it has downloaded. The standard best practice here is keeping DOM nodes as minimal as possible.

Rendering: This is the act of figuring out how to display a page and displaying it. When you talk about asyncing/deferring JS, critical path css, or keeping fonts visible, that’s all to optimize the rendering.

Specifying a character set lowers the time the browser needs to parse a webpage’s code. There are several accepted character sets you can use in HTML, including ASCII, UTF-8, and UTF-16 (though ASCII is becoming outdated).

If you don’t specify which character set you’re using, the browser has to take the time to figure out which character set you’re using. Time you can eliminate by telling it early.

Most well-coded WordPress themes do this by default, but you specify it by adding a meta tag in the head.

<metacharset="UTF-8">

Or for WordPress:

<metacharset="<?php bloginfo( 'charset' ); ?>">

2. Set Image Sizes
Setting an image size doesn’t necessarily seem like the kind of think you’d have to set for speed. But let’s look at what’s going on in more detail.

This is what happens during the rendering step.

Rendering Performance | Web Fundamentals | Google Developers

Style: Style is when the browser determines which styles should be placed on which elements. The best way to limit this step is to remove unused CSS and make your CSS styles as clean as possible.

Layout: This is how each of the elements are placed on the page. Where do the headers go, or the text, or the backgrounds, or the images. The browser is essentially creating a wireframe of where everything is to put data in later.

Paint: Painting is just like it sounds, it’s filling out the pixels with color. Just like an artist uses a pencil sketch to get the layout of their work, they will then paint on top of the sketch to bring color. You can think of this step also like painting by numbers.

Composite: Often times when we’re coding up a website, there will be multiple layers. For instance, the text is on top of the background. Compositing is the act of putting the layers in the right order. You wouldn’t want the background on top of the text!

Crucially, all steps must be completed in order. If you need to update the layout, you’ll then have to paint and composite. However, you can start at later steps. So if the layout stays the same but the color of the text changes, you can just paint and composite. Lastly, layout takes the longest time because to update one elements position or size, the browser then has to recalculate the layout for the entire page! Which means we have to rerender the entire page. So we want to update layout as little as possible.

Let’s look at this in terms of images.

By default, images have no sizes until they are loaded. Which means the browser is busy with the layout, painting, and compositing of all the text before the images is loaded, then has to redo all that work when the image is loaded. Because once the image is loaded, it has a size, so layout needs to be updated.

And this happens for every image.

That’s a lot of work, don’t you think?

So if you specify the image dimensions in the HTML, it saves lots of time rendering the page.

3. Disable Image Hot linking
Image hot linking is when another website uses your images by linking to it directly. Not copying an image and using that copy, but rather linking to your copy hosted on your server.

Though this is legal in the EU and the US, it steals your bandwidth, can overload your host, and slows your site down.

But it happens.

Though it might not effect you now, it could in the future. And there’s no compromises in speed, security, or functionality to check for hot linked images.

There are many methods for this, so it’s best to look at what your CDN or host says to do for image hot linking.

4. Instant Page

There’s a chance that you might have heard or thought about the other three items I’ve listed. But if there’s anything here that you’ve not heard of, it would be this one. And it’s so simple to implement.

As a website owner/developer, we want our pages to load as fast as possible. Ideally instantaneously. However, with current technology (and the speed of light), there’s a limit to how fast we can make our pages load.

But what if we knew what link a user is going to click on before they click on it, and start loading that page early? If this were possible, and we already had a page that loaded fast, we really could have instantaneous load times.

Of course, this isn’t hypothetical.

It’s called instant.page.

And it’s a simple 1kB JS script that does exactly this. When a user clicks on a link, they usually hover over that link for a bit. Typically 200-500 milliseconds. Sometimes longer. That means we can shave off a lot of time.

Adding the script is simple. Here are three options.

For HTML sites, add this to your footer:

<scriptsrc="//instant.page/2.0.0" type="module" defer async integrity="sha384-D7B5eODAUd397+f4zNFAVlnDNDtO1ppV8rPnfygILQXhqu3cUndgHvlcJR2Bhig8"></script>

For a WordPress plugin, download either WP Instant Links or the instant.page plugins.

For WordPress functions.php, add this snippet to where you enqueue your other scripts:

wp_enqueue_script('instant-page', '//instant.page/2.0.0');

Of course, async, defer, and combine with your other JS.

Conclusion
As you can see, getting the fastest possible site is not simply about getting high scores on common best-practices tools. It’s also about knowing the intricacies of how your site renders and gets displayed.

And it’s about finding every possible advantage to speeding up your site, even beyond those commonly found on “Ultimate Guides to Speeding up Your Website” articles.

 

Dislike ads? Remove them and support the forum: Subscribe to Fastlane Insiders.

[ApparentHorizon]

@MJ DeMarco You ever marked a technical thread as Gold/Notable? B/C I nominate this one.

 

[Nick M.]

Top 5 Myths About Site Speed​

There are many myths about what it takes to make a fast site. However, not all of them will end up making your site fast.

So let’s explore the top 5 myths in detail.

Myth #1: Load Time Matters
This myth has got to die. Because load time doesn’t matter.

Why?

Simple: users don’t care about load time. In fact 95% of the time, you probably don’t even notice how long it takes for a webpage to fully load (citation needed). And for the typical user, the only way to know when a page is fully loaded is to look for the favicon to appear. Are you looking there?

So if we don’t care about load time, what really matters with site speed?

Optimal User Experience

”Onload is not the best metric for measuring website speed […] What we’re after is a metric that captures the user’s perception of when the page is ready.” —Steve Souders: Former Head Performance Engineer at Google

We don’t need a site to load fast. We need a site to feel fast. In fact, we can often use this to our advantage. Which means, we can actually increase load time to increase speed!

Sounds paradoxical, but it’s true. Here’s how.

Several years back, Google defined several new metrics for web developers to use instead of load time. And they are meant to answer the following questions:

1. Is it happening?: Did the navigation start successfully? Has the server responded?
2. Is it useful?: Has enough content rendered that users can engage with it?
3. Is it usable?: Can users interact with the page, or is it still busy loading?
4. Is it delightful?: Are the interactions smooth and natural, free of lag and jank?

(source)

Isn’t that the kind of experience we want to give our users? That’s how they developed their metrics that are more useful than load time.

1. Is it happening?: First Paint / First Contextual Paint
2. Is it useful?: First Meaningful Paint / Hero Element Timing
3. Is it usable?: Time to Interactive
4. Is it delightful?: Absence of Long Tasks

Furthermore, they’ve also defined two more metrics that further help shape our understanding of how complete the site feels:

• Time to Visually Complete
• Speed Index

Typically, when I say “this website loads in X seconds”, I’m referring to one of those two stats (usually speed index because that’s the number that affects Google search ranking).

Notice how none of these user-centric performance metrics are load time?

This means that to make a site feel faster, we can actually delay non-essential resources to speed up these metrics. The technical terms for this technique are “progressive rendering” and “prioritizing the critical path”.

This can, in some cases, make the overall load time slower.

Take lazy loading of images. That’s a technique that’s used everywhere. Yet, it can technically take your site 20 seconds to load. Or 3 minutes. Or however long it takes for users to scroll.

That’s an extreme example, but it helps to show that load time doesn’t matter.

Myth #2: PageSpeed Insights is the Best Speed Tool
Your next thought may be that Google’s own PageSpeed Insights must be a great tool to help you test your website’s speed. I’ll admit, it’s good. It’s leagues ahead of Pingdom, more useful than GT Metrix, and shows you the user-centric metrics.

In fact, from its November 2018 update, it’s substantially more useful than it was.

Though it is a tool I use, it is not the tool I use the most. I use webpagetest.org.



Why?

Couple reasons:

• PageSpeed Insights gives recommendations and can be hard to diagnose the problem
• The PageSpeed score leads you into a false sense of security (see 4 Speed Optimizations You Didn’t Know You Needed)
• Webpagetest runs multiple tests, ensuring the results are typical (not an outlier)
• Webpagetest provides technical data you can use to make your site faster
• Webpagetest allows you to clearly see the bottlenecks in speed

With that said, I still use PageSpeed Insights to double check that the site uses best practices, but I do not use it to measure speed.

Myth #3: CDNs Will Speed Up Your Site
This myth is one of my favorite myths!

CDNs can speed up your site. But don’t believe that a CDN will speed up your site.

Let’s look at both at how CDNs actually work, and my personal recommendation for CDNs.



Without a CDN, you probably have a single server that’s hosting your website. It can be located anywhere in the world, but let’s say it’s located in Oregon (because many hosts have servers there). This is completely fine.

If someone in California views your site, it will be served fairly quickly. That’s because California is fairly close to Oregon. It’s only about 20ms round trip. However, if a person from New York views the site, it could take a bit longer. In fact, New York City is about 90-100ms from Oregon. That’s 4-5 times slower. And this can’t get any faster because the speed is limited by the speed of light.

So then if you have someone from Europe visiting your site, it will take 200-250 milliseconds! You may have a great load time on the west coast, but across the world it’s really slow!

Of course, you may think that a quarter of a second round trip is still not that bad. Well, it doesn’t just mean your site is just a quarter second slower. In fact, because this round-trip time is for every single resource, your entire site overall is 10x slower! Furthermore, the initial DNS lookup and TLS handshake requires several exchanges between your browser and the server. Which means that even the initial loading of the webpage suffers a lot!

So here’s where a CDN comes in: CDNs have servers all around the globe. You simply connect them to your site and then it can get served from the closest server. This means your site has a consistent load time anywhere in the world!

But here’s an important distinction: a CDN doesn’t necessarily speed up your site. It just makes it consistently fast. Or if your site is slow, it makes it consistently slow.

Furthermore, not all CDNs are equal. Some are faster than others. For instance, take CloudFlare. Now CloudFlare is a perfect example of making your site consistently slow. Because it’s free and has great security features, I’ve tested out CloudFlare extensively. However, it has not made any of my sites faster. If it normally has a 400ms TTFB time, that will become consistent everywhere around the globe.

Which is why I’ve opted to use StackPath lately. On the exact same sites, everywhere I’ve used it, StackPath is about 2x faster than CloudFlare. StackPath is a CDN that actually makes your site faster.

Now, to be fair, CloudFlare has recently made a big announcement that could make it faster than StackPath, but it hasn’t been rolled out to everyone yet. Expect a speed test coming when it does.

But as you can see, a CDN doesn’t necessarily make your site faster. Though it can make your site faster. With that said, get a CDN.

Myth #4: Using a CDN for Images Improves Speed
Specifically in WordPress, there are many image optimization tools. And for most of them, they will also advertise that you should connect it with their CDN for images. Should you?

Well, there’s two sides of the same coin. Like above, CDNs can make your site faster. But here we’re dealing with a CDN specific for images.

This means that your images will get loaded from one CDN, and the rest of your site from another.

However, this violates a couple principles of site speed. The first being Occam’s Razor. Two CDNs is not the simplest solution, so it’s likely not the best solution. So just like two caching plugins are slower than one, two CDNs are slower than one.

And there’s a specific reason for that: when you setup a CDN for images, the images get served from a second domain. Remember the DNS lookup and TLS handshake mentioned earlier? Well, this applies to every domain you connect to. At best, it takes 200ms. So this means that your site automatically becomes at least 200ms slower if you serve your images from a second CDN.



So in the picture above, with the thin blue, orange, and purple bars (dns, connect, and ssl), that’s all wasted time where the site could be faster.

Again, CDNs can improve speed, but don’t think they will improve speed.

Myth #5: Mobile Browsers are Slow
It’s fairly well known that sites on phones load slower than those on your computer. And there’s a reason: mobile internet connections are typically slower.

So this may seem like a bad thing. Mobile browsers are inherently slower. Well, in one respect, they are. However, we can’t use that as an excuse for slow sites.

My goal is always 1 second for desktop and 2 seconds for mobile sites. Compared to most sites on phones, 2 seconds is really fast. Yet it’s slower than desktop. But the typical mobile site isn’t twice as slow as its desktop counterpart. It’s 3-4 times as slow.

For reference, Google specifically recommends 1.2 seconds and 3 seconds on desktop and mobile, respectively.

So how can we still get mobile sites to load fast?



Well, let’s not make the site fast despite the fact that it’s a mobile device, but make the site fast because it’s a mobile device!

Phones have a smaller screen than laptops or desktops, which means it’s possible to load much less of the site and have it become visually complete. We can take all the techniques of progressive rendering (as we learned above) and use them even more than on desktop sites!

Again, it’s making the site load slower to make it feel faster. Because so much less fits on a phone scree, you can delay so much more!

Conclusion
There are a ton of resources online about speeding up sites. And while many will actually tell you tips that will make your site faster, very few actually help you learn why your site is faster. And that can leave you very confused.

That’s why it’s important to cut through all the myths of site speed to learn how to make your site feel fast, really.

 

[Nick M.]

i have one client who has tons of plugins on that Wordpress. Also some kind of system what gets new real estate object every hour in thousands. What advice would you have for that? Site is 50gb :O

When you're dealing with lots of data like that, everything you want to do falls in two categories:

1. Make the server as fast as possible
2. Take as much load off the server as possible

Definitely do what @ApparentHorizon and @LittleWolfie said, and if you can, make the new real estate objects as small as possible. That way, it's just less data to deal with.

I don't know the specifics of the setup, but make sure that the server is optimized. If you're on a shared host, get off it. The only good shared hosting I know of is Siteground. And that may or may not be enough. If you're looking at VPS or dedicated servers, definitely look at the RAM as well as the storage size. Also, not all VPS or dedicated servers are created equally. PHP 7.3 is a must. Along with OpCache. If the site serves static content, make sure it's NGINX.

Also, are all the plugins necessary? Duplicate plugins will slow things down. Even duplicate plugins that are supposed to speed up the site. If you have good caching and a CDN setup, the plugins may not effect the speed at that size, but it will definitely slow down getting the new objects. Also, even if your site has to update regularly, offload as much as possible to a CDN. That can greatly reduce how much the server has to deal with. My personal favorite is StackPath because it's easy and faster than any other CDN I've tried (including CloudFlare).

Of course, I'm kind of just guessing since I don't know what you've already tried or where the bottleneck is.

 

Dislike ads? Remove them and support the forum: Subscribe to Fastlane Insiders.

[ApparentHorizon]

Un-optimized Shopify sites with 22 MB file size (for home page) actually loads as fast as a heavily optimized WP site, if not faster. I'm still trying to dig out what type of tech stack they're using.

techstacks.io

TechStacks lets you Discover the Hottest Technology Stacks of the most popular Startups and Apps using your favorite languages and technologies!

techstacks.io

 

[srodrigo]

Myth #1: Load Time Matters
This myth has got to die. Because load time doesn’t matter.

Why?

Simple: users don’t care about load time. In fact 95% of the time, you probably don’t even notice how long it takes for a webpage to fully load (citation needed). And for the typical user, the only way to know when a page is fully loaded is to look for the favicon to appear. Are you looking there?

I must be the only weirdo out there who closes the tab if the site takes more than a few seconds to load.

Do you have a 2023 version of this thread? 4 years is pretty long in tech.

 

Dislike ads? Remove them and support the forum: Subscribe to Fastlane Insiders.

[LittleWolfie]

Fantastic write-up @LittleWolfie

Thanks, you can hear just how annoying and confusing this was for ground control here. That is about 2.5 seconds.

Fir the real estate system, I'd say go headless with a database perhaps on Amazon or Google with a restful API. Consider publishing static page per listing and just alter the search page/table of content and delte pages as appropriate.

Use next gen images and CDN in multiple regions, if there are a lot of mobile users, investigate pushing video/pictures to a proxy on the 3g edge.

 

[Dominik_M]

Great article!
It should be added that a Content Delivery Network (CDN) is not only a nice improvement but worth gold if you have users across the globe.
Speed of light is the limit for data signaling.
A request from Frankfurt, Germany to Adelaide, Australia will take longer than 300ms to complete - no payload transferred yet!

 

Dislike ads? Remove them and support the forum: Subscribe to Fastlane Insiders.

[Nick M.]

What an awesome thread; I've been running a Wordpress site on HostGator and just started running another one on SiteGround and I can't help but feel there's a speed issue thanks to Jetpack and pixel.wp.com and with whatever default caches are installed. Your post has shown me that my hunch was correct, that there are better Wordpress caching plugins!

Yeah, personally I'm not a fan of Jetpack or the pixel CDN mainly because they seem like a lot of overhead. It's Occam's razor, simpler is often better. With that said, not everything is that simple.

Do keep in mind that these TTFB times I recorded don't factor in network delays or the physical time it takes to send the data from the host to the browser. I did these tests on a local host.

It's also worth noting that multiple caching plugins slow down your site. Just one will do. Multiple just means you're doing twice the work for the same results.

And from my experience, SiteGround has always been better than HostGator in terms of speed. It's a bit more expensive (until you get to VPSs), but well worth the money.

 

Dislike ads? Remove them and support the forum: Subscribe to Fastlane Insiders.

[Nick M.]

Okay that's actually pretty interesting. Most places, people recommend using both CloudFlare with Stackpath.

So now would Stackpath make up for the loss of features that cloudflare comes with? Such as DDOS protection and the other bells and whistles? For example the firew and page rules?

P.S. I also don't use imagify CDN (didn't even know they had one), I'm using SG Optimizer for my images, haha I don't know why I had imagify in my head.

To be honest, I've never heard of using both CloudFlare and StackPath before, but after looking at how others have done it, my first instinct would be that it's still slower than one CDN because of all the DNS lookups and TLS handshakes.

When I've tested StackPath and CloudFlare before, the main speed difference is in the Time to First Byte (TTFB) for the html. All the resources loaded in the same amount of time. The setups I looked at had CloudFlare serving the HTML and the resources going through StackPath. That would mean you'd get the slower TTFB, and another 200-500ms wasted in another connection. Therefore, either CloudFlare or StackPath should be faster than both.

If you want the absolute most secure site, go with CloudFlare all the way. They have the best security features I've ever seen. Your site will only be 100-200ms slower than StackPath from what I've tested. However, that time discrepancy can make a difference on your overall business.

If you want the absolute fastest site, go with StackPath. They do have security features like DDoS protection and several other security features. However, I'd not recommend their WAF. Maybe you'll have a different experience, but for me it made my testing site painfully slow. (like 4 seconds was fast with their WAF). They do have a feature called "Edge Rules" which has some overlap with page rules. However, check out what if it has what you need before moving over. StackPath does have a 2 week free trial, so you can make sure it has all the bells and whistles you need from before you switch your site over. For most static sites, I use their full integration, and for ecommerce sites (or any kind of dynamic site), I use the standard WP integration.

With that said, keep in mind that I'm going to be redoing my CloudFlare v StackPath testing again in about a month or so because of CloudFlare's announcement of adopting QUIC.

 

[Serito]

Wow man great value! thanks a lot! Made my site a lot better with your tips!

I am experiencing a problem now though and i really hope that you (or someone else) can help. I don't think this is the thread for it but i am completely stuck and i don't know where to go with this. So im really sorry..

After i deleted a testimonial slider within the wordpress editor i got this error message:View attachment 37661

I don't have programming experience and the people i know that do had no clue.. 1 person however thought that i accidently deleted a file that is called in the function and therefore i get this message?

I really hope someone can help me with this as i am getting pretty desperate.. Also willing to pay ofcourse if that helps

Hi Sirrom, you should turn off notices so that the message isn't shown to the user. In Wordpress, this is done by editing wp-config.php and setting WP_DEBUG to false:

define( 'WP_DEBUG', false );

- see Debugging in WordPress

Then you should investigate the source of the notice (maybe you removed the testimonial slider, but an empty row is still there? Just guessing).

Hope it helps.

 

Dislike ads? Remove them and support the forum: Subscribe to Fastlane Insiders.

[Zyzzz]

A well-optimized WP site beats out Shopify any time in that. WP wins in everything except speed.
I drool when I see 34 MB Shopify sites loading in under 1 second.

I don't know much about Shopify but some of my sites load in under 2 seconds with help of speed + caching plugins, Cloudflare CDN, and a 6GB RAM VPS server.

 

Dislike ads? Remove them and support the forum: Subscribe to Fastlane Insiders.

[Cameraman]

I don't know about that testing site, but 3.27s is not fast. You should aim for at least below 2s, the lower than that, the better.

What I found to be most effective is a combination of using WP Rocket, ShortPixel for images (but other image enhancers will probably do as well), looking into what plugins slow down your site and, if possible delete or replace them, and a WordPress dedicated hosting company (I use WPspace).

My main problem wasn't desktop but, like probably for many others too, the mobile score. It used to be between 40-75, depending on what I tried. Since implementing these changes it now sits at 89-91 (and 99-100 for desktop).

Hope that helps.

I agree that WP Rocket is a great cache and you should be aiming for below 2 second fully loaded page times. The problem that I've found with all caching plugs is that they just speed up what's already on the page. Most of the time slow page load times are down to the page content, and I don't just mean images.

I had problems with my site a few years ago with pages were taking around 6 seconds to load. After a lot digging, I found many of my plugins were loading themselves on every page or post, even if they aren't being used. I eventually found a free plugin called Asset Cleanup which allowed me to see what is being loaded in a page and decide if I wanted to stop it.


This is a screenshot from my WordPress backend showing my Contact form page. The items in red are plugins that load themselves on the page but aren't ever needed. I've therefore used Asset Clean up to dissable them.

This page now fully loads in 1.4 seconds and many of my post pages load in 0.9 to 1.2 seconds. This is using standard shared hosting on SiteGround andthe Divi page builder theme which a lot of people criticise for beign slow.

It's well worth trying Asset Cleanup but be careful and test your pages properly afterwards. You can easily break a page by unloading code that's needed.

 

Dislike ads? Remove them and support the forum: Subscribe to Fastlane Insiders.

[Hitch-hiker]

Do you have a 2023 version of this thread? 4 years is pretty long in tech

I agree. 4 years is a lot in web development

 

[LittleWolfie]

Even if your site is already "fast" (3 seconds), just a 1 second increase can mean a $73,960 annual increase in revenue!*

3 Seconds fast? That is longer than a round trip to the moon and back, apollo 11 radio conversation are noticably slow.

100 milliseconds cost amazon Billions (1% of sales)

What are your sites? How fast are they? Are you caching in multiple geo-regions? What about minifying javascript, reducing image and video size? Moving to static sites?

 

Dislike ads? Remove them and support the forum: Subscribe to Fastlane Insiders.

[ApparentHorizon]

Fantastic write-up @LittleWolfie !!

i have one client who has tons of plugins on that Wordpress. Also some kind of system what gets new real estate object every hour in thousands. What advice would you have for that? Site is 50gb :O

Run asset cleanup then index the listings. Making db calls for all of those kills your server.

 

[ApparentHorizon]

Thanks, you can hear just how annoying and confusing this was for ground control here. That is about 2.5 seconds.

Fir the real estate system, I'd say go headless with a database perhaps on Amazon or Google with a restful API. Consider publishing static page per listing and just alter the search page/table of content and delte pages as appropriate.

Use next gen images and CDN in multiple regions, if there are a lot of mobile users, investigate pushing video/pictures to a proxy on the 3g edge.

What experience do you have with headless wp?

I'm getting 1-3s load times on a 5k SKU ecomm site, with just indexing and caching.

edit: Also thanks for the write up @bytecode. Major brain fart on that last post on my part.

 

Dislike ads? Remove them and support the forum: Subscribe to Fastlane Insiders.

[ApparentHorizon]

@bytecode LiteSpeed Cache is looking interesting these days. Have you had a chance to give it a whirl? I'm going to try it out on a new site in the next 1-2 months.

 

[MHP368]

Solid stuff , thanks for taking the time

 

[softwareRules]

What an awesome thread; I've been running a Wordpress site on HostGator and just started running another one on SiteGround and I can't help but feel there's a speed issue thanks to Jetpack and pixel.wp.com and with whatever default caches are installed. Your post has shown me that my hunch was correct, that there are better Wordpress caching plugins!

 

[cryptocasper]

In some sites for clients I use Nginx fastcgi cache which caches site + I make some other mods so in your region for example if you live in US and site hosted in US it will open under 1s all time.

Same if you live in EU and site hosted in EU - Opening times always under 1s - in average most client sites open in 450-770ms.

It requires lot of effort but speeding also impacts a lot search engines which can give additional traffic.

 

Dislike ads? Remove them and support the forum: Subscribe to Fastlane Insiders.

[Nick M.]

Great article!
It should be added that a Content Delivery Network (CDN) is not only a nice improvement but worth gold if you have users across the globe.
Speed of light is the limit for data signaling.
A request from Frankfurt, Germany to Adelaide, Australia will take longer than 300ms to complete - no payload transferred yet!

Completely! A write-up on CDNs is coming sometime along on this thread.

 

[Tourmaline]

How much of this can be applied to shopify?

Curious if there's a reason you like wordpress so much? Although you're addressing my biggest gripe with wordpress...it being so slow typically!

 

[Nick M.]

How much of this can be applied to shopify?

Curious if there's a reason you like wordpress so much? Although you're addressing my biggest gripe with wordpress...it being so slow typically!

Having never worked with Shopify before, I can't really say how much applies.

What I can say is that every single technique I'm posting up here applies to site speed on all websites. There might be different ways to do everything on Shopify in particular.

I like WordPress mainly because it's incredibly flexible, like 34% of websites use it (citation needed), and since it's slow, there's a good market for speeding it up.

 

Dislike ads? Remove them and support the forum: Subscribe to Fastlane Insiders.

[LightHouse]

@bytecode this is an excellent thread and very comprehensive so far on the pieces you have posted. Great work.

I think a lot of people do neglect how much sitespeed can really effect things these days. In the era of mobile computing and spotty performance married with instant gratification and anything-on-demand culture if your site takes too long to load, you are definitely losing money and/or trust with customers.

I look forward to the additional sections you are planning on adding, this can be a great resource for the forum.

@GlobalWealth was just talking about this on the phone, and I think I had a conversation with @therealmark recently as well.

 

[softwareRules]

@bytecode this is an excellent thread and very comprehensive so far on the pieces you have posted. Great work.

I think a lot of people do neglect how much sitespeed can really effect things these days. In the era of mobile computing and spotty performance married with instant gratification and anything-on-demand culture if your site takes too long to load, you are definitely losing money and/or trust with customers.

I look forward to the additional sections you are planning on adding, this can be a great resource for the forum.

@GlobalWealth was just talking about this on the phone, and I think I had a conversation with @therealmark recently as well.

I updated my caching plugins on my wordpress sites after reading this post. The desktop loading is much improved (using better PNG compression helped too). But on mobile, there's a weird delay before the initial loading of the page. I'm not sure if it's a DNS issue or something else

I'm going to try and use the remote debugging tools to figure out what's going on: Get Started with Remote Debugging Android Devices | Tools for Web Developers | Google Developers

 

[LightHouse]

I updated my caching plugins on my wordpress sites after reading this post. The desktop loading is much improved (using better PNG compression helped too). But on mobile, there's a weird delay before the initial loading of the page. I'm not sure if it's a DNS issue or something else

I'm going to try and use the remote debugging tools to figure out what's going on: Get Started with Remote Debugging Android Devices | Tools for Web Developers | Google Developers

On most modern browsers you can emulate a mobile phone, try using pagespeed plugin in emulation and see if you can replicate. There are a variety of ways to get to the bottom of it, but you have to rule out your phone/service first.

I am sure @bytecode has some good suggestions as well.