Response Time & Page Speed

12 Practical Ways to Improve Website Speed.

Written by noc724 team3 min readUpdated Oct 18, 2026

Speed work is easiest when you fix the biggest delay first. Measure before changing anything, change one thing at a time, and keep monitoring afterwards so the gain doesn't quietly disappear with the next release.

Key takeaways

  • Measure first: server time (TTFB) and front-end weight need different fixes.
  • Caching - at the CDN, the server and the database - usually gives the biggest win.
  • Compress text, resize and modernise images, and load scripts without blocking rendering.
  • Fewer redirects and third-party tags help every visitor.
  • Keep response-time monitoring on, so regressions are caught after deploys.
Downtime happens. Get notified!

noc724 checks your websites, servers and APIs around the clock and alerts you by SMS, Telegram or Bale the moment something breaks.

Register for FREE

Start by measuring

Split the problem in two:

  • Server side - how long until the first byte arrives? Check TTFB in your response time monitoring or browser developer tools.
  • Front end - how much has to be downloaded and executed after that? Look at the browser's network waterfall and page-speed reports.

If TTFB is over a second, front-end tweaks won't save you. If TTFB is 150 ms but the page weighs 6 MB, the server isn't the problem.

Server-side improvements

1. Cache full pages where you can

Pages that are the same for every visitor (home, articles, product pages for logged-out users) can be served from a cache for minutes at a time, skipping the application entirely.

2. Cache expensive data

Store results of slow queries or external API calls in an in-memory cache such as Redis with a sensible expiry.

3. Fix slow database queries

Enable the slow-query log, add indexes for the filters and sorts you actually use, and remove "N+1" query patterns that run one query per item in a list.

4. Use a CDN for static files

Serve images, CSS, JavaScript and fonts from a CDN close to users, with long cache lifetimes and versioned file names.

5. Enable HTTP/2 or HTTP/3 and keep-alive

Modern protocols multiplex many requests over one connection, removing much of the cost of loading many small files.

6. Compress text responses

Turn on Brotli or gzip for HTML, CSS, JavaScript, JSON and SVG:

# nginx
gzip on;
gzip_types text/css application/javascript application/json image/svg+xml;

Front-end improvements

7. Resize and modernise images

Images are usually the heaviest part of a page. Serve them at the displayed size, in WebP or AVIF, and lazy-load those below the fold with loading="lazy".

8. Load scripts without blocking

Add defer to scripts that don't need to run before the page is shown, and split large bundles so each page loads only what it uses.

9. Be careful with third-party tags

Chat widgets, trackers and ad scripts each add requests and CPU time, sometimes from slow servers abroad. Remove the ones nobody uses and load the rest after the main content.

10. Optimise fonts

Self-host fonts, use the WOFF2 format, include only the weights and character sets you need, and use font-display: swap so text appears immediately.

11. Remove redirect chains

Link directly to final URLs. Each redirect adds a full round trip before anything else can start.

12. Reserve space for content

Set width and height on images and embeds so the layout doesn't jump while loading - it feels faster and avoids mis-clicks.

Keep it fast

Speed regresses quietly: a new tag here, an unindexed query there. Keep a response time monitor on key pages with a slowness alert, and look at the chart after each release.

Frequently asked questions

  • Whatever the measurements show is biggest - usually server time on dynamic sites and images on content-heavy ones.

  • No. A fast server can deliver a page that is slow to render because of heavy images and scripts. Both sides need attention.

  • Compare the same measurement before and after, from the same locations, over at least a day so normal traffic patterns are included.

Share this article:XTelegramLinkedInFacebookReddit
noc724

Written by

The noc724 team

Uptime monitoring engineers

We build and run noc724, an uptime monitoring service that checks websites, servers and APIs from several cities in Iran. These guides come from the problems we and our users run into while keeping services online.

Contact the team

Expert on:Response Time & Page Speed

Questions?Contact Support
Feature suggestions?Share

Recent Articles