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:

1. Downloaded the latest version from WordPress.org
2. Extracted the ZIP file
3. Measured the total size
4. Counted the files
5. 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:

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.

Last month, I was talking to a blogger who runs a content site. She'd spent three hours that morning trying to fix a broken plugin after a WordPress update.

"I think it's been abandoned," she said, frustration clear in her voice. "The support forum is full of people with the same issue, and the developer hasn't responded to any of them. Everyone's just... stuck."

As a developer, my first instinct was to help troubleshoot. "Did you try reaching out directly?"

She laughed. Not a happy laugh. The kind of laugh that comes after you've exhausted every option.

"The developer's website doesn't load anymore. Based on the comments in the forum, it looks like they just disappeared. And here's the thing – this plugin has over 20,000 active installations, which was why I chose it to begin with. I guess I didn't do enough research."

Here's the part that made my blood boil: Twenty thousand websites potentially affected by the same issue, and no one at the wheel.

"So what are you going to do?" I asked, half expecting her to ask for my assistance.

"Same thing I always do. Find another free plugin and hope this one doesn't break in six months."

As a developer with decades of experience, that conversation absolutely infuriated me. Not at her – she was being completely rational given the hand she'd been dealt. I was furious at the system itself.

Why do we collectively accept abandoned software as normal? Why is "hope it doesn't break" a legitimate strategy for running a business website?

The Honeymoon Phase (AKA: Why Free Plugins Seem Amazing)

Look, I get the appeal. You need to add word count to your blog. You search "WordPress word count plugin." You find one with 4 stars and 10,000 active installs. It's free. You click install.

Five minutes later, boom – word counts on all your posts. It's like magic! You feel smart for saving money. You wonder why anyone would ever pay for WordPress plugins when free ones exist.

This is the honeymoon phase. Everything is new. Everything is exciting. You haven't noticed the problems yet.

But give it time. Oh, give it time.

Red Flag #1: The Ghost Developer

Six months later, WordPress updates to version 6.5. Your word count plugin breaks. No problem, the developer will fix it, right?

You check the plugin page. Last update: 2 years ago.

You check the support forums. Last response from the developer: "Working on it!" from 18 months ago.

You check their website. Domain expired.

Congratulations! You're now the proud owner of abandoned software. It's like adopting a digital puppy, except the puppy is broken code and you can't teach it new tricks.

The Reality: In my research, I found that many free plugins—possibly over half—haven't been updated in over 2 years. Some developers lose interest. Some move on to other projects. Some just... disappear into the internet void.

When you pay for a plugin, the developer has a financial incentive to keep it maintained. When it's free? They're doing it out of the goodness of their hearts. And hearts can't pay rent.

Red Flag #2: The Bloat Monster

Let me paint you a picture. You install a "simple" reading time plugin. You expect it to calculate reading time. Maybe 10-20KB of code, tops.

The download finishes. You check the file size: 580KB.

Wait, what?

That's a popular one, by the way – tens of thousands of installations. It's not some abandoned project. People are actively downloading 580KB to calculate reading time.

But it gets better (worse?). I found a progress bar plugin that clocks in at 664KB. Curious, I dug into the folder to see what could possibly need that much space.

Screenshot images. 540KB worth of banner images and screenshots meant for the WordPress.org listing. They're literally including their marketing materials in the download that users install on their servers.

All you wanted was a progress bar. You got a marketing portfolio.

My Approach: The BlogUtils Read Time plugin is ~19KB. The Progress Bar plugin? ~18KB. They calculate reading time, show progress bars, and do everything you need. No analytics. No upsells. No popup begging for reviews. And definitely no marketing screenshots eating up your server space. In fact, you can see them both in action on this page – check the progress bar at the top and the read time in the header.

Because sometimes, less really is more.

Red Flag #3: The "Free" Plugin That Isn't Really Free

Here's a fun game: Count how many "free" plugins show you an upgrade screen within 5 minutes of installation.

"Want to customize colors? Upgrade to Pro."
"Want to choose position? Upgrade to Pro."
"Want us to stop showing you this upgrade message? Believe it or not, also Pro."

This is the freemium model taken to its logical extreme. The free version is basically a demo that lives in your WordPress admin, constantly reminding you that you're using the inferior version.

