This week we continue with the second episode of our two-part masterclass on how to accelerate page load time and get ahead of the competition.

If there ever was a telltale sign that could point to a web creator’s level of professionalism, it is their attitude to speed. The need to shave milliseconds off of page load time, anywhere they can, is what sets the novice and the master apart.

In our previous Masterclass, we looked into ways that could help speed up the server process to send out our site data faster. In this article, we’ll see how we can speed things up along our platform — which in our case is WordPress, and look into ways to slim down our content without losing quality or quantity. 

How Site Data Travels Part 2

To figure out where we can trim and streamline our data, lets first understand how our site data is processed and sent to the user, at a deeper level.

Having received a request from a browser, or client, the server refers to the platform, examining its structure, reading through a long list of requirements, conditions, from WordPress, and then from all of the plugins and addons that are installed upon it. 

The server then takes all of this information and creates an initial response to the client’s request, containing an HTML file. This acts as blueprint, telling the client, or browser, what to do with all the site data, the graphic and text assets; how to reconstruct and render them for the user. This initial response also includes a list of assets, for which the client needs to issue requests separately.


How the server responds to these next requests, differs depending on whether or not the client is running on HTTP/1 or HTTP/2. For our intents and purposes, the difference is this:


If the client is running on HTTP/1, the client will issue a request for an asset. 

The server will respond by sending the requested asset to the client. The client will then ask for the next asset on the list, and so on.

When the client in question runs on HTTP/2, the server will wait for the entire list of requests for required assets to come through first, and only then will it respond by sending all of the requested assets in one bulk load. 

Yes, this makes HTTP/2 far more efficient, but unfortunately, there are still users around the world relying on HTTP/1, and many web-creators must build their sites with the global market in mind.

Page-By-Page vs Full Site Loading

One relevant aspect that came up in the comments was the debate on whether the server should be set to processes client requests on a page-by-page basis or whether it should send the client the entire site in one go. 

Obviously, if, as users, we only want to see that one page, loading all of the information for a whole site is redundant and a waste of time. However, if we’re on a site, such as an online store where we’ll want to move on to other pages, then loading that site on a page-by-page basis is going to get very frustrating very fast. 

As you know, there is constant and extensive research into current market trends. 

This same research points to the vast majority of users, preferring, or needing to view other pages on the same site they’ve visited.

Whether a server operates one way or the other, is defined at the platform level.

And as some of you pointed out, Elementor has the server ship the site data as a whole, rather than on a page-by-page basis. This is because the vast majority of web creators prefer it, 

because of the demands of their own clients. Because, this means that their users spend less time waiting for that new page to load, resulting in a faster, more efficient, user experience.

If the demand should change, Elementor will be only too happy to accommodate and adopt the new trends. Meanwhile, our job as web creators is to make the best site to suit the current climate and competition.

Mock up site based on the Photography Portfolio Template Kit

Auditing a Website for Page Load Time: Putting Speed Theory to the Test

As promised, this masterclass we’ll audit a site and show you just how all of our theory works in practice. The best way to learn how to get it right, is to work with an example of a website done wrong. For our experiment, we borrowed our recently released Photography Portfolio template kit and deliberately tinkered with it.

How to Speed up Our Site, Platform Side

Step 1: Run Initial Speed Test

Initial speed test using Google PageSpeed Insights
Initial speed test using Google PageSpeed Insights

Running a basic speed test using GT Matrix, or Google’s PageSpeed Insights will not merely show us how slow our example site is, it will also give us ideas of where and how to make the necessary tweaks to speed up our site.

What we’ll be doing next is reviewing why this site is so slow, and what we can do about it, beginning with speeding up our sample site, platform side. 

The two main concerns or reasons for speeding up our sites are:

  1. To ensure a better user experience. Reducing page load time reduces the likelihood of users getting frustrated and raising the bounce rate.
  2. To stay ahead of the competition.

We’ll begin by shaving time off of the processes that create that HTML file we mentioned. 

