Measure website performance with curl, cache checks and Linux resource data

A slow page can be caused by DNS resolution, network distance, TLS setup, application work or the amount of content downloaded. Buying a larger plan only addresses some of those causes. Measure a representative request and correlate it with application and server evidence before deciding whether to change the website, its cache behavior or the hosting resources.

Measure the same request in a repeatable way

curl --silent --show-error --output /dev/null \
  --connect-timeout 5 --max-time 30 \
  --write-out 'status=%{http_code} ip=%{remote_ip} dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s total=%{time_total}s bytes=%{size_download}\n' \
  https://example.com/

The timing values are cumulative milestones. For example, TLS time includes earlier connection work; first-byte time includes the earlier network phases as well as the server's response preparation. Use differences carefully rather than adding all the values together or calling the entire first-byte number PHP execution time.

Record status, destination IP, test location and whether the response passed through a CDN. Repeat a few times under similar conditions and distinguish a cold request from a warm cache. A single fast localhost request cannot represent a customer on another continent.

Inspect redirects, caching and content encoding

curl --silent --show-error --dump-header headers.txt \
  --output page.html https://example.com/
grep -Ei '^(HTTP/|location:|cache-control:|vary:|content-encoding:|content-type:)' headers.txt
curl --silent --show-error --location --output /dev/null \
  --write-out 'redirects=%{num_redirects} final=%{url_effective}\n' \
  http://example.com/

Unnecessary redirects add connection and request work. Compare the intended HTTPS and preferred-host redirect chain, and check the final status instead of treating any returned page as success. For compression, inspect Content-Encoding on a suitable text response and consult the dedicated compression guide for configuration and testing.

Cache policy must match the content. Public caching of static assets can help, while customer accounts, carts and other personalized responses must not leak through a shared cache. Include relevant hostname, currency, language or authentication behavior in the cache design rather than applying one long-lived rule to the entire site.

Reduce work before increasing server capacity

Use browser network and performance tools to identify large images, unused scripts, blocking requests and excessive third-party calls. curl measures a single HTTP resource; it does not render the page or execute its JavaScript. A small HTML document can still trigger a heavy page load.

du -ah "$HOME/public_html" | sort -h | tail -n 20

Adapt the document root and avoid running a large tree walk repeatedly on a busy service. Optimize the assets responsible for actual traffic, remove unnecessary application work and use appropriately sized images. Already-compressed images, video and archives usually benefit little from an additional gzip layer.

For dynamic pages, inspect slow database queries and application traces using the tools appropriate to your stack. Adding a cache may hide repeated expensive work, but stale data, invalidation and personalized responses still need an explicit design.

Correlate slow requests with resource pressure

uptime
free -h
df -h
df -i
ps -eo pid,user,rss,comm --sort=-rss | head -n 15
systemctl --failed

High memory use, CPU saturation, slow storage and exhausted inodes lead to different remedies. Resident memory figures can include shared pages, so blindly adding process RSS values can overstate total memory demand. Use sustained trends and the Control Panel's CPU, memory, network and disk I/O history alongside these snapshots.

On shared hosting, use the account's available resource and error reports and ask support about a specific incident window. Do not assume that an Unlimited transfer label also means unlimited concurrent workers, CPU or application memory. Review the actual service limits and terms.

Choose an upgrade that addresses the measured constraint

More RAM can help a workload that is repeatedly memory-constrained; additional CPU can help supported parallel application work; storage performance or query changes may matter more for an I/O-bound workload. A different location may improve network distance for an audience, but it does not repair an inefficient query.

Compare a baseline and a controlled change using the same request and business workflow. Verify both typical response and errors, and monitor resource use after the change. If the bottleneck is outside the server, increasing the VPS size may change the bill without changing the customer experience.

Keep a small performance record

• Record representative URLs and the user workflow each test exercises.
• Track test location, resolved IP, cache state, status and response size.
• Separate browser rendering time from server and single-request measurements.
• Recheck after application releases, cache changes and material traffic growth.

Performance work is most effective when the evidence explains the next action. Keep the measurement narrow enough to interpret and repeat, then use broader profiling or a planned load test only when the initial findings justify it.

Primary documentation

• curl command-line reference
• NGINX gzip module
• Apache mod_deflate configuration
• systemd journalctl reference