Make the symptom repeatable
Measure one slow URL in a repeatable way, then separate network, page, application and account-resource evidence.
Use a comparable unaffected page to make the measurement meaningful. Record the date, time zone, browser, network, device and whether the page is slow before content appears or only after interaction. Repeat from another network or device to separate a local connection problem from a site-wide one. Do not rely on one speed score: lab tools use controlled conditions, while field measures reflect real visitors with different devices and caches.
Capture the response status, redirect chain and browser network timings. A slow initial document suggests a different investigation from a fast document waiting on a large image, third-party script or web font.
Separate browser, assets and backend response
In the browser network panel, sort requests by duration and size. If one image or script dominates, test that asset and its cache behaviour with the application owner. If the first HTML response is slow across several clients, compare a static file and a dynamic page on the same host. A static file that is quick while the dynamic page is slow points toward application or database work, although it is not proof of one cause. If both are slow, collect host and network evidence before making changes.
Check whether the slowdown coincides with a recent deployment, plugin update, content change or traffic event. Preserve the known-good version so a reversible test is possible.
Read only the metrics actually available
If your DirectAdmin account exposes disk, bandwidth or other resource figures, capture the metric and its time interval. DirectAdmin’s disk and bandwidth documentation does not make a CPU or memory graph available on every service, and optional throttling must be confirmed for your account. A quota warning explains a constraint but does not identify the slow request. Send support the page timings and panel evidence if the operator needs to inspect server-level processes or logs.
Do not restart shared services, alter global PHP workers or widen permissions from a customer account. These are operator changes and can affect other sites.
Change one application variable at a time
With an authorised site owner, test a bounded change such as reverting the latest plugin release or replacing an oversized asset. Compare the same URL, device and network before and after. Keep the change only if it improves the recorded symptom without breaking forms, layout or accessibility. Restore the prior version if the result worsens or cannot be reproduced.
Escalate a sustained backend delay with exact URLs, timestamps, request identifiers if visible, and the steps already tested. Never include passwords or private customer data in a public performance report.
For example, a cached public page may be quick while an uncached account page is slow. Repeat both under comparable conditions; one run does not distinguish application cost from network variation.
Frequently asked questions
Does a good Lighthouse score mean visitors are fine? No. A lab score describes one simulated run; field data and reported user symptoms can differ.
Will more disk space fix a slow page? Only if a verified storage constraint caused the symptom. First find the slow stage and its measured resource.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.