How I Found a Major Performance Bottleneck in 10,000+ Redirects

Sometimes the biggest performance wins come from doing less, not more. I learned this the hard way while working on a WordPress site that was crawling. Pages that should’ve loaded in under a second were loading between 8 and 11 seconds

How I Found a Major Performance Bottleneck in 10,000+ Redirects

Sometimes the biggest performance wins come from doing less, not more.

I learned this the hard way while working on a WordPress site that was crawling. Pages that should’ve loaded in under a second were loading between 8 and 11 seconds and sometimes more. Visitors would be leaving which would have affected conversion rates and as you guessed, everyone was frustrated.

When I dug into the bottlenecks, I uncovered something hiding in plain sight: more than 10,000 redirects being handled inefficiently. The web team also worked on other issues like unoptimized images and heavy JavaScript/CSS, but my article will focus on the redirect nightmare that was dragging the site down.


Why 10K Redirects Broke the Site

The problem came from a common setup:

  • A bloated .htaccess file with thousands of old redirects
  • A plugin managing a smaller set of redirects
  • Apache being forced to process every single rule on every request

Here’s what was happening: every visitor triggered Apache to slog through the massive .htaccess list, and only after that did WordPress load and let the redirect plugin check its own rules.

It was like putting two security guards at every door, one forced to slowly check 10,000+ IDs before letting you inside, and another checking a short list once you’re already in.


The Redirect Journey:

BEFORE: Request → Apache (.htaccess 10K+ rules) → WordPress → Plugin (small set) = 8+ seconds

SOLUTION 1: Request → Apache (RewriteMap) = Major improvement  

SOLUTION 2: Request → Nginx (direct config) = Fastest

Fix #1: Let Apache Do the Work Efficiently

Instead of panicking, I stepped back and looked for smarter options. The big issue was obvious, so I focused on how Apache could handle 10K+ redirects without choking. That’s when I found RewriteMap.

I exported the .htaccess redirects into a plain text file and configured Apache to use RewriteMap. The difference was night and day. Page loads dropped significantly, and this single change gave us a huge performance boost. Later, we reduced plugin-managed redirects as well.

That experience reinforced a lesson I’ve carried into other challenges,even security hardening: simpler is faster and safer.

Most importantly, I realized something: performance problems often disappear when you let the right layer of your stack do the work.


Fix #2: Moving to Nginx for Speed

A few months later, a collegue suggested migrating from Apache to Nginx. At first, I hesitated, the RewriteMap solution was already working well. But after looking into Nginx’s approach, I was convinced.

Unlike Apache, which processes rules one by one, Nginx can handle thousands of redirects with very little overhead. We moved our redirects directly into the Nginx configuration, and the results were even better:

  • Faster redirect handling under load
  • More predictable performance
  • Cleaner, easier-to-maintain configs

How Performance Fixes Improved Security

As we simplified the redirect setup, something interesting happened our security improved at the same time.

Here’s why:

  • Reduced attack surface: fewer plugins meant fewer potential vulnerabilities
  • No open redirect abuse: server-level redirects are harder to manipulate
  • Removed .htaccess complexity: less exposure to injection attempts
  • Better visibility: server-level logs gave us clearer insight into traffic patterns

The Bigger Lesson

This project showed me that performance and security often move together. When you cut unnecessary complexity and let each layer do what it’s best at, you get faster response times and stronger defenses.

The redirect bottleneck was just one piece of our broader optimization next came image compression and trimming down JS/CSS but the redirect fix was a game-changer in teaching architectural thinking.

The pattern I follow now looks like this:

  1. Identify bottlenecks (don’t guess).
  2. Ask if the right layer is handling the task.
  3. Research alternatives before piling on new tools.
  4. Simplify relentlessly, remove what isn’t earning its keep.
  5. Challenge business processes that create unnecessary technical complexity.

Building fast, secure applications isn’t about throwing in more tools it’s about making smart choices and knowing when simpler is better.