June 15, 2026

Why I Write a 200-Line Plugin Instead of Installing a 200,000-Line One

A case for writing small, single-purpose WordPress plugins instead of reaching for a heavyweight one — fewer dependencies, faster pages, and code you can actually read.

  • WordPress
  • Performance
  • PHP
Illustration of a small focused code block inside a larger faded circle

The default instinct is wrong

Need an FAQ accordion on a WordPress site? There’s a plugin for that. It also bundles a page builder integration you don’t use, a settings panel with forty options you’ll never touch, its own jQuery version, and a changelog full of “fixed XSS vulnerability” entries for a feature you didn’t know it had. Multiply that by every “there’s a plugin for that” moment on a real site and you get what most slow WordPress installs actually are: a pile of general-purpose plugins, each solving 5% of your problem and shipping 100% of theirs.

My default now is close to the opposite: if a feature is genuinely narrow — an accordion, a calculator, a CSV import routine, a translation sync between staging and production — I write it as its own small plugin. Not a theme function, not a snippet in functions.php — a proper standalone plugin with a clear name and a one-line description of what it does and nothing else.

What this actually buys you

  • No dependency surface you didn’t choose. A 200-line plugin has one job. It doesn’t load an admin framework, an analytics SDK, or a licensing check-in system in the background. When something breaks, there’s one file to read.
  • It survives theme and plugin updates. I’ve watched entire SEO-critical page layouts get wiped by a theme update because the markup lived in the theme. A widget library or an import tool that’s its own plugin doesn’t care what the theme does next.
  • It’s actually reviewable. I can hand a client’s next developer a 300-line file and they understand the whole thing in ten minutes. Nobody reads a 5MB plugin’s source before trusting it; everyone can read mine.
  • Performance is a side effect, not a project. Removing a bloated “everything” plugin and replacing its one used feature with 80 lines of PHP is one of the most reliable page-speed wins I know — no image compression, no caching layer, just less code running per request.

Where this doesn’t apply

I’m not anti-plugin. WooCommerce, LearnPress, ACF — these solve genuinely hard, broad problems, and rewriting them yourself is how projects die. The line I draw is: if a plugin exists to be configured into doing one specific thing on one specific site, I’d rather just write that one thing. Configuration is its own kind of complexity, and it’s a lot harder to read a settings panel’s intent six months later than it is to read a function.