How Websites Slowdown

How Websites Slowdown
  1. Why Website Speed is Important
  2. How to Check & Monitor Your Website Speed
  3. How Websites Slowdown
  4. Optimizing Static Vs Dynamic Sites
  5. How Hosting Affects Your Website Speed

Speeding up your website is exciting but before you start adding a caching plugin to your site it’s good to think about the whole process of building a web page. Because each part of building and rendering a web page can be done efficiently and fast OR inefficiently and slow.

1) Requesting a Web Page

The first thing that happens is that a visitor’s browser requests a web page from a server. 

Requesting Web Page

If someone wants to visit Laid Back Games. They’ll request a page and that has to get to the server. The server uses WordPress to assemble the page. It turns a bunch of PHP files into a single HTML file which is returned to the visitor.

When you receive this file this is called the time to first byte – or TTFB. This isn’t one of the official Lighthouse performance metrics that search engines like Google use – but it is still very useful to know.

Server Location

The first place to try to optimize is the location of the server. If you have customers that are in a specific geographic region try to put a server close to them.

Speed up WordPress & Server Speed

The second is how the server assembles the HTML file. That’s the WordPress specific part of this series. It could be your server and how fast it parses PHP, it could be how many plugins you have and what each of those plugins are doing, it could be the theme and how many templates and how many template parts you have to stitch together.

Time to First Byte Goal

A good goal for time to first byte (TTFB) is less than 200ms. If it’s higher than that it’s very likely a server or WordPress issue. And if it’s shorter than that you’ll probably be able to optimize your site better in other areas.

2) Parsing HTML & Gathering Assets

Once the visitor’s browser has the HTML page it starts reading through the HTML and loading assets. That means image, CSS files, and JS files. 

We’ve all heard about HTTP – that’s the protocol that your browser uses to download files. And for decades we’ve used HTTP/1.1. But there’s a new protocol called HTTP2 that’s starting to roll out. If your server and your client’s browser both support HTTP2 you can download assets in a new fashion.

HTTP/2 (Multiplexing) compared against HTTP/1.1
With HTTP/2 you can multiplex
which means you only need one connection to download multiple files

This sounds like a minor feature but it’s actually huge. Imagine if you have to send a separate email to get the image for your birthday party invite, a separate email for the music, and a separate email for the birthday party invite copy. 

And you can only send the 2nd email after you’ve received a response to the first email.

With HTTP/2 your browser sends the equivalent of one request (or one email to keep with our analogy) which requests the image, music, and copy. The server will respond to that email thread with whichever files it has available and gets your assets much faster.

And if you have a huge file like a large photograph that no one bothered to crop – other assets won’t get stuck behind that request which makes the whole site take forever to load.

3) Rendering HTML & Assets

Once the browser has at least some of these assets it starts rendering them. And this is called First Contentful Paint (FCP) which is one of the main signals search engines use to measure the speed of your site.

First Contentful Paint

Here’s what Google says about First Contentful Paint:

“First Contentful Paint measures how long it takes the browser to render the first piece of DOM content after a user navigates to your page. Images, non-white <canvas> elements, and SVGs on your page are considered DOM content; anything inside an iframe isn't included.”

I like to think of First Contentful Paint as some content, with CSS for colors & styles, and the first image – likely a logo.

First Contentful Paint Goal

If you’re looking for metrics you want your FCP to be 934 MS or just under a second. That’s when users start to expect to see the content for your site to start loading.

If this is taking too long and you have a good TTFB time then it’s likely your assets. You could reduce the size of your assets – so optimize your images, concatenate files which means you download one medium file instead of a dozen tiny files, and make sure you server can handle HTTP/2.

4) Largest Contentful Paint

Your browser keeps loading and rendering images, new stylesheets, loading JS files until it loads the largest image or video file. This is called the Largest Contentful Paint or LCP.

Largest Contentful Paint

You want your Largest Contentful Paint to happen in 1.2 seconds or less.

If your first couple numbers look good and your LCP is taking a while then you want to make sure you load the largest content element earlier and there are ways to make that happen in WordPress.

5) Keep Rendering Assets

At this point, your browser keeps loading all remaining assets until the page is fully loaded. This isn’t a major indicator for search engines anymore – but an older rule of thumb is that you want your website to load completely within 3 seconds.

As you can see there’s a lot of places where you might accidentally configure something to load inefficiently which slows down the whole site.

Probably about ½ of these are going to help your server return that first byte faster – and the other half are going to be about loading fewer assets, and loading them quicker.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.