10 Things You Can Delete From Your Website Today

The median web page in July 2025 shipped 697 KB of JavaScript on desktop and weighed 2.86 MB in total, according to the HTTP Archive Web Almanac. Of that JavaScript, the median page never ran 280 KB of it. It downloaded it, parsed it, and then sat on it.

That last number is the interesting one. The average site is not slow because someone built something ambitious. It is slow because it is carrying things nobody decided to carry. A widget from a campaign that ended. A library loaded for one line of code. A font weight that appears nowhere in the design.

The cheapest way to remove website bloat is to delete it. No refactor, no migration, no rebuild. You remove a thing, the page gets lighter, and nothing breaks because nothing was using it. This is a list of ten of those things, with what each one actually costs and what to do instead.

Some of these will not apply to you. The point is that four or five of them probably will, and you can be done with all of them before lunch.

Want the printable version? Download the complete guide as a PDF — 9 pages, all ten items with the numbers, the checks, and a ten-minute audit, no login required.

1. The Homepage Carousel

Erik Runyon published click data from the University of Notre Dame's homepage carousel back in 2013, and it is still the most quoted number in this argument for a reason: just over 1% of visitors clicked the carousel at all, and of those who did, about 84% clicked the first slide. Slides two through five were splitting a rounding error.

The cost is not only attention. A slider ships a JavaScript library, usually its own stylesheet, and four or five hero-sized images that all load whether or not anyone sees them. On a typical WordPress build that is 60 to 150 KB of script and CSS plus several hundred KB of images that exist purely to rotate past.

How to check: open your analytics and look for click events on slides two and up. If the carousel has no event tracking at all, that is the answer. Nobody has ever looked, which means nobody has ever cared.

What to do instead: keep slide one. That is what people saw anyway. Make it a static hero with one headline and one button. The other slides usually contain things that deserve their own section further down the page, so move them there where they can be read instead of glimpsed.

2. The Live Chat Widget Nobody Answers

DebugBear measured the popular chat widgets and found the heaviest ones load 500 to 750 KB of JavaScript. A separate test of ten live chat tools by CueForGood clocked script parse and execution time between 129 ms and 820 ms depending on the vendor. That is main thread time, competing directly with the browser responding to a tap.

Here is what makes this an easy delete. Most small business chat widgets are not staffed. They were installed during a growth push, someone answered messages for three weeks, and now the widget collects "hi is anyone there" at 2am and sends it to an inbox nobody reads.

How to check: look at the vendor dashboard for conversations in the last 90 days, and separately, your median first response time. If the answer is "a handful" and "eleven hours", you are paying half a megabyte for a worse experience than a contact form.

What to do instead: a phone number and an email address in the header, or a plain form. If you genuinely staff chat, load the widget only on the pages where conversations actually start, and load it on interaction rather than on page load. Most vendors document a manual init for exactly this.

3. The Third Analytics Tool Nobody Reads

GA4 through Google Tag Manager, plus a heatmap tool, plus a session recorder, plus whatever the last agency added. Each one is a separate connection, a separate script, and separate main thread work. The Web Almanac's 2025 third parties chapter found that over 90% of pages include at least one third party and that the median third-party inclusion chain is three deep, meaning the scripts you added are loading scripts you never chose.

Session recorders are the worst offenders. They listen to mouse movement, scrolls, clicks, and DOM mutations on every page for every visitor, forever, so that you can watch nine recordings once.

How to check: list every third-party script on your site and write next to each one the name of the person who looked at its data this quarter. Any script without a name gets deleted. It is the fastest way to remove website bloat I know, and it is brutal in a good way.

There is a second reason to keep this list short. Every third-party script is code you did not write executing on your domain with full access to your pages, which is the same risk surface I wrote about in Your Website Is One Compromised npm Package Away From Disaster. Fewer scripts is fewer things that can turn hostile without you noticing.

