I Downloaded 8 Popular WordPress Plugins. Here's What I Found.

The Afternoon I Became a Plugin Detective

I spent last Tuesday afternoon doing something that probably sounds incredibly boring: downloading WordPress plugins and measuring their file sizes.

Why? Because I'm building lightweight WordPress plugins, and I wanted to make sure I'm actually delivering the best solution. So I did an apples-to-apples comparison of my work against other plugins in the same categories.

I picked eight popular plugins across three categories: reading progress bars, table of contents, and reading time generators. These should all be relatively simple plugins – a progress bar is literally just a colored div that fills up as you scroll. A table of contents scans your headings and creates a list. Reading time is basic math.

Nothing here requires megabytes of code. Or so I thought.

Spoiler: I found plugins ranging from a reasonable 88KB to an absolutely wild 11MB. For a progress bar and reading time generator. Combined.

Let me show you what I found.

The Experiment: What I Actually Tested

I wanted a fair comparison, so I focused on plugins that should theoretically be lightweight:

Category 1: Reading Progress Bars
Four different plugins that show a progress bar as you scroll through a post (like the one at the top of this page). This is a solved problem in web development – you calculate scroll position, divide by total height, multiply by 100. Done. Should be a few kilobytes of JavaScript at most.

Category 2: Table of Contents
Four plugins that auto-generate a table of contents from your post headings (check the sidebar on desktop, or the collapsible section above on mobile). Scan the DOM for H2-H6 tags, create an ordered list, add smooth scrolling. Again, not rocket science.

Category 3: Reading Time
Included in some of the progress bar plugins. Count words, divide by 200 (average reading speed), display result. It's straightforward logic that shouldn't require megabytes of dependencies.

For each plugin, I:

Downloaded the latest version from WordPress.org
Extracted the ZIP file
Measured the total size
Counted the files
Investigated the largest directories to see what's taking up space

All measurements verified. No estimates. No rounding up to make my point. Just the actual numbers.

The Results (Spoiler: Yikes)

Here's what I found, grouped by category:

Category	Size Range
Progress + Time	11MB / 252KB
Progress Bar	1.2MB / 872KB / 664KB / 88KB
Table of Contents	1.4MB / 956KB / 884KB / 856KB
Reading Time	580KB

For comparison, my plugins:

BlogUtils Read Time: ~19KB
BlogUtils Progress Bar: ~18KB
BlogUtils Table of Contents: ~23KB
BlogUtils Word Count: ~17KB
Total: ~77KB for all four plugins combined

The largest competitor plugin is 143x bigger than all four of my plugins put together.

(And yes, all four of these features are running on this page right now – progress bar at the top, read time and word count in the header, table of contents in the sidebar. Dogfooding at its finest.)

Let that sink in for a moment.

Case Study #1: The 11MB Monster (830 Files)

The biggest offender deserves special attention. This is a plugin that combines a reading progress bar with a reading time generator – two features that should take maybe 30KB combined.

Actual size: 11MB.

I had to double-check my terminal output because I thought I'd made a mistake. Eleven megabytes. For a progress bar. And a timer.

So I dug into the folder structure to see what could possibly justify this size:

Complete icon library: 1.3MB
The plugin includes an entire icon font library with multiple font formats (TTF, WOFF2, etc.). They might use one icon in their admin interface. They shipped thousands.

Admin options framework: Multiple megabytes
The plugin uses a complete admin options framework with 664KB of color CSS files (yes, just for color picking), vendor JavaScript libraries, and an image folder.

SCSS source files: 548KB
They included the source SCSS files. You know, the preprocessor files that compile into CSS during development. These have zero purpose on a user's production server. They're literally just dead weight.

File count: 830 files

For context, my entire four-plugin suite has fewer than 50 files combined. This one plugin has 830.

It's like ordering a hamburger and getting the entire cow, the farm it lived on, and the farmer's personal diary.

Case Study #2: The "Minimal" Plugin With a Secret

One table of contents plugin explicitly claims to be "minimal" and have "zero bloat" in its description. The WordPress.org page emphasizes that it doesn't load unnecessary JavaScript or CSS.

Great! Finally, someone who gets it.

Downloaded size: 884KB.

Wait, what? How is 884KB "minimal" for a table of contents?

I investigated. Turns out 768KB of that size is a single development dependency file.

This is the type of file that tracks exact versions of build tools during development. It's extremely useful when you're developing the plugin.