There’s very little that we can change on WordPress itself. And the server still has to read through all of WordPress’s definitions and guidelines. 

The good news is that WordPress is constantly improving things on their side to help speed up this part of the process.

The bad news is what comes next, when the server has to read through the list of definitions in the theme, plugins, and addons, to retrieve the similar data.

Yes, we are talking in mili-seconds but this is where each mili-second counts.

Step 2: Optimize to Superlite (Barebones) Theme

You’re probably aware of the growing ‘No-theme’ or ‘Theme-less’ movement among professional WordPress web-creators. 

Themes have a tendency to not only limit design possibilities and flexibility but also add unwanted time to the server’s process.

This is why the Hello theme has become so popular so fast. It is one of the lightest, most flexible themes out there. In fact, it’s so light, it’s practically invisible.


Step 3: Remove Redundant/Excessive Plugins & Addons

Next, we want to reduce the number of plugins that we have activated. Remember that the server reads through each and everyone, whether they are redundant or not.

In our example site, we’ve got separate plugins for a contact form and the popup menu. Plugins and addons that are already available on Elementor. Available because developers have gone to all the trouble of creating these as customizable widgets precisely to allow web creators to make their sites as fast and efficient as possible. 

Having fine-tuned our site platform-side, we want to make things easier for the browser or client.

And we do that by reducing, not the quantity, but the weight of our content payload.

How to Speed up Our Site, Content Side

Looking at the breakdown of our speed test, at what is commonly known as a ‘waterfall’ we’ll see that the heaviest files are our images.

Waterfall of speed test using Google PageSpeed Insights

Upfront, you should know that as early as version 4.5, WordPress automatically reduces the density of any JPEG assets that we upload to the media folder, which is great, but still not enough.

Many designers prefer to use graphic file types like PNG for vector art and images with transparency, which WordPress does not convert. But as we’ve mentioned in previous Masterclasses, there are a couple of great apps and online sites, like TinyPNG, Optimole, Pixlr X, etc. that can help us scale down images to a far more acceptable weight. 

While on the subject of images, there are two more things to consider when processing our graphic assets.

When it comes to size, a bigger picture will not give you better quality. 

If you have a graphic asset meant to fit in a four-hundred by four-hundred-pixel space, a twenty-four hundred by twenty-four hundred pixel image is a waste of weight. 

Instead, we should make sure that the images we upload to WordPress have the dimensions of the largest instance we will need, most likely for the desktop view of your site.

Step 4: Scale Images to Appropriate Dimensions and Resolution

Beyond that, WordPress does a pretty good job of creating several instances of the image, in varying sizes ready to be used in responsive mode. (It’s because of this that Elementor relies on the WordPress media feature for uploading and relaying images.)

We can see this happening in the code when we inspect an image in Google Chrome. 

Example of wordpress instances of image sizes

The next thing that affects the weight of an image is its resolution, which is measured in pixels per inch, or PPI; not to be confused with DPI which is a similar concept but from the world of printed graphics.

It used to be the case that 72 PPI was sufficient enough for all our graphic assets. Since then need to consider display formats such as 4K and Retina

So far we have less to fear or worry about from 4K. However, Retina, an Apple display system is prevalent on iPhones, iPads, iMacs, and MacBooks. That’s a lot of users that we need to consider when designing our sites. 

TOP TIP: Keep image resolution at 300ppi

The pixel density of Retina technology differs from one device to another. Experts used to recommend sticking to at least 220 PPI to accommodate this. But with this number creeping upwards, many are currently adamant that all of our assets are at least 300 PPI.

TOP TIP: Use short videos instead of GIFs

While GIFs are a very popular asset to use in our design, a great tip is to use short videos instead. As they aren’t as heavy as GIFs, especially when we use linked Video widgets

Step 5: Use Caching/Lazy Load

In previous Masterclasses, we’ve spoken about “Lazy Load” and “caching” plugins. These are not redundant plugins. In fact, they are extremely useful for speeding up page load time. 