And you know what? I respect the hustle. Developers need to get paid. But let's not pretend it's "free" when 80% of the useful features are locked behind a paywall.

My Approach: When you buy a BlogUtils plugin for $50, you get everything. All features. All settings. All customization options. No "Pro" version. No "Premium" upsells. Just the complete plugin you paid for.

Red Flag #4: The Theme Compatibility Nightmare

Free plugin developers often don't have the time or resources to test their plugins across multiple themes. So they test on their theme, maybe one or two popular ones, and call it a day.

Then you install their plugin on your site, and... nothing works. Or it works weird. Or it works but looks terrible. Or it works perfectly until you update your theme, and then it breaks spectacularly.

Why? Because they used CSS selectors instead of WordPress hooks. They hard-coded DOM elements instead of using proper WordPress filters. They made assumptions about your theme structure that turned out to be hilariously wrong.

My Approach: Every BlogUtils plugin is tested on the five most popular WordPress themes: Astra, GeneratePress, OceanWP, Hello Elementor, and Twenty Twenty-Four. But more importantly, they're built using WordPress hooks and filters – the proper way to extend WordPress.

This means they work with basically any theme, not just the ones I tested. It's the difference between "works on my machine" and "works on everyone's machine."

Red Flag #5: The Support Vacuum

You have a problem with the plugin. You post in a support forum or send an email. And then... nothing.

Days pass. Weeks pass. Maybe someone else with the same problem chimes in. You trade theories about what's broken. Neither of you actually knows.

Eventually, you either figure it out yourself, hire someone to fix it, or just give up and find a different plugin.

The Reality: Free plugin developers aren't obligated to provide support. Most do their best, but they're juggling this with their day jobs, families, and lives. When you don't pay for something, you can't really demand 24/7 support.

When you buy a paid plugin, you're not just buying code – you're buying a support relationship. When something breaks, I have to help you fix it. That's the deal.

"But What About CodeCanyon? Those Are Paid Plugins!"

Fair point! CodeCanyon and similar marketplaces sell WordPress plugins for $29-49. So paid plugins should be perfect, right?

Not so fast, my optimization-seeking friend.

To be fair, I do believe there's generally a higher level of quality on CodeCanyon compared to the free plugin directory. You're paying for something, so developers tend to put more effort into the code, testing, and support. That accountability matters.

But even with that quality bump, marketplace plugins still fall into some of the same traps. They're packed with marketing materials, feature bloat from trying to be everything to everyone, and frameworks that do way more than necessary. Respectfully – they're often solving problems you don't have.

Marketplace plugins have their own issues:

• They're often massively bloated (200-500KB is common)
• You're buying from a marketplace, not directly from the developer
• Support can still be hit-or-miss depending on the developer
• Updates can be inconsistent
• You're one of thousands of customers

My Approach: Direct sales. When you buy from BlogUtils, you're buying directly from me. I built these plugins. I maintain them. I answer support emails. There's no middleman, no marketplace fees, no layers of separation between you and the person who wrote the code.

Plus, my plugins are competitively priced while being way lighter and more focused than marketplace alternatives.

The Accountability Factor (This Is the Real Point)

Here's the uncomfortable truth: When a developer charges money for their plugin, they're accountable to you.

If I sell you a plugin and it breaks your site, that's my problem. I have to fix it. I can't just shrug and say "it's free software, no warranties." You paid for it, so I'm on the hook.

This accountability drives better quality:

• More thorough testing before release
• Faster response to bug reports
• Regular updates as WordPress evolves
• Actual incentive to make the plugin good

Free plugins don't have this dynamic. The developer is doing you a favor by maintaining it at all. You can't be mad at free stuff for breaking – it's free.

The Real Math: What "Free" Actually Costs

Let's do some back-of-the-napkin math:

Scenario 1: Free Plugin

• Cost: $0
• Time spent troubleshooting broken updates: 2 hours
• Time spent searching for alternatives when abandoned: 1 hour
• Time spent fixing theme compatibility issues: 1 hour
• Total cost at $25/hour: $100 of your time

Scenario 2: Paid Plugin ($50)

