4 Speed ​​Audit Quick Wins

We all know that speed is money.

A faster website converts better, which translates into improved revenue.

Despite the direct impact of speed on the bottom line, it can sometimes be difficult to get recommendations for performance improvements due to the frequent need to edit legacy code that can compromise the structural integrity of the site.

This is especially true for improving the performance of JavaScript.

While the flexibility of JavaScript makes it easy to use when coding functions, the same flexibility (a dynamic and loosely typed language) makes it difficult to maintain.

One of the common requests made by customers and developers is to prioritize performance improvements based on simplicity and required resources (due to development time constraints).

This can be very difficult to determine, especially if you are not a developer and do not have a full view of the site back end code.

To get around this, I’ll sort my list by activities that I know will require minimal changes to the site code.


Read on below

In this article, I’m going to highlight four of my most common quick fixes.

1. Remove third party tools, widgets, and web technology

Most websites are based on third-party technology for tracking, monitoring, customer support (chat functions) and much more.

The challenge with third party technology is that it typically runs on your site with code that you have no control over and therefore cannot improve performance.

The number of third-party scripts loaded on a page can affect page performance because the scripts come from different domains.

To understand this, you first need to understand what happens when you access a web page.

When accessing a web page, the browser finds all resources for which a DNS (Domain Name System) search is required.

The browser will then have to wait for the search to finish before starting to download the page.

This event depends on the origin server responding quickly.

When the server responds, the code must be read and understood by the browser and then delivered to you.


Read on below

Although this event can last milliseconds, multiply this by the number of searches the browser needs to perform and then provide a slow server response time for one of the domains looked up. However, these milliseconds increase to seconds.

The question here is why are you carrying dead weight when you don’t need it?

As part of my audits, I always review the amount of third-party technology that is being used on a site.

The easiest way to do this is by using technology lookup tools like BuiltWith and Wappalyzer (several other paid and free tools can be used to do this).

These tools are useful when you need to make a simple decision to keep or delete.

However, if the technology is still in use and you need to evaluate the benefits of maintaining it versus the impact on site load, you should use diagnostic tools such as the Page Speed ​​Insight Tool and Lighthouse to highlight the performance impact.

If you’re more tech-savvy, you can use Chrome’s development tools to block network request blocking to see how fast the page loads if a particular script or resource doesn’t load.

Another good tool for visualizing loading activity is the RequestMap from webpagetest.org.

This report provides a visual representation of the size of assets carried by bytes using Chrome request data.

I use this when introducing the effects of external technology to C-suites who don’t know anything about coding.

The older the site, the more likely it is to find external code that is no longer used.

I’ve found:

  • Scripts for chat boxes that are no longer used.
  • Different versions of widgets for consent to cookies.
  • Ad tracking pixels from software that is no longer used.
  • And, worst of all, using an external social share button widget when a CSS button would.

These scripts are easy to remove as they do not compromise the overall integrity of the rest of the code on the site.

Alternatively, if you need to keep these scripts, move as many as are supported to Google Tag Manager (GTM) or whatever Tag Manager you are using to reduce the number of DNS searches the browser does.


Read on below

Check the Tag Manager scripts regularly to remove unnecessary scripts.

You can also use the Window Loaded Trigger in GTM to delay the loading of unnecessary scripts once the visitor lands on the page until the page is completely loaded.

2. Implement DNS Prefetching & Preconnect

DNS prefetch and preconnect are notes on browser resources that can be used to speed up the DNS search.

Browsers typically wait until they need a resource before attempting to request the origin of that resource.

While this resource is being requested, the entire page will stop loading until it is resolved.

DNS prefetching is a way to get the non-critical resource origin before it is needed and to speed search time by giving the browser a head start.

You can preview third-party widgets that appear at the bottom of the page, such as: B. Chat boxes, social share buttons, poll widgets, etc.

Chrome Dev Tools JavaScript console window

Preconnect is also used to make an early connection, but should be used for resources that are critical to the loading of the page, such as: B. Assets hosted on networks for content delivery, web fonts, etc.


Read on below

3. Use a single JQuery library whenever possible

Some third-party scripts come with a jQuery library.

For laypeople, jQuery is a JavaScript library that simplifies the use of JavaScript functions.

Most modern websites have some form of JavaScript so a version of jQuery is already loaded on the website.

It is a waste of resources to have two versions of this library on your site when you only need one.

When loading an external script, always ask for a version that the version of jQuery won’t load.

Your developer can then set the script to use the global version that loads on your site.

Don’t forget to test that the script you are loading is compatible with the version of jQuery on your site.

Use the Chrome Dev Tools JavaScript console window to see what version or versions of jQuery are loading on your site.

Enter Ctrl + Shift + J to open the console, then enter console.log (jQuery (). jquery); in the command line.

Chrome Dev Tools JavaScript console window

Yellow Lab Tools has a simple interface for checking jQuery versions.

Yellow Lab Tools jQuery result

Other ways to reduce the impact of loading jQuery files are to use the latest version and make jQuery available through Google’s hosted libraries.


Read on below

4. Remove redundant CSS statements for legacy browser support

The older the website, the higher the number of crimes.

Removing redundant CSS directives like old browser support (IE fixes) and old prefixes is easy as it is usually a separate block of code.

Many tools mark unused CSS on a site.

Instead of having to search the code line by line for the old prefix and browser support, Yellow Lab Tools gives you an easy-to-understand list that you can make available to your developer.

Yellow laboratory tools - result of old prefixes

Make sure you check your tracking tool to see how many visitors are still using those old browsers and if the number warrants you to keep support.


Read on below


There are many amazing technologies out there that are improving the way we target and track visitors to our website.

While speed will always be a top concern, delivering the best user experience will always be a top priority.

By regularly reviewing your external scripts, you can provide your visitors with the best possible experience in the most efficient way.

More resources:

Photo credit

All screenshots by the author, October 2020