What Sites With Great Website Speed Have In Common
Last week, we looked at what some of the most popular media sites and blogs had in common. We looked closely at their layouts and content. Now, we’ll examine some of the fastest and most popular websites on the internet to see what they’re doing to deliver such a fast website experience to visitors.
Website speed is not a flat metric. It is affected by dozens and dozens of factors. However, it can be daunting to sort through all the potential culprits responsible for slowing down site speed.
Below, I’ll evaluate four attributes that popular sites with great website speed have in common.
Who has a fast website with good website speed?
Often, one of the best ways to get an idea of how to do something is by looking at what someone who is currently doing it.
Website speed is not inherently the easiest thing to do this with.
Why?
Well, a lot of people will measure website speed using free tools like Google Pagespeed Tools, Pingdom, or GTMetrix (which focus too much on TTFB).
Unfortunately, these are not reliable tools that provide a good look at actual page speed.
Don’t get me wrong, they can be used as part of a speed evaluation protocol, but the best way to look at page speed — and the way Google will be measuring it in their ranking algorithm later this year — is in the Chrome Developer Tools waterfall.
You can read my whole manifesto on measuring and improving website page speed here.
Fortunately, I dug into the waterfalls of several of the fastest and most popular sites on the web. Including…
- The Guardian
- The Washington Post
- TravelBlog.org
- Wikipedia
- Deadspin
- RobbWolf.com
- Snopes.com
- Ranker.com
- FanFiction.net
I also looked at a few other large sites that get a lot of traffic, but may not be as well known as the others above.
Let’s take a look at what I learned about fast website speed.
1.) Fast websites use CDNs
CDN stands for “content delivery network”.
A CDN takes your site from your origin server and distributes it to other servers around the world; allowing visitors to access your website from the closest possible server.
A CDN is a staple of all the fast sites I looked at. Every single one of them was using some kind of CDN.
CDNs are cheap — and even free in many cases. They are simple to configure and are available to sites of all shapes and sizes.
This may seem like a no-brainer, but the majority of the websites on the web still aren’t using CDNs.
If you’re currently using Ezoic, you can flip on a CDN in one click by installing and be using the free Caching App (instructions here).
2.) Most of these sites avoid overuse of auto-play video and floating video players
Sometimes it’s not what fast websites include on their pages that matter most.
Fast websites often do a good job of excluding components that are notorious for slowing down website speed.
In this case, these publishers were selectively using video.
Videos and video players can slow down site speed for many visitors. This is especially true when the video is set to auto-play.
A visitor will often be happy to wait for a video to load if they are interested in the content. However, auto-play videos assume that the visitor wants to play the video on the screen.
Of course, not every visitor is going to want this.
If the visitor doesn’t have a super-fast connection, this can slow down overall website speed or disrupt the overall experience on a particular page.
The same can be true for floating videos.
These two elements are often found with publishers that leverage video ads; as video ads seek good view time and viewability; which often requires auto-play and floating video features.
This may also be apart of a publisher’s video strategy; which includes ad pre-rolls.
It is very difficult to deliver all visitors videos in an ad format without negatively impacting user experience. For visitors with a very fast connection, the larger page size and inclusion of video ads may not considerably impact their experience.
For many visitors, the added video load time will cause a slower experience that could negatively impact engagement time.
This is why visitor segmentation shows time and time again to be so valuable to publishers. Video ads and a video strategy can be selectively applied to some visitors in a way that can increase engagement and per session revenue.
However, a broad implementation of video may ultimately result in lowered visitor engagement and poor website speed.
The best solution is to deliver different visitors different experiences.
3.) Fast sites resize and compress all of their images
I collected a sampling of 15 images off of popular fast sites.
Here’s what I learned from studying those images:
1.) The images were compressed. The median image size was 56kb.
2.) The images were resized for mobile. Most did not exceed a width of 650 pixels (which is about as wide as a mobile viewport will get)
3.) Most of the images were JPEGS, not PNG or GIF.
Web page file sizes have grown considerably over the years. With more and more scripts on the page, it is imperative sites avoid having images that are too big.
I’ve banged on this drum before when talking about site speed. Many websites rely on plugins or extensions for image compression.
Most plugins, tools, or extensions designed to compress images leave a lot to be desired.
Example: If you have an image that is 2,000 pixels wide, it is wider than almost all viewports that visitors will actually be viewing the image in. Even if you properly compress the image using Photoshop or Optimizilla, it is unlikely you will ever see that image drop below 150kb.
You must resize this image or no amount of compression will ever be able to make it small enough to where it doesn’t affect page load times.
If you want to know how to properly resize and compress images, you can check out this short article here.
4.) Really fast sites use best practices like lazy loading and caching
I was able to detect some common best practices for website speed across all of the fast sites I studied.
This includes things like asynchronous loading — also know as lazy loading — which means the most important elements of the site are loaded first, with calls to less important scripts being made after the content the visitor wants to see loads first.
This deals largely with javascript (js) on the page. JS is notorious for slowing pages down.
Go to any slow website page, right-click in a Chrome browser, click inspect element, go to the Network tab, and then refresh the page.
This will show you their waterfall in Chrome’s developer tools. If they are a slow site, I’m willing to bet that all the slow things you see loading on the page are coming from two sources.
1.) Calls being made to services responding slowly (maybe even the origin server).
2.) Miscellaneous JS on the page.
Caching simply refers to the act of saving parts of a site for instant loading. This means caching elements that may not often change (like existing articles or pages with static content).
Any number of rules can be set for how long an item is cached, but this can prevent visitors from needing to request the full page from the server to load every page whenever they visit a site.
This results in much faster load times, especially for return visitors.
There are a number of tools, plugins, and instructionals available on how to implement these techniques on your site.
WordPress sites often will use a tool like W3 Total Cache to implement lazy loading and caching on their site. However, if you do this, you should properly understand how to configure the settings of this app before setting it live.
Ezoic users can use Ezoic’s free caching app to simply turn on all of these best practices. This is usually the best option if you use Ezoic (as it configures proper settings for you).
Custom sites — or any site for that matter — can find and add any of these rules to the <head> of their website by searching the exact rules on a site like W3schools.
Ultimately, these are principles that every site can use and benefit from. Although, many will need to configure settings to fit their unique needs.
What did we ultimately learn from all of these fast sites?
Fast sites all have one thing in common.
You can tell they are fast when you visit them.
All of these sites have focused on the most important metric of all, the visitor’s experience.
Speed is often obsessed over by publishers. While there are ways to objectively speed up your site, this obsession over site speed isn’t always warranted or even necessary.
I’m guessing this is because of website speed measuring tools that spit out composite scores. I’m assuming that it is falsely believed that if these scores are improved that organic traffic, SEO — or even UX metrics — will improve as well.
Improving website speed scores won’t directly do any of those things; however, improving the website experience can.
Example: Imagine you improve a site’s time to interactive —the time until a visitor can interact with the content — from 8 seconds to 3 seconds.
This will likely positively impact engagement time and eventually SEO.
If you improve the same page from a time to interactive of 3 seconds to 1.8 seconds, the impact is likely to be much less noticeable (if noticeable at all).
The percentage improvement is close to the same; however, the improvement to the visitor is totally different.
The first improvement is way more impactful to the visitor.
This is why looking at things in terms of a score is not really the best way to think about website speed.
Publishers that focus on the website visitor usually outperform the rest.
Think about what we learned from the selective use of video. This is likely more than just a decision made about website speed.
These publishers likely don’t see the broad implementation of these types of experiential elements as an overall positive experience for their audience.
In fact, visitor engagement metrics are probably the best objective way to measure and impact all of these things.
Nevertheless, website speed is best measured in the developer waterfall in Chrome and something that should be closely watched when making overall decisions about what should — and shouldn’t — be on the page.
Questions, thoughts, opinions about this data?
Share them below.