It has absolutely zero purpose on a user's server. It shouldn't be in the distributed ZIP file at all. I can't even think of a reason it should exist in production deliverables.

Remove that one file, and the plugin drops to around 116KB – which is actually pretty reasonable for a table of contents plugin with multiple features.

But instead, every user who installs this plugin downloads 768KB of completely useless data. Thousands of installations. Hundreds of megabytes wasted across the WordPress ecosystem.

Because someone forgot to add development files to their build exclusion list.

The actually minimal code: ~116KB
The accidental bloat: 768KB
The irony: Claiming to be "minimal" while shipping 768KB of dev files

Case Study #3: The Marketing Portfolio

A progress bar plugin clocking in at 1.2MB caught my attention. Progress bars should be tiny – you're literally just updating a width value as the user scrolls.

Guess what's taking up most of that space?

Marketing images: 904KB

Not images used by the plugin. Not images displayed on your site. Marketing images showing screenshots of the developer's other premium plugins and themes.

The folder structure:

admin/images/
  features-1.jpg (78KB)
  features-2.jpg (67KB)
  free-1.jpg (51KB)
  free-2.jpg (118KB)
  free-3.jpg (168KB)
  pro-1.jpg (54KB)
  premium-plugin-246x116.png
  premium-theme-246x175.jpg
  ... and more

These are upsell images displayed in the plugin's admin screen, showing you what other products you could buy.

You installed a progress bar. You got a sales catalog.

I've seen this pattern before (remember the 540KB of WordPress.org screenshots I found in another plugin?), but 904KB is a new record. That's almost a full megabyte of JPGs you'll never look at, sitting on your server forever.

The actual plugin code: ~300KB
The marketing portfolio: 904KB
The ratio: You're downloading 3x more marketing than actual code

Case Study #4: The Mystery Application

One of the most popular table of contents plugins (over 600,000 active installations!) has something unexpected in its codebase:

A specialized application library: 216KB

This appears to be a complete HTML parsing and filtering application, similar to what you might use for web scraping or content extraction.

For a table of contents plugin.

I'm genuinely curious why a table of contents plugin needs this. WordPress already gives you the post content. You're rendering it on the same page.

Maybe there's a legitimate reason I'm not seeing. Maybe it's used for some advanced feature. But it still strikes me as odd to include a 216KB specialized application when your primary job is "make a list from headings."

The plugin also includes duplicate files – two versions of the same tag filter (one for PHP 5.6, one for later versions), each around 104KB. Both shipped in every download, even though any given server only needs one.

The actual plugin code: ~1MB
The unnecessary bloat: ~424KB (specialized library + duplicate files)
Still large, but 30% smaller without the extras

My table of contents plugin: ~23KB.

That's a 60x difference for fundamentally the same functionality.

The File Count Problem

Beyond raw size, the number of files matters. Every file is an inode on the filesystem. More files = more disk operations, slower backups, more complex updates.

Remember the 11MB plugin? 830 files.

Let's put that in perspective:

A typical WordPress theme: 50-100 files
A well-built plugin: 10-30 files
My entire four-plugin BlogUtils suite: ~50 files total

This one plugin has more files than most complete WordPress themes.

Why? Because it includes:

An entire admin framework (hundreds of files)
Font icon libraries (dozens of font files)
Translation files for 20+ languages
SCSS source files (development files)
Vendor libraries for features WordPress already includes
Sample code and documentation

Don't get me wrong – translation support is great. But shipping all translation files when WordPress can lazy-load only the ones needed? That's a choice.

The "Lightweight" Claims

I need to address something that bothered me during this research.

Multiple plugins explicitly claim to be "lightweight" in their descriptions. One says it "removed jQuery for better performance." Another emphasizes "minimal bloat."

Then you download them:

The "lightweight" progress bar: 872KB (includes jQuery and other libraries WordPress already has)
The "minimal" table of contents: 884KB (768KB dev file)
The plugin that "removed jQuery": Still 872KB total

I'm not accusing anyone of lying. I think these developers genuinely tried to build lightweight plugins. Removing jQuery is great! That's a real optimization!

But then they included an entire options framework, bundled complete icon libraries "just in case," shipped their SCSS source files, and forgot to exclude dev dependencies from the build.

The road to bloat is paved with good intentions – and poor build processes.

What This Actually Costs You

