Speed and Performance Fixes After an Incident

Why hacks slow sites down

Spam hacks are designed to create pages, sometimes tens of thousands of them, each linking to products or scams. Even after the code that created them is gone, the pages can remain in the database. Search engines keep requesting them, which uses server time, and the database grows heavy enough to slow every page.

Other common causes are less obvious:

• scheduled tasks left by the attacker that still run every few minutes and fail quietly;
• an options table filled with leftover settings and transients;
• cached copies of infected pages still being served by a caching plugin or the host;
• two or three security plugins installed during the panic, all scanning at once;
• a hosting account limited by the host while the site was sending spam.

What we do

1. Measure first. We record load times for your key pages from a consistent location and note server response times, so improvement can be shown rather than claimed.
2. Remove leftover spam. Spam posts, pages, comments and users are removed from the database, after a copy is taken. Where Google indexed the spam, removed addresses return a proper "gone" response so they drop out of search over time.
3. Clean the database. Expired transients, orphaned records and leftover settings from removed plugins are cleared, and tables are optimised.
4. Review scheduled tasks. Every WordPress cron event is checked. Tasks belonging to removed plugins or the attacker are deleted.
5. Cut duplicate plugins. One well-configured security approach replaces several overlapping ones. Unused plugins are deleted, as the WordPress hardening guide recommends ^[1].
6. Rebuild caches. Page caches, object caches and any CDN cache are purged and rebuilt from the clean site.
7. Check images and scripts. Oversized images are compressed and scripts that are no longer needed are removed from page templates.
8. Measure again. The same pages are measured the same way, and the results go into your report.

Spam pages in Google

If Google flagged hacked content, removing it is part of fixing the issue on every page before requesting a review ^[2]. Spam addresses can remain in search results for a while after they are gone from the site. Returning a clear "gone" status helps search engines drop them, and we check Search Console over the following weeks to confirm they are falling away.

How we measure

Speed numbers are only useful when they are measured the same way twice. We pick a handful of pages that matter to your business, usually the home page, a key service or product page and the contact or checkout page, and test them from the same location, at a similar time of day, with caches in the same state. We record the server's response time separately from the full page load, because a slow server and a heavy page need different fixes. Google's Search Console also has a Core Web Vitals report based on real visitors, and we note what it shows before and after, keeping in mind that it updates over weeks rather than hours.

When the host is the bottleneck

Sometimes the cleanup reveals that the hosting plan itself is the limit: an old PHP version, too little memory, or an account the host throttled during the incident and never restored. We check the PHP version and the limits the host reports, and ask the host to lift any temporary restrictions once the site is clean. If the plan is simply too small for the site, we say so, with the evidence, and leave the decision to you.

What affects the result

Some of what makes a site slow is outside this service: low-cost shared hosting, a heavy page builder, embedded videos, chat widgets and tracking scripts. We note any of these in the report with an estimate of their impact, so you can decide whether they are worth changing. We do not promise a specific score from any testing tool, because scores move with conditions outside the site.

What you receive

Speed work is easy to describe vaguely and hard to check. To keep it honest, every job ends with a short written summary that sets out what was measured before the work, what was changed, and what was measured afterwards, using the same pages and the same testing method each time.

The summary covers:

• the pages tested and the tool used, so you can repeat the test yourself;
• leftover files, database entries, scheduled tasks and user accounts removed after the incident;
• plugins or features switched off or replaced, with the reason;
• caching or image changes made, and anything that needs care when the site is next updated;
• issues outside the site itself, such as hosting limits, that we could not fix but that you may want to raise with your host.

Measurements change from test to test, because networks and servers vary. We report the figures as they were measured and do not round them in our favour. If the improvement is small because the remaining slowness sits with the hosting plan, the summary says so, so you can decide whether a hosting change is worth the cost.

Keeping it fast

Databases, caches and plugin lists grow again over time, so the gains fade if the site is left alone. A maintenance plan includes regular database tidying, update testing and a monthly look at load times, which keeps the gains in place.