• Cost: $50
• Time spent troubleshooting: 0 hours (it just works)
• Time spent searching for alternatives: 0 hours (not abandoned)
• Time spent fixing compatibility: 0 hours (properly tested)
• Total cost: $50

The math gets even worse if you're billing clients. Every hour you spend debugging free plugins is an hour you're not billing. Or worse, an hour you're eating because you can't charge the client for fixing your plugin choice.

My WordPress Plugin Philosophy (Gets Down From Soapbox)

After decades of development, here's what I believe:

1. Small is Beautiful
My largest plugin (Table of Contents) is ~23KB. (You're looking at it right now in the sidebar, by the way.) That's smaller than most plugin screenshots. All four plugins combined? ~77KB total. Compare that to the 580KB reading time plugin I mentioned earlier – one competitor plugin is nearly 8x larger than my entire suite. No bloat. No unnecessary frameworks. Just clean code that does exactly what it's supposed to do.

2. One-Time Payment > Subscriptions
$50 once, and it's yours forever. Updates for life. No annual fees. No surprise price increases. No "your subscription expired" emails.

3. WordPress Hooks > CSS Hacks
Build plugins the right way using WordPress filters and actions. They'll work with any theme, any page builder, any setup.

4. Support Matters
When you have a problem, email me. I'll respond. I'll help. That's part of the deal when you pay for software.

5. Quality > Quantity
I could release 20 mediocre plugins and hope a few stick. Instead, I'm releasing 4 really good ones. They're tested. They're optimized. They work.

The Part Where I'm Biased (Full Disclosure)

Look, I'm obviously biased here. I'm literally writing this to convince you to buy my plugins instead of using free alternatives.

But I'm biased because I genuinely believe paid plugins are better for everyone:

• Better for users: You get quality, support, and accountability
• Better for developers: We can actually afford to maintain our software
• Better for WordPress: Quality plugins make the ecosystem stronger

It's not that all free plugins are bad. Some are genuinely great, maintained by passionate developers who do incredible work for free. Those developers are heroes.

But many free plugins are abandonware waiting to happen. And when you're building a business on WordPress, you need tools you can depend on.

The 30-Day Safety Net

Still worried about investing in a plugin? I get it. It's real money, and you want to be sure it's worth it.

That's why every BlogUtils plugin comes with a 30-day money-back guarantee. If it doesn't work for you – for any reason – just ask for a refund. No questions. No hassle. No forms to fill out explaining why.

Try it risk-free. If the free alternative ends up being better for your needs, I'll refund you and you can go back to the free plugin. No hard feelings.

The Bottom Line (Finally)

Free WordPress plugins aren't evil. They're just not always the bargain they appear to be.

When you factor in the time cost of troubleshooting, the risk of abandonment, and the bloat that slows down your site, sometimes paying for a focused, well-maintained plugin is the smart financial decision.

Plus, you get the warm fuzzy feeling of supporting independent developers who are trying to build quality tools instead of growth-hack their way to an exit.

And hey, at least my plugins won't ghost you after six months. That's a promise I can keep.

I'm about to add four more WordPress plugins to an ecosystem that already has... checks notes ...approximately 60,000 of them.

I know what you're thinking: "Great. Another developer who thinks their plugins are special." And you'd be right to be skeptical! But hear me out, because I've got a story about subscriptions, bloated code, and why I'm done with the way most WordPress plugins are built.

The Problem: When Did Plugins Become Monthly Payments?

Here's the thing – I've been writing code for decades. I've seen trends come and go. I've watched free tools become "freemium." I've witnessed one-time purchases morph into monthly subscriptions faster than you can say "SaaS creep."

And somewhere along the way, WordPress plugins joined the party.

$9 a month for a word counter. $15 a month for a reading time generator. $29 a month for a progress bar that's literally 50 lines of JavaScript. When did we collectively decide this was okay?

Look, I get it. Developers need to eat. I'm not saying all subscription models are evil. But when I just want to add a simple feature to my blog – like showing how long it takes to read a post – I shouldn't need to commit to a long-term relationship with someone's billing system.

The Lightbulb Moment (Or: Why I'm Doing This)

I was reviewing a popular reading time plugin the other day – you know, one with tens of thousands of active installations. The download was 580KB.

For context, that's roughly the size of a small novel. To calculate reading time. Using basic math.

My version? ~19KB.

That's not a typo. That's not me being clever with compression. That's just... not including a bunch of stuff nobody needs. No analytics trackers. No upsell popups. No framework that does 100 things when you only need one.

Here's the kicker: that 580KB competitor plugin is nearly 8x larger than all four of my plugins combined (~77KB total). One plugin. Eight times my entire suite.

It's like buying a hammer and getting a free anvil, forge, and blacksmithing certification course you didn't ask for.

What I'm Building (The "Keeping It Light" Collection)

I'm launching with four plugins, each designed to solve one problem really well:

Word Count (~17KB) – Shows word counts on your posts. That's it. No fancy AI predictions about how many words you should write. Just accurate counts that match what Google Docs and Word give you. Because sometimes simple is enough.

Read Time (~19KB) – Calculates reading time using the same algorithm Medium and Substack use (200 words per minute, for you speed-readers taking notes). Check the header of this post to see it in action. It even accounts for images, because yes, I've actually thought about this stuff. First image? 12 seconds. Eleventh image? 3 seconds. Your readers are skimming by then anyway.

Progress Bar (~18KB) – A smooth, 60fps scroll indicator that shows reading progress. You're seeing it right now at the top of the page. It's performant enough that your site won't feel sluggish, and your readers get that satisfying visual feedback as they scroll. Small wins matter.

Table of Contents (~23KB) – Auto-generates a TOC from your headings with smooth scrolling navigation. If you're on desktop, it's in the sidebar to your right. On mobile, it's collapsible at the top. Works with Gutenberg, Classic Editor, and all the major page builders. Yes, even that one you're thinking of. And it's still under 24KB.

Total size of all four plugins combined? ~77KB. That's less than most single plugins from competitors.

The Part About Money (Let's Not Dance Around It)

Each plugin is $50. One-time payment. Not per month. Not per site (okay, technically it's per site, but no subscription). Buy it once, use it forever, get updates for life.

If you want multiple plugins, there are bundle discounts – 2 for $90 (save 10%), 3 for $127.50 (save 15%), or all 4 for $160 (save 20%). That's less than what some developers charge per month for similar tools.

Why so cheap? Because I'm not trying to fund a yacht. I'm trying to build a sustainable business selling tools that genuinely help bloggers. If I price them fairly, support them properly, and keep the quality high, I figure people will actually want to buy them.

Revolutionary concept, I know.

The Promise (This Is Where I Get Sincere)

Here's what I'm committing to:

No subscription creep. I'm not going to gradually move features behind a monthly paywall. What you buy today is yours. The "one-time payment" model isn't a temporary marketing tactic.

Actual support. When you email me, you're emailing me. Not a tier-1 support team reading from a script. Not a chatbot pretending to be helpful. Just a developer who knows exactly how these plugins work because I wrote every line.

Lightweight code. I'm not going to bloat these plugins with features nobody asked for. They're small, they're fast, and they're going to stay that way.

Theme compatibility. All four plugins are tested on the major WordPress themes (Astra, GeneratePress, OceanWP, Hello Elementor, Twenty Twenty-Four). They use WordPress hooks properly, so they work with basically any theme. Not just the popular ones.

30-day money back guarantee. If you try one of my plugins and it doesn't work for you – for any reason – just ask for a refund. No questions, no hassle, no "but you already downloaded it" nonsense.

Why You Should Care (Besides My Winning Personality)

WordPress powers approximately 43% of all websites as of 2025. That's a lot of blogs that could benefit from better tools. Tools that load fast. Tools that don't require a monthly commitment. Tools built by someone who actually cares about quality.

I've been building software for decades. I know what good code looks like. I know the difference between "works on my machine" and "works everywhere." And I know that most WordPress users just want plugins that solve their problems without creating new ones.

That's BlogUtils in a nutshell.

The Free Thing (Because Everyone Loves Free Things)

Oh, and before you go – try the free read-time generator on the homepage. Paste in your article, see how long it takes to read. No signup required, no tracking, just a useful tool that demonstrates the kind of quality I'm going for.

If you like what you see, maybe consider checking out the actual plugins. If not, hey, at least you got a free generator out of it.

Welcome to BlogUtils. It's good to have you here.