What to do instead: pick one analytics tool. If you need heatmaps, run the tool for two weeks, get your answers, and remove it. Heatmap data is a study, not a permanent installation.

4. Tracking Pixels for Campaigns That Ended

Meta's pixel, a LinkedIn Insight Tag, a TikTok pixel, a Google Ads remarketing tag, and one from an affiliate program that closed in 2023. Each of these is typically 50 to 200 KB of script plus its own network requests, and they are the classic thing nobody removes because nobody remembers installing them.

The compounding problem is that they usually fire through Tag Manager, so they are invisible in your theme files. You can search the codebase all day and find nothing, because the tags live in a web interface someone else set up.

How to check: open Tag Manager, sort your tags by last modified, and look at anything older than a year. Then check the ad platform itself. If a pixel is receiving events but no campaign has spent money in twelve months, it is collecting data for nobody.

What to do instead: pause the tag rather than deleting it if you are nervous, confirm nothing broke for a week, then delete it properly. Keep pixels only for platforms where you are actively spending. When you restart a campaign, you re-add the tag. It takes four minutes.

5. jQuery, Loaded for Two Selectors

jQuery is roughly 87 KB minified and about 30 KB over the wire compressed, and on a very large number of sites it exists to support a mobile menu toggle and a smooth scroll. Both of those have been native for years.

$('.menu').toggleClass('open') is document.querySelector('.menu').classList.toggle('open'). $.ajax is fetch. $(document).ready is a defer attribute on the script tag. These are not clever workarounds any more, they are just how the platform works.

