In this post, I'm going to share the secret ingredient that isn’t being talked about enough, and it was fundamental in helping Tribe SEO score a perfect 100% Google PageSpeed score.

And yes, that’s from a mobile device and for a rich media webpage that contains lots of videos and images, as well as plenty of text.

Now, before I reveal the hidden ingredient, there are a few technical bits I need to clear up, and I’ll make them as visual and as easy to understand as possible.

Server-Side and Client-Side Optimisation

In computer science terms, a device used to access the Internet is known as the Client. So, this could be your smartphone or laptop.

When you request a webpage from your Client, your web browser is served by the Server.

The Server or Web Server, if you like, is where your website is hosted. You can think of it as a giant computer that lives in the cloud and processes how your webpages look and function.

So, when a webpage is requested, HTML controls the display of the content, and CSS controls its appearance, so the look and feel part.

Now, scripting–both server-side scripting and client-side scripting–controls the function, so what content is being returned based on a user’s interaction with the Client.

Scripting can be thought as a type of programming language.

For example, JavaScript is typically run from a web browser, so it’s usually an example of client-side scripting.

However, PHP is an example of server-side scripting because it’s processed on the server.

So, why am I telling you this?

The “Hidden” Ingredient That Sets Fast Websites Apart

We all know the iceberg metaphor. Above the waterline is what is easily seen and understood, and below it what’s not seen.

For page speed and above the waterline, the more obvious things to optimise are images, content and having a fast web host.

But, below the line are the more technical things that happen in the background, like enabling compression, leveraging browser caching–but perhaps the most hidden and most significant of all is script optimisation. And that’s what we’ll focus on in today’s video.

Sever-Side Scripts

Server-side scripts are almost entirely hidden from the public because they run on the web server and are only available to web site admins and developers.

In the case of WordPress, which is the most popular content management system (CMS), it uses PHP as it’s a server-side programming language and MySQL to retrieve information from its database.

As with most CMSs, WordPress sites typically contain a theme, and some include a page builder to help with the design and layout of pages.

Now, it’s not uncommon for a WordPress website to use a couple of dozen plugins to extend its functionality. For example, Gravity Forms is a popular plugin used to collect website enquires.

But what do CMSs, themes, page builders and plugins all have in common?

They all generate server-side scripts that process calculations in the background, contributing to longer page load times.

While these examples are for a WordPress website, the same principles can be applied to almost all content management systems because they typically use server-side scripts to dynamically create content and interact with a database.

If you’re not careful with your choice of CMS, theme, page builder and plugins, you may end up with bloated code that makes unnecessary calculations in its script, which will slow your website down.

If we stick with WordPress for the moment. “Hello” is the name of a popular theme and made by Elementor, which is one of the most popular WordPress page builders.

Both the “Hello” theme and Elementor page builder are considered fast.

Although they are not the fastest because there is a trade-off between speed and ease of use.

Oxygen Builder is a bit differently because it’s neither a theme nor a page builder but serves the purpose of both.

In the case of the Tribe SEO website, Oxygen Builder was used because it has very lean code, which helps with fast loading webpages.

Client-Side Scripts

Client-side scripts are a little easier to detect than server-side scripts and are most typically CSS and JavaScript.

Here are some examples of some JavaScript use cases:

  • Live chat
  • Google Analytics
  • Email marketing and email capture tracking
  • Re-capture
  • Carousels
  • Ads

So, let’s look at BuzzFeed website.

Let’s suppose I want to know which scripts are run client-side, so on a user’s browser.

I simply grab BuzzFeed’s homepage URL and pop it into GTmetrix for a page speed test.

We can see Buzzfeed gets a GTMetrix D grade and a performance score of 59%. If I scroll down, I can see that the page is 2.82 MB and JavaScript contributes to roughly half of that at 1.32 MB.

Let’s investigate this further and visit the “Waterfall” tab.

The Waterfall tab can look a bit overwhelming at first, but it’s a fairly simple chart that lists, in order, all the file requests made from a web server to the browser. This includes every media file, text and scripts that make up a webpage.

If I want to review client-side scripts, I can either click the CSS or JS tabs. But, I’ll click the JS tab to see the JavaScript files first.

So, right off the bat, I can see there are a LOT of JS files.

I’ll click the “Size” column a couple of times to order the files by file size rather than the sequence they were loaded.

The left column is called “URL”, so you get an idea of what the JavaScript file is called. For Buzzfeed, it’s hard to make sense of the URL column, so let’s check out the “Domain” column instead.

You can see many of the scripts come from external domains like Doubleclick, Facebook and Google. All of these scripts, particularly the larger ones, can play a significant role in slowing a webpage down.

So, you either want to eliminate as many as you can or defer them to load after the more important elements of a page. More on how to do this in the following video.

How to Measure Server-Side and Client-Side Performance

Buzzfeed has a lot of client-side scripts, but is this a problem? And if so, how do we measure how much of an issue this is and for both client and server-side scripts?

Let’s start by switching back to the server-side first, and then we’ll cover the client-side.

Time to First Byte (TTFB)

The most common way to measure your server response time is through the Time To First Byte (TTFB) metric.

If you’ve been following along in this video series, you’ll know that TTFB measures the length of time between a Client making its request from a browser and receiving the first byte of data from the server.

There are a few ways to find this out. In the “Summary” section of GTmetrix, you’ll see the first metric reported is TTFB. We can see Buzzfeed’s score is 139 ms.

So, is this a good score?

Well, according to Google, yes, it is. Anything under 200 ms is good, while under 100 ms is excellent.

If your website scores between 200 and 600 ms, Google considers this ok but needs improvement. However, over 600 ms would fail Google’s page speed test.

So, we can conclude because Buzzfeed’s TTFB is 139 ms it’s client-side optimisation is in pretty good shape, so it shouldn’t be holding its page speed score back too much.

First Input Delay

To measure how your client-side optimisation is doing, we’ll use the First Input Delay (FID) metric which we cover in more detail in the next video.

Sticking with the Buzzfeed homepage example and GTmetrix, I’ll click on the “Performance” tab.

Hmm, it looks like the First Input Delay metric isn’t there. That’s because it’s a “field” metric recorded by Google from real-life users to a webpage. You’ll need to head over to Google’s PageSpeed Insights tool to get that metric.

But Total Blocking Time is an equivalent computer generated metric. GTMetrix scores Total Blocking Time as 845 ms and says it’s much longer than recommended.

So, it’s fairly safe to conclude that Buzzfeed’s slow homepage has a lot to do with client-side scripts and JavaScript in particular.

But here’s the thing. How your website handle scripts, both client-side and server-side, can make or break how fast your website loads.

In the following few videos, I’ll show what you can do to optimise scripts and improve your Google PageSpeed Insight score.

So, if you want to learn how to make your webpages faster and more interactive, be sure to hit the subscribe button and like this video.

If you have a question at all, pop it in the comments sections below.

That’s it from me, Joe Williams from Tribe SEO, and I’ll see you in the next video.