Server Guides

How to Optimize TTFB on Offshore Hosting

Step-by-Step Tutorial

What you will set up

By the end, you will have a lower TTFB on your offshore site — meaning your server starts sending each page faster after someone clicks.

First, what is TTFB? TTFB means Time To First Byte. It is how long your server takes to start sending the page after a visitor clicks. Think of it like a waiter: TTFB is the time before the first plate arrives, not the time to eat the whole meal. Lower is better. Offshore servers can sit far from your visitors, so cutting this number really helps.

Do one step at a time. Finish a step, measure again, then move on.

What you changeCaching, PHP, and a CDN.
Where you workServer over SSH + your hosting panel.
Why do itPages start loading sooner for visitors.

Before you start

The goal: get a faster TTFB by caching pages, speeding up PHP, and serving visitors from a nearby location.

Take a backup first. Before changing anything, make a backup or a server snapshot you can roll back to. If a website is already live, back up its files and its database.

  • Keep your hosting/server panel login ready.
  • Keep the server IP, username, and password (or SSH key) ready.
  • Keep your Cloudflare or CDN login ready (for the last step).
  • Open a notes file and write down your TTFB number before and after each change.
  • Change one thing at a time, then measure again — so you know what actually helped.

Where does each change happen?

Each change lives in a different place. Here is the simple rule:

  • Page caching → your web server (LiteSpeed) or a WordPress cache plugin.
  • PHP speed (Opcache) → the PHP settings on the server, over SSH.
  • CDN → your Cloudflare or CDN dashboard.
  • Measuring TTFB → from your own computer using curl.
Map of where each TTFB change happens: caching, PHP, and CDN
Where each step happens.

The steps

Step 1: Measure your current TTFB

First get a starting number, so you can tell if your changes actually helped. This one curl command prints how long the server took to start sending the page.

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}sn" https://yourdomain.com

Check: you see a line like TTFB: 0.85s. Write that number down. Run it two or three times to get a fair average.

Step 2: Turn on page caching

Without caching, the server rebuilds the whole page on every visit, which is slow. With caching on, the server keeps a ready-made copy and sends that instead — so the first byte arrives much sooner. Pick whichever fits your setup: LiteSpeed LSCache (if your server runs LiteSpeed), a WordPress cache plugin, or a Redis object cache for the database. Turn on just one page cache to start.

Check: reload the homepage twice, then re-run the Step 1 command. The TTFB number should drop.

Step 3: Speed up PHP with Opcache

Opcache keeps your compiled PHP code in memory, so the server does not re-read and re-compile it on every request. That shaves time off the first byte. First check whether it is already on.

php -i | grep opcache.enable

If it shows Off or 0, enable it in your php.ini (set opcache.enable=1) and restart PHP-FPM. On a managed panel, look for an “Opcache” toggle instead.

Check: the command above shows opcache.enable => On => On.

Step 4: Put a CDN in front

A CDN (for example Cloudflare) keeps copies of your site in many locations around the world. Visitors are served from the one nearest them, and your offshore server does less work. This is the biggest win when your visitors are far from your server.

Sign in to Cloudflare, add your domain, and point your domain’s nameservers to the ones Cloudflare gives you. Then turn on caching for static files.

Check: after the CDN is active, run the Step 1 command again from a location near your visitors. TTFB should be lower than your starting number.

Extra commands you may need

Run these only on your own server. If your server uses a managed panel, check with support before changing system-level settings.

See the full breakdown of where time goes

This shows connect time, TTFB, and total time together, so you can tell whether the delay is the network or the server building the page.

curl -o /dev/null -s -w "connect: %{time_connect}s  ttfb: %{time_starttransfer}s  total: %{time_total}sn" https://yourdomain.com

If connect is high, the problem is distance/network (a CDN helps). If ttfb is much bigger than connect, the server is slow to build the page (caching and Opcache help).

Confirm Opcache is on

php -i | grep opcache.enable

It should say On.

One note about testing: always measure from a tool or location close to your real visitors. A test run from right next to the server will look great even when faraway visitors are still waiting. Use a testing tool that lets you pick a region near your audience.

Keep short notes as you go

While you work, jot down each change: the TTFB before, the TTFB after, the time, and what you changed. For example: “Caching on, TTFB 0.85s → 0.30s, changed 10:30, homepage works.” It sounds small, but it tells you exactly which change helped and by how much.

If you run server commands, paste the output into your notes too. Then if you ask support for help, you can show the exact command, the exact result, and the exact time.

If a step fails, how to undo it

Always have a way back. For caching, turn the cache plugin or LSCache off again and clear it. For Opcache, set opcache.enable=0 and restart PHP-FPM. For the CDN, pause Cloudflare or point your nameservers back. Don’t change three things at once — if TTFB gets worse, you won’t know which one did it.

Final TTFB testing checklist after caching, Opcache, and CDN
The final testing checklist.

How to test after setup

  1. Re-run the Step 1 curl command and compare with your starting number.
  2. Test the homepage, an inner page, and a blog post — not just one URL.
  3. Test from a tool or location close to your real visitors.
  4. Reload each page twice so you measure a cached hit, not a cold one.
  5. Check the HTTPS padlock still works with the CDN on.
  6. Run the breakdown command to confirm where the remaining time goes.

Quick troubleshooting

Problem Likely reason What to do
TTFB still high with cache on The cache isn’t actually being hit Check the response headers for a cache hit (e.g. x-litespeed-cache: hit); make sure logged-in or cookie pages aren’t bypassing it
Database-heavy pages slow Every visit runs the same slow queries Add a Redis object cache and optimize or index the slow queries
Far-away visitors slow They reach the offshore server directly Add a CDN so they’re served from a nearby location

Final checklist

  • Starting TTFB measured and written down.
  • Page caching turned on.
  • Opcache confirmed on.
  • CDN active in front of the site.
  • New TTFB measured and lower than the start.
Need fast, privacy-friendly hosting for this setup?

OffshoreKaka offshore web hosting comes with caching-friendly servers so a low TTFB is easier to reach.

View OffshoreKaka hosting plans

FAQ

What is a good TTFB number?

Under about 0.2 seconds is great, and under 0.5 seconds is fine for most sites. On offshore hosting the distance adds a little, which is exactly why caching and a CDN help so much.

Will a lower TTFB get me to #1 on Google?

No honest tutorial can promise that. A fast TTFB helps — speed is good for visitors and for Google — but your content and backlinks still decide your ranking. This just gives you a faster, more stable base.

Which step matters most?

Page caching usually gives the biggest drop, because the server stops rebuilding the page every time. After that, a CDN helps most when your visitors are far from your server.

Leave a Reply

Your email address will not be published. Required fields are marked *