Technical Cleanup

Why sites accumulate weight

Every new feature, plugin, campaign and redesign adds files. Very few changes take files away. web.dev's guidance on tags observes that tags tend to accumulate over time and recommends labeling each one with an owner and reviewing them regularly ^[1]. The same is true of the site's own code. Cleanup is the work of finding what is still loading and asking whether it still needs to.

What we look for

Unused CSS and JavaScript

Page builders and themes often ship styles and scripts for every component on every page, whether the page uses them or not. We measure how much of each file is actually used on key templates, then split, trim or conditionally load files so pages carry only what they need.

Render-blocking files

Stylesheets and synchronous scripts in the head block rendering until they arrive. This is one cause of a long element render delay, the last of the four LCP subparts web.dev describes ^[2]. We inline the small amount of CSS needed for the first view where it makes sense, defer scripts, and remove anything blocking that is not required.

Duplicate and outdated libraries

It is common to find two versions of the same library, or a large library loaded for a single small feature. We replace or remove these where it is safe to do so.

Fonts

web.dev's font guidance makes the point well: "The fastest font to deliver is a font that isn't requested in the first place" ^[3]. We reduce the number of families and weights, use WOFF2, subset where the license allows, preload the one or two fonts that appear above the fold, and choose a font-display setting that suits the design ^[3].

Layout shift sources

Cleanup often uncovers banners, cookie notices and embeds that push content down after it has appeared. We reserve space for them or change how they load, following web.dev's advice on layout shift causes ^[4].

Back-button speed

Some old scripts use the unload event, which can stop pages from using the back/forward cache. web.dev advises never using the unload event at all, and recommends pagehide instead ^[5]. We check for this and fix it where we find it.

How we keep it safe

Removing code is where speed work can break things. We work on a staging copy, change one group of files at a time, and test the features those files support: menus, forms, search, sliders that remain, tracking and consent. Every change goes into a log with the file, the reason and how to undo it. Nothing is removed without a reason we can explain to you.

What you receive

• A list of what was removed, delayed or replaced, and why.
• Before and after measurements of page weight and script execution time on each template.
• Notes for future work, such as which components are expensive and how to add new ones without repeating the problem.

When cleanup is not enough

Sometimes the theme or page builder itself is the problem, and trimming around it only goes so far. If that is the case, we will say so, explain the options, from a lighter theme to a partial rebuild of key templates, and give a rough sense of the effort involved. We will not recommend a rebuild without evidence that cleanup cannot get the site where it needs to be.

A typical cleanup, illustrated

Consider a fictional site built on a multipurpose theme. The home page loads 14 stylesheets and 19 scripts. Measuring coverage shows that only a fraction of the CSS is used on that page. Two plugins each load their own copy of the same carousel library. An icon font with hundreds of icons is loaded to display six. A testimonial slider was removed from the design last year, but its script and styles still load on every page.

The cleanup combines stylesheets that are always needed, loads component styles only where components appear, removes the duplicate library, replaces the icon font with six inline SVG icons, and deletes the slider's leftovers. Each step is small and tested on its own. The page looks the same afterwards; it simply asks the browser to download and process much less before it can render.

Cleanup and Core Web Vitals

Cleanup work affects all three metrics. Fewer render-blocking files shorten LCP's element render delay ^[2]. Less JavaScript on the main thread helps INP, and Google lists avoiding unnecessary JavaScript among its top INP recommendations ^[6]. Reserving space for late-loading banners and embeds reduces CLS ^[4]. Because the gains are spread across metrics, we measure all three before and after each group of changes.

What we need from you

Access to the site's code or theme files, a staging copy if one exists (or permission to create one), and a list of features that must keep working. It also helps to know about any planned redesigns, since there is little point cleaning up a template that is about to be replaced.