How to check: search your theme and custom JS for $( and jQuery(. Under thirty hits, this is an afternoon. Three hundred hits, leave it alone, this list is about easy wins.

The caveat is real: on WordPress, plugins may depend on jQuery even if your theme does not, and dequeuing it will break them silently. Check the plugin list before you touch anything. I went through the same exercise with plugins in 20 WordPress Plugins You Can Replace With a Few Lines of PHP, and the same rule applies: verify the dependency before you remove the dependency.

The same logic covers animation libraries. Most sites load one to do a fade and a slide, both of which CSS does natively, which I went through line by line in Every JavaScript Animation Library You Can Replace With 3 Lines of CSS.

6. Four of Your Six Font Weights

The Web Almanac put median font weight at 139 KB per desktop page in 2025. That is usually two families at three weights each, or one family loaded in Light, Regular, Medium, SemiBold, Bold, and Black because the Google Fonts embed code offered them all and nobody unticked anything.

Open your stylesheet and grep for font-weight. Most sites use two values. Each unused weight is a separate file, a separate request, and another chance for a flash of unstyled text.

How to check: in Chrome DevTools, open the Network tab, filter by Font, and reload. Count the files. Then compare that count to the number of distinct font-weight values in your CSS. The gap is your delete list.

What to do instead: two weights, one family, in WOFF2, self-hosted with font-display: swap and a preload on the one used for your largest text. If you want a third weight for headings, use a variable font, which ships one file and gets you the whole range.

7. Half of Your Cookie Banner

DebugBear's testing of consent platforms found real damage from the heavier ones, including a case where LCP went from 1.43 seconds to 3.61 seconds because the banner text became the largest contentful element. OneTrust alone ships upward of 184 KB of JavaScript. Cookiebot's script is around 34 KB and loads synchronously.

Here is the honest question. Does your brochure site with a contact form and GA4 need an enterprise consent management platform built for ad-tech companies running dozens of vendors? Usually not. You are running the compliance machinery of a business model you do not have.

I am not a lawyer, and if you are running real ad targeting in the EU you need the real thing. But the compliance-theatre version, where the banner is heavier than the tracking it consents to, is common and worth questioning.

What to do instead: reduce what you collect first. If you drop the ad pixels from item four, your consent requirement shrinks with them. Then a small self-hosted banner, or in some setups no banner at all, does the job. The lightest consent implementation is having less to consent to.

8. The Icon Font

Font Awesome's full WOFF2 is around 130 KB for a set you are using nine icons from. An inline SVG icon is typically 100 to 300 bytes of markup, less once compressed. Nine icons inline is under 3 KB and it renders with the HTML, so no invisible icons during font load and no boxes if the font request fails.

How to check: search your markup for fa- or icon- class names and count the unique ones. Under about thirty unique icons, inline SVG wins clearly.

What to do instead: copy the SVG paths for the icons you use into a sprite or straight into your components. If you like the icon font workflow, subset the font to only the glyphs you use, which usually takes it under 10 KB.

9. The Auto-Playing Background Video

A hero video is normally the single heaviest asset on a site, frequently several megabytes, and it plays behind text that would read perfectly well over a still image. On mobile the browser may refuse to autoplay it anyway, so half your visitors get the poster frame, which tells you the poster frame was sufficient.

I have no vendor study to cite here. Open your own Network tab, filter by Media, and look at the number. It is usually larger than you expect, and it competes with everything else the page needs in the first second.

What to do instead: use the poster frame as a static hero image. If the video genuinely sells the thing, put it further down the page behind a play button, which is also the honest signal that it is worth watching.

10. Every Embed That Loads Before Anyone Looks at It

Zach Leatherman measured a single standard YouTube embed at almost 1.2 MB. A facade implementation such as lite-youtube-embed does the same job at roughly 30 KB until someone clicks play. That is a 97% reduction for a change that takes ten minutes and looks identical.

The same pattern applies to Google Maps embeds, Instagram feeds, Twitter timelines, and review widgets. All of them load third-party JavaScript on every page view so a small fraction of visitors can interact with them.

How to check: run PageSpeed Insights and look at the "Reduce the impact of third-party code" and "Lazy load third-party resources with facades" items. Lighthouse names the offenders and estimates the savings.

What to do instead: a facade. A static image or a styled placeholder that swaps in the real embed on click. For maps, a screenshot linking to Google Maps is usually better than the embed, because on mobile people want directions in their maps app, not a tiny pannable rectangle.

Find Yours in Ten Minutes

You do not have to guess which of these apply. Open Chrome DevTools, press Cmd+Shift+P, type "Coverage", and reload the page with recording on. You get a per-file breakdown of how much CSS and JavaScript was downloaded and how much actually ran.

On a page-builder site the red bars are alarming. Page builders sit well above the Almanac's median 280 KB of unused JavaScript because they load every module's CSS and JS on every page in case you used that module. Coverage will not tell you what is safe to remove, but it tells you where to look, and the biggest red bar is almost always a file you can load conditionally instead of globally.

Then run PageSpeed Insights before and after. Not for the score, for the third-party table, which lists every external domain with its transfer size and main thread blocking time. That table is your delete list with the arguing already done.

Do this once and it becomes a habit, in the same way that running through The Blog Post SEO Checklist before publishing stops the same five mistakes from shipping every time.

What This Actually Buys You

Removing a slider and two pixels will not turn a slow site fast. If your stack is fundamentally heavy, deletion buys you a few hundred milliseconds, not a new site. I looked at where the structural gap sits in Astro Sites Pass Core Web Vitals 67% of the Time. WordPress 49%., and the honest answer there was that platform choice explains a lot of it.

But deletion is free, it is reversible, and it is the only performance work with no downside. Every item on this list makes the page smaller and leaves one less thing that can break, get exploited, or need updating. Most of them also make the page clearer, which is the part that shows up in conversions rather than in Lighthouse.

Start with the third-party table. Delete what nobody can name an owner for. Then do the carousel, because deleting a carousel has never once made a website worse.

If you work through the list and the numbers still look bad, the problem is deeper than the widgets, and you need someone to measure properly rather than guess. Helping people remove website bloat and then fix what is left is a fair chunk of what I do at Wunderlandmedia. I am happy to tell you when deleting is enough and when it is not.