The way lazy load plugins work, in layman’s terms, is by keeping the major assets a ‘secret’ until the client needs them. When the server sends its initial response, the HTML that the client receives has placeholders instead of a reference to an asset. This way, the client isn’t waiting to receive these assets before rendering the page for the user.

As such, Google will also be clocking the Page Load Time as though the site is already complete. This not only means that the user doesn’t wait too long to see the site but Google assumes that the site loads much faster than without the app.

As the user scrolls down the page, the missing assets are transferred as needed from the server, wthout the user having to waste any extra time waiting. 

LazyLoad by WP Rocket

Like many of you, we recommend WP Rocket to get this job done.

Step 6: Remove Redundant Structure Elements

We’ve spoken about this and more, in our Masterclass on common mistakes, but there’s a chance that as Elementor users, you’re overloading your page with redundant and unnecessary elements. 

You’ll want to use as few columns, sections, and empty widgets as you can.

I personally, begin by trying to keep an entire page in one section. Admittedly, this is not an easy task, but reducing the number of sections by any amount is a good professional practice.

You’ll want to avoid using external scripts for things like ads, font loaders, etc. that can have a huge impact on your website’s performance. This brings us to another concept that you’ve been bringing up in the community, and that is Minification.

Step 7: Minification

Minification refers to the process of clearing up all of the redundant content, excessive HTML, and space, which also take up room. 

Apps like Kangax HTML Minifier, or Minifier, are tools designed to identify and remove redundant and convoluted HTML, JavaScript and CSS code, significantly reducing the weight of our site data reducing the site’s functionality.

Step 8: Re-Run Speed Test

Once we’ve cleaned up and streamlined our site, we’ll run a test using GTmetrix, Google, or TestMySite to test your page’s desktop and responsive loading time alongside industry benchmarks and give us scores based on real-world data on user experience.

This is yet another way we can learn what is slowing down our site and how we can make our user experience better.

Final speed test using Google PageSpeed Insights

Some of you have recommended using the Impact Calculator to estimate the potential loss or gain of revenue according to the current speed of our site.

The speed we’re looking for is 4 seconds or faster.

Based on extensive research by companies like Google who have vested interest in understanding what online users want, getting our Page Load Time down to 2 seconds would be wonderful. 

But for really big sites, like online stores anywhere between less than 4 seconds is great, 7 seconds or less is not brilliant but still a pretty good speed.

Another great way to evaluate our site’s performance is by using Speed Scorecard to see how our mobile site speed compares in different locations within the geographic regions we’re targeting, in countries around the world. 

Another idea is to compare your Page Load time with that of your competitor’s sites. Even if you can’t get your load time down, you still want to be faster, and more reliable than the competition. 

Balancing Great Speed with Great Site Design

Beyond everything we’ve examined, it’s important to remember that there is no perfect solution for speed. 

It boils down testing and retesting, and above all, finding the balance between what we need our site to deliver and how fast we get it there.

As web creators, sometimes our mission is to blow our audience’s minds, but sometimes we’re risking speed. But this is precisely where creativity and ingenuity thrive — within limitations.

Designing & Planning for Speed

A great deal of what we’ve discussed should be implemented, or at least discussed, at the design stage. 

As regular readers, you probably recall us stressing the importance of the planning stage, time and again, and planning for speed is essential to a website’s design.

On the subject of design, you might want to consider Minimalist design, which is not only fashionable but has proven to be very functional. And something that we plan to examine in a Masterclass in the near future.

Some of you might have noticed that in this masterclass, there were some issues that we haven’t discussed, such as throttling, and other topics that we felt would be better addressed in a later, separate, expert-level masterclass that we have planned for the future.

Also, since releasing part 1 of this Masterclass on speed, we’ve been enjoying your comments and really great insight. So please, if you have any further advice or tips that could help other users speed up their websites, please share it in the comments below.

If you have any criticisms, we are equally interested in your thoughts.

After all, our goal is to be the best at helping others excel at their craft.