Along with images, CSS and JavaScript are two of the most common reasons for code bloat and slow loading pages. Sometimes (although not often) this is unavoidable, and the functionality and design of a page requires a lot of code however there is nearly always room for improvement. Users don’t like waiting for a page to load and search engines know it. You should try and improve page speed however you can.
It is particularly frustrating to see pages where large portions of the scripts being called by a page are redundant and not actually being used for anything. This can happen for a number of reasons including those listed below:
- Scripts being called in the head section of a template that are required for some pages but are being called for every page on the site.
- Scripts and styles that are only used when a certain part of the page is interacted with such as tabs, accordions, faceted navigation.
- Cruft that has built over time where additional functions or styles have been added over time without reviewing existing code to see whether it can be modified to fit newer requirements (Dawn Anderson recently talked about the concept of generational cruft)
- Installation of Plugins / addons for a CMS where only a small subset of the functionality offered is actually required.
- Poor coding.
There are many other reasons for why unused code can build up, but these are some of the common ones. You can read more on this topic here
How do we Identify What is and Isn’t Being Used?
There are various methods for identifying unused code including browser plugins, custom built testing scripts, third party libraries etc but there is also a really simple and handy way to do this right within Chrome Developer Tools which is the option we will be looking at today.
The first thing to do is open the page you want to examine in Chrome and then press F12 to bring up developer tools. Once you have the Chrome Developer Tools window open, hold CTRL + SHIFT+ P to open up the filter bar shown below
It shouldn’t matter which tab you are in (Elements, Console, Sources etc) the filter should still open. In the filter box you should type coverage which should bring up the options shown below
You should select the first option which is Draw Show Coverage which should bring you up a couple of panels as shown below
In either of the panels click the reload button which should refresh the page and start populating the bottom panel with data as shown in the example below.
In addition to the URLs of all scripts loaded on the page (not shown here but would normally appear on the far left) we also get the type of script, the Total size of the file and the Unused Bytes. The bar on the right hand side shows the split between used and unused code with the red portion showing a visual representation of the percentages.
At the bottom left of the screen you will also see the total percentage of code loaded on the page that isn’t being used.
As you can see from the example above, of 2.3 MB of CSS and JS 1.5 MB or 64% is not being used on this particular page on initial load. By clicking on an individual row in the bottom pane you can also see the specific blocks of code that aren’t being used in the top page.
It is also possible to get this information using Headless Chrome and Puppeteer. You can find out more about this here This is a more complex approach but much more scalable if you need to get data in bulk. We will talk more about this approach in a future post.
What do I do With This Information?
Whilst it’s exciting to think that huge savings can be so quickly and easily achieved it’s important to remember some of the points mentioned earlier and not just dash off and tell the dev team to remove all of the highlighted code (hopefully they would say no if you did this anyway!)
To get an idea of the impact of scripts not being available you can test on a per page basis by blocking resources and then interacting with the page to identify UI issues. You can find more information on this here
Below we will discuss some of the ways that you can use this information to improve coding efficiencies on your site.
Defer Non-Critical Scripts and Styles
Aside from removing completely redundant scripts, one of the other common reasons for identifying code that is not used on initial page load is to minimise render blocking code that doesn’t actually do anything until a user interacts with the page. Examples previously mentioned include things like accordions, tabs, search functionality etc.
Tools such as Lighthouse highlight both render blocking scripts and unused CSS but return the file names rather than the specific parts of the script that unused however it may well be that parts of a script are required for the initial render and some are only used upon interaction.
By looking at a more granular level it may be possible to split code up into that which is parsed at the start of the page load process and unused scripts and styles that can be deferred until after the above the fold content has loaded.
Use Different Templates for Different Types of Pages
Many sites include references to all external scripts on every page of a site which is often the reason for unused code. As an example, an e-commerce site might be loading all of the scripts and styling for product listings, search results, shopping baskets etc on the home page and other unrelated pages.
In such cases, we recommend having different templates for each part of the site to ensure that only the required functionality and styles are loaded at any time. Another alternative may be to use Google Tag Manager to conditionally inject script references based on a selector on the page however this is often not the best approach and a template based approach is normally preferable.
Use Custom Builds of Script Libraries
Use of third party libraries such as JQuery and BootStrap is another frequently causes code bloat. Sites frequently load the full library when they are only using a small subset of the functions available.
There are a number of options available for building custom versions of these libraries to minimise the amount of unused code that is included. You can find a BootStrap customizer here and a jQuery builder here and a jQuery UI builder here
You should also consider whether you really need to load an external library at all. The greatest savings can sometimes come from using simple custom solutions.
