Skip to content
Avaloi

Site is slow

Find out why pages load slowly by reading the cache headers, the logs, the PHP settings, and the bot traffic, then fix the cause.

A slow site usually comes down to one of four things: pages that skip the cache, PHP that runs short of memory or threads, a plugin or cron job doing heavy work, or bot traffic. Every check below uses a tab on the site in the dashboard. Work through them in order, because the first ones find the cause most often.

What you see

  • Pages take several seconds to load, or load fast once and slowly the next time.
  • wp-admin is slow while the public pages are fine, or the other way round.
  • The site slows down at the same time every day or every few minutes.
  • Visitors report timeouts while the site looks fine to you.

Check these first

  1. Read the cache headers. Open a slow page in your browser's developer tools, or run curl -I against it, and look at x-avaloi-cache and x-avaloi-cache-reason. HIT means the edge served the page and PHP never ran, so the delay is in the page itself: large images, slow third-party scripts, or many requests. MISS, BYPASS, STALE, or EXPIRED means PHP built the page, and the reason header says why. Avaloi never caches a page for a logged in visitor, a visitor with items in a cart, a POST, or a response that sets a cookie.
  2. Check the cache settings. Open the site, then Caching. Pages are kept for one hour and static files for 30 days by default. Look for a path rule that excludes the slow page and for query parameters that split the cache into many copies. Marketing parameters such as utm_source are ignored already.
  3. Read the logs. Open Logs and pick cache.log to see the cache result for many requests at once. Then pick error.log and filter by Error and Warning: a PHP memory error or a plugin fault shows here. php-fpm.log shows what the PHP workers reported. access.log shows which URLs get the most requests and from which addresses. The viewer holds the last 1000 lines and adds new ones live, or call GET /v1/environments/{id}/logs/{file}.
  4. Check PHP. Open Tools, then PHP settings, and compare the memory and run time limits with what your plugins need. On the Info tab, PHP performance shows the memory pool, the threads, and the memory per thread. Too few threads means requests queue; too little memory per thread means requests fail. If you changed the PHP version recently and the homepage answered with a server error, Avaloi switched back on its own and tells you why.
  5. Check cron. Open Cron. A job that runs every 5 minutes and takes a long time, or one whose last run shows a non-zero exit code, slows every request that runs beside it. Open the row to see the exit code and the output. Avaloi keeps the output for 7 days.
  6. Check bot traffic. Open Bot protection to see bot traffic in the last 24 hours. When the mode is Off or Monitor, automated traffic reaches PHP like any visitor. Compare it with the addresses that fill access.log.
  7. Check recent changes. Open User activity to see who deployed, changed PHP, or cleared a cache, and when. The Code tab lists the releases, so you can see whether the slowdown started with a deploy.

Fix it

  • If a plugin sets a cookie on every page and that stops caching, turn on Strip Set-Cookie under Tools. Then clear the cache from Caching; it clears the edge and the server together.
  • If a path rule or a query parameter stops caching by mistake, change it on Caching. Saving applies the settings at the edge through a job.
  • If PHP runs short, raise the memory limit or rebalance threads and memory inside the pool. Change one PHP setting at a time, so each change can roll back on its own. Restart PHP from Tools afterwards.
  • If a plugin is at fault, test the change on staging first. Clone content from live, deactivate the plugin in wp-admin on staging, and compare.
  • If a cron job is heavy, pause it from its switch or make its schedule less frequent.
  • If bots are the cause, set the mode to Challenge suspicious or Block definite bots. Verified crawlers such as search engines always pass. For one address that floods access.log, add it under IP deny.
  • If a deploy started it, open Code, choose the earlier release, and roll back. Rollback changes code only, and the older code goes live in under 10 seconds.

Still stuck

Write to [email protected] with the site name, the environment, the request ID from the API response or the job ID, and what you tried. Add one slow URL and the x-avaloi-cache and x-avaloi-cache-reason values you saw for it.

Still stuck?

Email [email protected] with your site name and what you tried, or send us a message.