Many sources list page speed as an essential factor in SEO. However, it is not a static concept; there are several things to consider when you’re optimizing your web page for page speed. This article is going to explain how page speed works, by developing a few related concepts. It is important to understand the exact factors that affect page speed in order to improve your page’s performance.
What is Page Speed?
Page speed refers to the time a webpage takes to load. However, there are several ways to calculate page speed according to the elements that were loaded. We’ll discuss further in this article the difference between several page speed evaluation models and how each of them works.
Even though not all websites use the same loading settings (in fact, there are many different ways to make a website load), recommendations to improve your page speed are usually the same for all websites.
In the case of WordPress, the easiest way to improve page speed is either:
using WP Rocket and an image optimization plugin or;
using Autoptimize and a cache plugin
But why does page speed matter? Well, first of all, Google has included page speed in its ranking criteria since 2010. In 2018, mobile speed was added to those criteria. As time goes by, we see an increase in the relevance of page speed for SEO. But what does this relevance translate into?
Other than counting as an SEO factor, page speed is also important in two other aspects:
First of all, page speed affects user experience; if your website takes a lot of time to load, users are not going to stick around and wait.
Secondly, page speed also counts for page analytics purposes. If your analytics tag is not fired soon enough, visits are not registered properly.
Even though Google never mentioned specific measurements for page speed, usually sources mention the three-second rule. This stems from Google’s mentioning that users will leave a page if it takes over three seconds to load. However, you should not consider it a golden rule to measure page speed. Google’s recommendations are as general as “make websites load as fast as possible”. It will depend highly on your page content how fast that is.
How Do Pages Load?
This is a difficult question, and we’ll start by explaining how a connection is established between a device and a website.
DNS
DNS stands for Domain Name System. It associates your website name with an IP address, as the DNS server establishes the connection between the typed URL and the website’s real location – its IP address. The IP address tells you the location of the website, according to your DNS – which is provided either by your domain provider or your CDN (Content Delivery Network).
You should know some DNS providers are faster than others. Studies have proved that Cloudflare is the fastest one, so if you care about page speed you should use Cloudflare. It’s also relevant to point out that if you have already visited a website once, it is going to remain cached in your device for a while (a period defined by TTL – Time to Live). When a website is cached in a device, it is going to load a lot faster since it does not need to reach out to the DNS to find out the IP address.
Connect
The “connect” phase translates into the timeframe in which your browser establishes a connection with the server, using TCP/IP (Transmission Control Protocol/Internet Protocol). There are several issues that can occur here. Since this protocol is routing your connection from your browser to the server, there can be blocks. One possible block is an unstable connection, which can cause a packet loss – so the data packet has to be sent again.
The server can also limit the rate at which the download is processed, or the ability to establish a certain number of connections to the server.
Many CDNs have workarounds that make the connection faster, such as using a geographically closer server.
SSL
SSL applies when your website uses HTTPS. In this phase, the browser and the server establish a security level through a cipher suite and a TLS (Transport Layer Security) agreement. After that, the browser verifies the website’s SSL (Secure Sockets Layer) certificate to ensure the identity of the website.
HTTPS allows you to use the H2 protocol, which gives you several advantages. One of those advantages is a persistent connection for files in the same server, removing the need to establish a connection for each file. Unlike HTTP/1.1, it also allows the transfer of several files at the same time, so even though it might seem otherwise, having an SSL certificate on your website is going to make it load faster.
HTML Download and Processing
The first thing a browser downloads when opening a new website is the HTML code. To measure the initial response time, there is a measurement called TTFB (Time to First Byte), which tells you how long it takes from the HTML request until the first data is downloaded.
If your Time to First Byte is too long, look into connection, file size, your Server Size Render time, database queries, and server resources. All of these can drain the speed of your HTML download.
The main resources in this first download are channeled into creating the Document Object Model, which matches the content structure of the website. This thread includes tasks like running Javascript, creating the page layout, and much more.
If you want to reduce the time it takes for these resources to download, use minification (which reduces white space in the code and removes unnecessary characters) and compress your files to make them lighter on the CPU of the device that’s being used.
After the HTML download, new connections will be generated that lead to other files that have to be downloaded as well. This includes CSS, images, and fonts used in the website. What happens here is that each file in your HTML is going to reference other files, creating a network of actions and downloads that build up the whole website.
It is now a best practice to use the same server for requests when it is possible in order to make those downloads faster. This means self-hosting as many resources as possible. However, there are advantages to caching some files, such as fonts, which might be used across several websites.
If you’re using another server, you can use Preconnect or Prefetch. Preconnect allows you to make the connection to that other server faster than it would normally happen so that those resources are downloaded at the same time as the HTML.
Prefetch refers to establishing the DNS connection earlier, and it is said to have better support than Preconnect. Both are frequently used in modern website development, but Preconnect is recommended if you know there is a specific resource that needs to be downloaded first for your website to work properly. Remember, however, that Preconnect is going to require more resources at the beginning.
Page Render
The process through which the browser renders your website is called Critical Rendering Path. This process mixes HTML, Javascript, images, fonts, and CSS. CRT goes through five steps:
the DOM parses the necessary HTML;
the CSS Object Model processes the CSS into styles, colors, object sizes, etc.;
the Render Tree is composed by the CSSOM and the DOM;
based on the Render Tree, all elements are processed forming the layout of the page;
pixels form shapes, colors, text, and images.
Now, to improve your page speed, you’ll want all these processes to happen as soon as possible. The CMS or the Javascript Framework (or both) defines which resources are loaded first and how they are loaded. There are a few metrics you should know about when it comes to painting your page image in a browser:
First Paint: when the browser renders the first object
First Contentful Paint: when the browser renders something (image, text, etc.) from the DOM
First Meaningful Paint: when the most important objects are completely visible.
Largest Contentful Paint: when the largest element above the fold becomes visible.
Visually Complete: when the page is visually complete.
Speed Index: measures how long it takes for each web page’s visual contents to load completely.
Cumulative Layout Shift: measurement for the stability of the layout and how much the elements move around during loading.
Loading CSS
The thing about page speed is that there is not a one-size-fits-all approach, so what works for one website might not work for another. Some of the methods you can use to improve your page speed are going to be more difficult to implement than others, so the best approach depends on your development skills and resources as well.
When it comes to CSS files, they cannot be displayed to the user unless they’ve been fully loaded. This means that you should save CSS files in the user cache to make them visually available faster.
Asynchronous CSS Loading
CSS files, by default, are render-blocking: which means that, as mentioned previously, they cannot be shown until they are fully loaded. So, you want those CSS files to not block the render.
A way to do this is to implement the stylesheets you want to load first using a different format as if they were going to apply only to the print version, as an example, and once they’re loaded, apply them to the online content. This tricks the browser into loading some elements earlier than they were supposed to.
This technique can be used for all your CSS. However, remember that it might create some flashing as the elements change position and shape once CSS is applied.
Inline
Inline makes your content load together with the initial HTML file, by taking essential bits of the CSS and Javascript, and adding them to the HTML file. This makes the HTML file a bit slower to load but will deliver content faster.
This method does have an impact on other factors, though: the main issue being caching. Since the CSS code is inside the HTML file, the browser is not able to save the elements, which makes them load twice. However, for advanced users, it is possible to use inlining and caching at the same time.
When using inlining, you can minify your CSS as well to make it easier to load. You shouldn’t inline all your CSS, though. Leave that for elements you need to load first.
There’s also the possibility of inlining critical CSS at scale. This can be done with the help of a plugin, package, or module according to the CMS you’re using. It’s easy to find tutorials or instructions for critical CSS as well. As an example, This is our favorite for WordPress.
Preload
As an alternative to inline critical CSS, you can also use Preload. This technique fetches the essential resources to load the page faster than it would otherwise.
Browsers establish a priority for each resource when loading a page. What Preload does is to change that priority, making elements above the fold load faster and delaying other elements that are going to be needed later in the process. Loading using Preload also removes render blocks, making those resources load asynchronously.
Preload should usually be used together with asynchronous use of CSS so that it will work even for browsers that do not support preload.
Which files should you Preload?
Usually, you should load the theme file first. However, if you’re not sure if that’s all you need (or don’t know how to figure out which file includes the theme), you can use Chrome Dev Tools to request that each file be blocked.
If you block a file from rendering and the page still loads just fine, you don’t need to Preload it. However, if the page breaks when a resource is blocked, that’s a sign you should use Preload to load it faster.
You should also know that Preload might cause your fonts to be downloaded twice, so you should use cross-origin on any fonts needed. Normal file calls for CSS and Javascript should not be deleted.
If you need a font that is in a different CSS file, you can do it using Preload. However, remember: do not Preload too many files, as that might cause loading issues.
Server Push
This is one of the benefits of HTTP/2. Remember that we mentioned you needed HTTPS to get HTTP/2? We have another reason why you should use HTTPS: using HTTP/2 allows you to load files that weren’t requested. What server push does is to alter the chain from HTML to CSS and fonts (example), allowing you to jump a few steps.
Server Push is not recommended unless you’re really sure of what you’re doing, as it can cause serious issues if not used correctly.
Loading Javascript
One of the most common sources of error in Javascript is the fact that it uses dependencies. This means that some resources are needed in order to load others. Changing the loading order might affect how a page is painted.
Many of the options you have for CSS also apply with Javascript, such as Inline and Preload. Javascript does have its own intricacies, such as Server Side Rendering. SSR creates a snapshot of the code through a quick render and is highly useful in selecting the resources you’re going to use.
To find out if you need Javascript for your website’s primary functions, use Site Settings in Chrome to Allow or Block JS. If your page breaks when Javascript is blocked, you should use SSR to load it faster.
There are other things you can do to improve your Javascript parsing, and we’ll go through those now.
Move Inline Scripts to the Footer
Javascript uses parsing blocks, which prevent essential HTML from being loaded. If you move your scripts to the footer, you can ensure most of the page loads before those blocks occur. For script references, we recommend using defer and async.
Defer and Async
You can use either defer or async with script tags. While downloading and running a script, parsing is blocked. Async will allow parsing and downloading at the same time, but will block while the script is being executed. Defer, on the other hand, only executes the scripts after HTML is parsed, but does not block parsing during the download as well.
Responsive Design
To measure the responsiveness of your website, use First Input Delay. FID measures how long it takes between interaction with your page and the response. You can also use Time to Interactive, which measures the time needed for a website to become fully responsive. There is a single thread in which Javascript is also competing for resources, which means you might get a delayed response when the thread is blocked. Users notice this delay, which affects your user experience. This is usually caused by Javascript running.
Third-party Tags
Tags and their scripts might slow down your Javascript loading, as they block other resources from loading while they’re running. We advise checking how long is the main thread blocking time of all the third-party tags you use to determine if the information you get from them is worth the time they add to loading your website.
Javascript Cleanup
There are quite a few things you can do to reduce the so-called “Javascript bloat”.
First of all, reduce the amount of tracking and scripts in use. Some trackers collect a lot more information than you’re ever going to need.
Try to reduce systems with the same functionality. Each program has many functions, and sometimes there’s an overlap. If you’re using two systems for the same function, your website is wasting resources.
Define which areas of your website are going to be affected by A/B testing. If only one or two pages are testing, there is no need to have the tracking running on all pages.
Consider using server-side tracking rather than client-side. There are a few tradeoffs for this method but we believe they are worth the benefits you get.
If you don’t need a resource from the beginning, let it load later rather than sooner. We recommend saving the priority for the resources that you really need to load, and if you have some resource that requires interaction from users, do not load it until users request it.
How JS Frameworks Improve Your Website
By Javascript Frameworks we mean the likes of Vue, Angular, and React. These have the following benefits:
They allow your page to load only the resources needed, rather than loading all dependencies. This is called tree shaking and requires that the users interact with the page to load more resources.
They allow splitting your larger files into smaller chunks. This ensures interactivity to flow since files that block other functions become smaller and take less time to load. In the periods between those smaller downloads, website functions can work perfectly.
Loading Fonts
Our main recommendation to make your fonts load faster is to use font-display: swap. This makes the text content load in a default system font until the proper font is ready to be displayed correctly.
Loading Images
Even though images do not block other resources from loading at the same time, we recommend using images in the right size for each device and not using images that are “too heavy”. This means using images that are not only smaller in terms of size but are quick to load as well. Very large images might take away bandwidth that could be used to load more important resources.
When designing for mobile, you can remove background images that only make your website heavier. Images are rarely ever needed for your pages to look good or to be easy to understand.
Other than that, you should refrain from having large images above the fold, since that will only add up to your Time To Interactive.
Lazy Loading
Lazy loading has been added to WordPress as a default, but it requires a bit of work still. You can easily learn how to do it, though. Lazy-loading images means that, at first, only the images for above the fold are loaded. As the user scrolls down, the rest of the images are loaded.
Responsive Images
It’s important to remember not to have large images being resized after they load on smaller screens. Responsive images should be implemented from the ground up so that your website loads easily in every device.
Page Size
The page size combines all the resources and gives them a specific weight. We have already mentioned how to reduce this weight: minification, compression, and removing useless tracking and anything on your website that is not needed.
You can find out how much it cost to visit your page around the globe using What Does My Site Cost. The heavier the page, the most expensive it is.
Other Possible Improvements
There are other things you can do to improve your page speed that we haven’t mentioned so far. We’re going to list a few:
Server Cache: when a website loads, its contents are obtained from the server cache. You should hit a balance point between having the most content cached and allowing your website to update according to the latest changes. That’s why we recommend using a cache warming system: this sends a bot that rebuilds the cache quickly with every change allowing the cached content to be distributed without a user request.
Browser Cache: if you store some website content in your users’ devices, it’s easier to load faster when each user goes back to your website. This is called browser caching and makes your website load a lot quicker on a second visit. It does not affect the first load, but it makes the second and the next ones a lot faster.
Adaptive Loading: it picks which resources are going to be prioritized and which ones can wait. The main features are downloaded first, while other resources are left to load according to the device’s CPU and network speed. If the device used is weaker, the design is going to be a stripped-down version of the original; if you’re able to use all resources, they’re going to be shown.
There are other resource hints you can use, such as prefetch and preload. In this case, prefetch is going to load the page that’s most likely to be next according to Analytics data. Preload can load resources when users hover over links, rather than waiting for a click. There is also AMP, which loads while users are still in the SERPs. This gives new visitors the impression that the page loads a lot faster since the visible resources are loaded before they navigate to the actual page.
How to Check Page Speed on SERPed.net
If you use SERPed, it’s quite easy to access a Page Speed report for your website. First of all, open Site Manager. Then, click on SEO Audit on the right. Once the SEO Audit is complete, all you have to do is click the Speed tab:
And there you go. Our Speed report is based on data from Google for better results and higher accuracy.
Wrapping Up
When it comes to Page Speed, there is no such thing as over-optimization. The only reason why you shouldn’t implement a specific change is when it requires too many coding resources to be worth the effort. As we mentioned, a few of the options we recommend in this article are difficult to implement, but it all boils down to the resources you have available and the expertise of the developer that’s implementing the changes to the code.
If you are building a website from scratch, we recommend using these techniques from the beginning so your pages will have a better performance straight away!
The post Page Speed – Step by Step Guide to Speed Optimization 🔥 appeared first on Serped.com.
Source: SERPd
Link: Page Speed – Step by Step Guide to Speed Optimization 🔥
