Why Staff Stopped Opening the Marketing Admin Page After 5 Seconds

The Marketing admin page took about 5 seconds to load, and the fix took 1h25m to trace and ship. Nearly all of that time went into the query, not the page.

The page is a staff-facing overview. The header block of counts and summaries renders before anything else, so the slow part was the first thing anyone saw. Nothing was erroring. It was just slow enough that people had stopped opening it.

Two faults behind one slow header

We started at the top of the page and worked down to the query that fed it. It had two separate faults, and both added to the load time.

A missing index. The query filtered and joined on a column that had no index, so the database scanned the table for every lookup. The fix is one statement, shaped like this:

CREATE INDEX ix_<table>_<filter_column> ON <table> (<filter_column>);

Too many round trips. The page issued its lookups one at a time. Each was cheap on its own, but every one paid its own network and query overhead, and that cost multiplied. We cut the round trips by fetching what the header needed in fewer, wider queries.

Then we added caching on top. The header numbers do not need to be true to the second, and the same admins load the same page many times a day. A short-lived cache means most loads skip the database entirely.

We would repeat the order. The index makes the cold path fast. Fewer round trips make the cold path cheap. The cache makes the warm path nearly free. Had we done only the cache, the page would have looked fixed on the second load while the first load of every cache window stayed at 5 seconds. Someone would have reported it again within a week.

Confirming it on production

This went out as a same-day hotfix. We confirmed it live on production by loading the page and watching the header render. That is the check we trust, because a query plan that looks good on a small staging dataset says little about a production table.

While in there we hit an unrelated bug and filed it as its own ticket instead of folding it into the hotfix. A hotfix that carries a second change is harder to roll back, and this one needed to stay a single small diff.

What the log does and doesn’t show

Our session log records the outcome: index added, caching added, round trips cut, hotfix confirmed live. It has no before-and-after timings beyond the roughly 5 seconds. We did not keep a per-query breakdown of what each of the three changes bought, so we cannot say the index was worth X seconds and the batching Y. We can say the combination fixed the page, and that the order above is the one we would choose again.

If a page is slow at the top, look at what the top depends on first. Then check that the fix covers the first load as well as the repeat loads, and that someone confirmed it on production.