"Okay," you might be thinking, "but storage is cheap. Who cares about a few megabytes?"

Fair question. Let's talk about the real costs:

1. Bandwidth
Every time WordPress updates a plugin, it downloads the full ZIP. If you have auto-updates enabled and that 11MB plugin updates monthly, that's 132MB/year just for one plugin. Multiply that across all your plugins and all your sites.

2. Backup Size
Your backup solution backs up those 830 files every time it runs. Daily backups? That's 830 files × 365 days being processed, compressed, and stored. Slower backups, higher storage costs.

3. Server Performance
More files = more disk I/O. More CSS/JS to parse and load. More memory usage. More potential points of failure. It adds up.

4. Update Risk
830 files means 830 things that could conflict with other plugins, cause permission issues, or fail during updates. Simpler plugins are more reliable plugins.

5. Security Surface Area
Every included library is a potential vulnerability. That icon library from 2023? If a security issue is found, the plugin developer needs to update it. Those specialized application libraries? Same deal. More code = more attack surface.

Is 11MB going to crash your server? No. But it's death by a thousand cuts. Install five bloated plugins and suddenly you're managing thousands of files, hundreds of megabytes, and significantly more complexity than necessary.

How I'm Building BlogUtils Differently

Here's my philosophy for the BlogUtils plugins:

1. One Job, Done Well
My Read Time plugin calculates reading time. That's it. It doesn't also create a progress bar, show related posts, or integrate with your email list. It counts words and does math.

2. No Framework Bloat
I don't need an admin framework for a plugin with five settings. I use WordPress's built-in Settings API. It works perfectly fine.

3. Build Process That Excludes Dev Files
My build process explicitly excludes source files, dev dependencies, and anything that's not needed in production. No SCSS. No development dependency files. No "samples" folder.

4. No Bundled Libraries Unless Absolutely Necessary
Need icons? I use Unicode symbols or inline SVG. Need color pickers? WordPress includes one. Need a complete icon library? I don't need 1,000 icons to show a clock symbol.

5. Aggressive Testing on Minimal Resources
I test on shared hosting with limited resources. If it's slow there, I optimize it. I don't assume everyone has a $100/month VPS.

The result:

~77KB total for all four plugins
~50 files total across all plugins
No external dependencies (besides WordPress itself)
No marketing images, no upsell screens, no dev files

Just clean code that solves specific problems.

What You Can Do About This

If you're currently using bloated plugins (and statistically, you probably are), here's what you can do:

1. Check Your Plugin Sizes
SSH into your server and run: du -sh wp-content/plugins/*

You might be surprised. If you see anything over 1MB for a simple utility plugin, investigate what's taking up space.

2. Look for Lightweight Alternatives
Before installing a plugin, check the download size on WordPress.org. If a reading time plugin is 580KB and another is 88KB, maybe try the smaller one first.

3. Ask Developers About Bloat
Leave constructive feedback on plugin support forums. "Hey, I noticed your plugin includes development files – any chance those could be excluded from future builds?" Most developers will appreciate the feedback.

4. Support Developers Who Care About Performance
Whether it's my plugins or someone else's, vote with your wallet. When you find a developer who's putting in the effort to build lean, quality tools, support them.

Or hey, just keep using the free bloated ones. I'm not your boss. But at least now you know what you're installing.

The Bottom Line

I started this experiment to validate my suspicion that WordPress plugins are often unnecessarily bloated.

The data proved me right – but honestly, I wasn't expecting it to be this bad.

11MB for a progress bar.
768KB of dev files in a "minimal" plugin.
904KB of marketing images.
Web scraper libraries in table of contents plugins.

And these aren't abandoned plugins from 2015. These are actively maintained, popular plugins with thousands (sometimes hundreds of thousands) of active installations.

The WordPress ecosystem can do better.

I'm trying to do better with BlogUtils. Four plugins, ~77KB total, no bloat, no upsells, no surprises. Just clean code that does exactly what it promises.

If that sounds appealing, check out the BlogUtils plugins. Each one is $50, or grab all four for $160 (save 20%). 30-day money-back guarantee if they're not lighter, faster, and simpler than what you're currently using.

And if you just want to see if I'm full of it, try the free reading time generator on the homepage. Paste your content, get your reading time, no signup required. It's the same algorithm the $50 plugin uses.

Either way, I hope this audit helps you think more critically about what you install on your WordPress sites.