2. ● WordPress lover since 2010
● Speeds up WordPress websites every day
● Loves spaghetti with tomato and basil
● Swims 4,3 km per hour freestyle
Sabrina Zeidan
19. 1. Speed Index = 5.98 seconds
2. Request count = 111
3. Page weight = 2.96 MB
Chances are your numbers are close to these:
* Average for the UK, reported by Google
21. Dogwalker’s site:
11 seconds before interactive
News site:
2 seconds before interactive
From: Dulles, VA - iPhone 8 iOS 14 - 3GFast
22. 2: Enable CDN
Say, your web host has a server located in London
Without CDN: when user requests your website it
gets it delivered from London
With CDN: when user requests your website it gets it
delivered from one of the CDN’s servers
23.
24.
25.
26. Read my full article here:
https://www.cloudways.com/blog/choosing-the-right-server-location/
27. 1: Change your web host/
Upgrade your hosting plan
Quick check: if a website has no traffic it’s not your
hosting, for sure
and in most other cases, too
28. 5. prevent WordPress from making additional requests
4. disable unused plugins
3. combine requests
2. Enable CDN
1. Change/upgrade web host
5 popular recommendations that don’t work:
32. So, how to find out what is right
for your website?
33. The only way to understand
why your website is slow is to
read waterfall, really
34. Few tips:
● Use right tools for specific purposes:
○ PageSpeed Insights -> for quick checks
○ Lighthouse in Chrome DevTools -> for handy analysis
○ WebPageTest.org -> for real UX testing
● Forget about the scores!
● Look at Largest Contentful Paint (or other UX metrics)
● Test speed across the website (not only homepage)
● Keep an eye on it everyday!
36. Get in touch with me:
● @sabrina_zeidan
● http://sabrinazeidan.com/
● sabrinazeidan@gmail.com
● or just say “Hi” right after this talk is over :)
Questions?
WordFest Live 2021
Notas del editor
Hi!
My name is Sabrina.
I’m from Kyiv, Ukraine.
I swim, I like spaghetti, I drink a lot of coffee.
But also, I speed up WordPress websites.
I do this every day. I’ve been doing this for the last 3 years.
And during these 3 years I never ever had a client who hired me before they tried doing something to improve their site speed themselves.
It always starts the same way: Hey Sabrina. A while ago we noticed that our website is slow. So we tried this and that, one thing after another, but basically it stayed as slow as it was. What are we doing wrong?
So I made a list of the most common recommendations that you will see like in every search result if you google something like “how to speed up your website”.
I’d like to share those with you today. And I will show exactly the reasons why they don’t help to improve the site speed most of the times.
Hopefully, after this talk you’ll be spending no more money, time and efforts on the things that don’t work.
[click video]
First, let’s take a quick look how the process of a web page loading goes.
After you enter a website address (or more likely, you click the link on another website), your browser makes a request to the server where the website is hosted, asking to send the data.
That server processes the request, executes PHP code of the website, gets data from database, and have the page ready as HTML file.
Which includes: text, font files to display that text, CSS files to make it look nice, images, JavaScript files to empower other functionality.
Except of these basic things, in order to serve content to visitor this page needs to connect with other websites and services. For purposes like:
[click-click-click]
animations
sliders
chat bots
messaging apps
payment gateways
newsletter subscription
videos
social sharing
analytics
another analytics
ads
sign-on systems
comments
a couple more analytic systems
For example, your website would connect to Mailchimp server, introduce itself.
Mailchimp would response, like yeah, I know who you are, I recognize your API key, so yeah, I will send you a proper data so that subscription form would be displayed on your website as you want it to, and it will be saving your subscribers into your account, not a random one.
And so, some images, CSS files, JavaScript files would be requested and loaded from MailChimp server then.
And the same way with other 3rd party services.
The more functionality like this you have on your website, the more requests you need to make, the more data you need to load.
Where these functionality, and therefore, these requests are stored at?
Everything that happens on your website comes from:
[click] WordPress core, theme and plugins
Considering there is a whole bunch of things we need to request, process and display, it sounds like a reasonable idea that:
to make our website faster we need to reduce the number of those, right?
So we’ll get to our top-5 popular recommendations that don’t work in a minute, but first
let’s take a look at these two websites.
Here is the first one.
It’s a popular news portal with loads of ads, popups, sliders, videos, tons of analytics and endless list of hot trending news.
And these all causes into 515 requests. And 4 mb of data.
And here is the second one.
It’s a tiny website - or even business card - of someone who walks dogs in the small town north from London.
It has one large image and 3 smaller ones, a few blocks of text, a couple reviews, and that’s it. No popups, no ads etc. And understandably it has just 17 requests. And weights less than 1.5MB.
Let’s get back to our recommendations.
We’ll start with number 5, 4 and 3 altogether: [click]
> prevent WordPress from making additional requests
> disable unused plugins
> combine requests
As they all are aimed to the same thing:
to reduce the number of requests, and page size!
So the idea is the following: if we make lesser requests and our page weights less, we need less time to process those requests and then - less time to load everything.
So you follow this advice.
You google how to prevent WordPress core from making additional requests and add a few lines of code to your functions.php file or use a plugin for that
You go and check out plugins that you don’t use, and disable some.
Most of the caching plugins have the option to combine CSS and JS into single file. So you just go there and tick the box, right
Then, you check the number of requests, and it have gone down!
But as soon as you check the timing, you might find out the actual time that user has to wait before starting to interact with your website is still the same!
Which means:
your website hasn’t become any faster
conversion rate hasn’t been improved
user experience hasn’t become better
Why it didn’t work?
First, Prevent WordPress core...
If WordPress core was responsible for your website being slow, then any other WordPress website would be slow too, as we all use the same core, right.
But that’s not the case :)
I made a fresh install of the latest version of WordPress, and this is how it loads on mobile device, 3G internet connection.
It needs 2.9 seconds to get fully loaded.
https://webpagetest.org/result/210105_DiQE_2936d5fbc2d935a00a7c8107d5686acf/1/details/#waterfall_view_step1
It makes 9 requests, and page weight is only 42 kB.
[click] LCP on mobile is 2.0s
And this all without caching, without any optimization techniques at all, shared hosting and free SSL certificate.
Freshly installed WordPress is fast.
Those requests and page weight don’t come from WordPress core, they come from themes and plugins that we use to get the functionality that we need.
So if there are so many CSS and JavaScript files needed for all that functionality, what we can do about that?
Another recommendation that you probably saw a lot is to combine those requests into one.
https://webpagetest.org/result/210105_DiQE_2936d5fbc2d935a00a7c8107d5686acf/1/details/#waterfall_view_step1
For example, if your web page load 5 external CSS files and 5 external JavaScript files, combining your CSS and JavaScript into a single separate file each would result in just 2 requests instead of 10.
However, it was a useful recommendation years ago, when most of servers were using HTTP 1.1 protocol.
But you would have hard times finding hosting that still uses HTTP 1.1, as most of them use HTTP 2 nowadays.
And here comes the big difference.
HTTP 1 would process 10 requests one after another - so it absolutely made sense to minimize the number of those.
While HTTP 2 is fully multiplexed, which means it allows multiple files and requests to be transferred at the same time. And combining files will have less of an impact on the loading time.
In many cases, it would make it even worse.
3. Disable unused plugins
This seems like a reasonable one, right?
So, you go to your plugins page and check out which plugins are activated and not being in use actually, so you can disable them. But the thing is it doesn’t really help.
Let me explain.
At a time when I was working at WP Rocket, one of the clients sent us a support request to help them to speed up their website.
That site had 400+ plugins activated, including 4 caching plugins at the same time. It was an absolute champion! I don’t know if anyone has broke this record later on, but that was the most impressive one that I’ve seen.
If you’re listening to this talk at the moment, chances are that your website (or your clients website) is nothing like this.
If you’re listening to this talk it means you are interested in keeping it nice, clean and efficient. I would assume that you keep the core, theme and plugins updated. You care about what you install, you read reviews before activating things and avoid bloating the website at all costs.
So if you go through the list of the plugins that are activated but not in use, it won’t be a slider plugin, live chat plugin, popup plugin, contact form and so on. Cause if you have them activated they are there for a good reason.
Your findings would probably be something like manual backups, search-replace, Import/Export plugins - in other words those that are used occasionally and can be disabled effortlessly.
But the thing is that those plugins don’t do much either, unless you interact with them.
So once you disable them not much is changed in the site’s performance.
So yeah, if the site is a Frankestein like this, the idea of disabling some plugins might be useful (and a new one!). But perhaps, it’s not your case.
So what is your case then?
Chances are your numbers are close to these:
Speed Index which indicates how quickly the page displays content a user can interact with around 6 seconds
Request count 111
Page weight 3 mb
These are average numbers for the UK, reported by Google
Remember, those 2 websites we looked at before?
Let me remind you the numbers: [read]
News website…
Dogwalker website…
Now, let’s take a look how they both are loading. From the same testing server, same device, and same internet connection.
This is how news website with 500 requests is loaded.
And now, here is a tiny website with 17 requests.
User has to stare at a blank screen before anything starts happening for quite a while.
[click]-[click]
LCP on the news site is 2.6s, while LCP on dogwalker’s site is 7.8s
Despite of it being quite lightweight.
As you can see, it’s neither the size of the page and nor the number of requests that makes a website slow or fast.
But what is that then?
Let’s see how those requests are executed and how that data is delivered.
You probably know what is this. It’s called waterfall, it illustrates everything that is happening on the page.
You won’t be able to see details here, but you can see the general picture though.
First screenshot is a tiny website’s waterfall, and we have all those 17 requests displayed here. Look at this large blank area: nothing is happening for a long time, and then some requests get processed.
It takes 11 seconds before user can interact with this lightweight, super simple website.
Second screenshot is just a part of news’ website loading process. It has 500 requests, but only 12 of them get executed before the content is displayed to user and they can interact with it. And this happens in just 2 seconds.
So while user is already enjoying the site’s content, the rest of the data is loaded in the background. Nice, isn’t it?
The next recommendation,we see a lot, is #2 in our list - Enable CDN.
First, how Content Delievery Network works?
Say, your web host has a server located in London.
Without CDN: when user requests your website it gets it delivered from London
With CDN: when user requests your website it gets it delivered from one of the CDN’s servers across the globe
Now, which way is faster?
Let’s see!
It highly depends on how fast your hosting server is, how fast CDN is, where they have their servers located and how they decide which one to use when request comes in.
But the most important question is not one of these! The most important question is: where is your audience located?
Take a look at this website.
It’s a SaaS startup Reply.io It’s a sales engagement platform that automates personal email outreach, calls, and tasks. If you check the location of their users, you will see that the majority is coming from the US, with another big chunk of users coming from the UK.
As you can imagine, both locations are important for their business, and they want their website to be loading fast on both sides of the pond.
It makes sense for them to use CDN to serve it equally fast everywhere.
Now, if you run the same check on Franco Manca’s website.
Famous chain with delicious pizza, good wine and an incredibly long queue to be seated.
You’ll find out that 93% of site visitors come from the UK.
And there is no wonder, actually. As it’s UK chain, right.
So they don’t care how fast their website is in Australia, they want their website to be as fast as possible to the visitors from the UK.
They would benefit the most if they won’t be using CDN, but instead if they make sure they have a fast server located in the UK (the closer to London the better as more than half their restaurants are located in London).
If website audience is not spread all over the world, but comes from the certain area, chances are CDN would make user experience worse, not better.
I wrote a detailed article about it for Cloudways blog, feel free to check it out.
And the last, but not the least, and my favourite one.
1: Change web host/ Upgrade your hosting plan
A few years ago some development agency contacted me.
They just finished developing a brand new website for their client that looked nice and functioned as it was expected to, but it turned out to be tremendously slow.
And they just could not hand it to a client that way.
They implemented some caching and basic performance optimization techniques.
Frontend became a bit better, but still was slow. And backend was hardly usable if more than two people would login at the same time.
They contacted their hosting provider (one of the good ones, by the way) and were recommended to upgrade their plan.
So they did that.
They upgraded their plan and it still was slow, so they hired me.
They told me the whole story and I was really surprised at that time that hosting support would recommend them to upgrade the plan for newly created website without any visitors instead of recommending what really would help them - to profile their code and see why the website is slow and fix it!
But that’s in ideal world. In real life as I learned later it’s more likely, if you ask your host why your website is slow they would offer you to pay more and get more resources.
Though it doesn’t seem nice from their side, I’m convinced that it’s our responsibility as developers not to be fooled like that.
If your newly created website that doesn’t have any traffic yet (or is hosted on staging) loads slowly - clearly the issue is with your code, not with resources on your server.
Upgrading hosting plan or moving to another host (with more resources) might mitigate the issues you have in your code, but it would never fix them. So you’ll just find out quite soon it’s slow again.
A quick note: There are obviously some hosts that are definitely slow.
But if your site’s code is fine, you won’t be experiencing serious problems before you have some meaningful traffic on your website.
So, these were 5 popular recommendations to speed up your website that don’t work:
5. prevent WordPress from making additional requests
4. disable unused plugins
3. combine requests
2. Enable CDN
1. Change/upgrade web host
Are these recommendations bad?!
Let’s make a little break
Here are 2 guys in Tampa, Florida trying to break into a safe in Taco Bell restaurant.
They brought some tools, they make noises and flash lights, but still no luck.
But… did you know that you can open that kind of safe using just a hammer?
A beer can?
Your hand
or even potato?
Yeah, you can do that!
In case you understand how digital safe works, and in case you know what you’re doing!
No, those recommendations are not bad.
It’s just that they are not suitable for each and every case. For majority of cases, actually.
How do you find out what is suitable for your website? What will help your website to run faster?
As you probably already understood, the only way to really see what’s going on there is to look into waterfall,
it should not be a guessing game.
Everything is in there, in waterfall.
Also, here are a few tips that would help you to understand your site speed better.
> if you are a developer they would help you to learn
> in case you are not a developer they will help you to hire someone to do the work for you without getting fooled
The fisrt one is:
to use right tools for specific purposes:
PageSpeed Insights > for quick checks
Lighthouse in Chrome DevTools > for analisys
WebPageTest.org -> for real UX testing
No matter which tool you use -> Forget about the scores!
Look at Largest Contentful Paint (or other UX metrics)
Test important pages (not only homepage)
Run tests few times
Do it everyday!
Test page loading time first (run test 3 times to get average, to avoid fluctuations)
Do 1 change at a time
Test page loading time again (use the same tool, the same page; mind to test under the same conditions: device, page, connection), 3 times also
Compare results (mind to compare exactly the same performance vital (whether it’s Speed Index, Time to Interact or Largest Contentful Paint)
Decide on weather it helped or not (mind the fluctuation it may vary a bit each time)
Sidenote: If you really want to become a Chef, you need to learn how to read a waterfall chart - that’s how you can skip a lot of guessing game
Here is a tool that I use for automatic everyday monitoring.
It’s called SpeedGuard.
It’s a WordPress plugin, you can have as many pages of your website monitored every day.
Those can be pages of different types - posts, pages, WooCommerce products, events, any other CPTs, but also terms, taxonomies and categories archives.
It uses PageSpeed Insights API and measures Largest ContentFull paint.
It calculates the average across your entire website and notifies you in case it needs your attention.
That’s all for free.
I was looking for the plugin like this, and couldn’t find one. So I built it.
You are very welcome to try it out and please feel free to let me know if it made life a bit easier for you too.
Thanks for listening. You can get in touch with me via Twitter, my website or email, my name is Sabrina Zeidan.
This was “5 popular recommendations to speed up your website that don’t work”
If you have any questions feel free to reach out. And I hope to see you in a chat in a couple of minutes!