My WordPress site was attacked about two weeks ago. The malware spread through PHP files, redirected visitors, and badly damaged the site's SEO. I restored the site from an older backup, and the obvious redirects appear to be gone, but the homepage still takes around 36–60 seconds to load. Other pages are faster, and the site runs on AWS.
I'm trying to determine whether the delay is caused by leftover malware, injected database content, slow PHP, a compromised plugin or theme, an external request that is timing out, AWS resource limits, or a caching/CDN problem.
What is the most effective way to identify exactly where the time is being spent? I'm especially interested in WordPress tools, browser diagnostics, PHP or web-server logs, AWS metrics, command-line checks, and malware scanners. I'd also appreciate advice on verifying that the infection is fully removed, speeding up the homepage, and hardening the site against another attack beyond enabling two-factor authentication.
4 Answers
A file restore does not necessarily clean the database, and the backup itself may have been infected. Inspect the database for injected content, especially autoloaded rows in wp_options, homepage-related post data, and unexpected scheduled events. Also inspect functions.php, mu-plugins, uploads, and other directories for unfamiliar PHP files. Online scanners are useful as a second opinion, but they should not replace a manual review and comparison with known-good WordPress, plugin, and theme files.
After a compromise, I would avoid trusting a partially cleaned installation. Replace WordPress core and every plugin and theme with fresh copies from trusted sources, restore only verified content and database data, and rotate hosting, database, SFTP, administrator passwords, salts, and API keys. Review access logs for suspicious POST requests and long-running processes, remove unknown cron jobs and mu-plugins, and keep the site in maintenance mode until it is verified. Once it is clean, restrict file editing and plugin installation in wp-config, keep everything updated, use least-privilege accounts, maintain tested offline backups, and add monitoring or a WAF.
Start with the browser’s Network panel and check the timing breakdown for the document and every asset. Look for an unfamiliar script, request, or resource that takes roughly 30 or 60 seconds to fail. Then test with a default theme and all plugins disabled. If the page becomes fast, re-enable them one at a time to isolate the problem. Query Monitor can also show slow database queries, PHP hooks, and WordPress HTTP API requests.
A 36–60 second delay often points to a request waiting for a timeout. Query Monitor’s HTTP API section may reveal a remote call that is hanging, such as an update check, license request, external asset, or leftover malware endpoint. From the server, use curl timing output against the homepage to compare DNS, connection, time to first byte, and total time. Enabling the PHP-FPM slow-request log can show which PHP requests exceed five seconds; AWS CPU, memory, disk, network, and burst-credit metrics are worth checking too.
Thanks, that gives me a practical order to test things. I’ll start with the network timings and then narrow it down by disabling plugins and the theme.