How to Reduce Time to First Byte on Canadian Hosting: A Core Web Vitals Guide

Time to First Byte (TTFB) is the elapsed time between a browser sending a request to your server and receiving the first byte of the response. Google's Core Web Vitals framework targets a TTFB under 800ms for a good score, with anything above 1800ms classified as poor. For a Canadian business website targeting Canadian visitors, TTFB is one of the most actionable performance metrics because many of its contributing factors are under your control at the hosting level, not the application level.

What contributes to TTFB and which parts you can fix

TTFB is the sum of three components: network latency (the physical travel time of the request), server processing time (how long your server takes to generate the response), and any queuing time (how long the request waited before processing began). Network latency is determined by the distance between the visitor and the server, which is why Canadian hosting on a Toronto server serves Canadian visitors with lower TTFB than US hosting does. This baseline advantage is already baked into your TTFB if you are on Canadian hosting. The components you can improve are server processing time and queuing.

Full-page caching: the highest-impact single change

For a standard WordPress or PHP site without a cache, every visitor request triggers a full PHP execution cycle: load the PHP interpreter, execute the application code, run multiple database queries, assemble the HTML response, and deliver it. For a cached site, the server reads a pre-built HTML file from disk and delivers it directly, skipping every step in between. The processing time difference between an uncached PHP request and a cached HTML delivery is typically 200 to 1,500 milliseconds. That difference maps directly onto TTFB.

On a shared hosting or VPS with Apache, WP Rocket or W3 Total Cache with disk-based full-page caching brings WordPress TTFB from a typical 400 to 800ms range down to 50 to 150ms for cached requests. LiteSpeed Cache is more effective still when the server runs LiteSpeed Web Server, because the cache is served at the web server level before PHP even starts. If your Canadian hosting runs LiteSpeed (which many shared hosting plans do), LiteSpeed Cache is the right plugin choice for maximum TTFB reduction.

Database query optimization for WordPress

Even with full-page caching enabled, logged-in users (customers viewing their account, admins working in wp-admin, WooCommerce checkout sessions) bypass page cache and hit PHP and the database on every request. For these requests, database query performance is the primary TTFB driver. Install the Query Monitor plugin temporarily to see how many database queries each page generates and how long they take. A well-optimized WordPress page should complete in under 30 queries. Pages that run 100 to 200 queries almost always have a plugin doing something inefficient, like running a query inside a loop or fetching all posts to count a category rather than using a count query. Identifying the two or three heaviest queries through Query Monitor and addressing them (deactivating the offending plugin, or replacing the query with a more efficient approach) often cuts cached-bypass TTFB in half.

PHP-FPM socket vs TCP connection

When Nginx or Apache communicates with PHP-FPM, it can use either a TCP connection (connecting to a local IP and port) or a Unix socket (a file-based communication channel). Unix socket communication is faster because it skips the TCP stack entirely and communicates through the kernel's socket interface. On a VPS where Nginx and PHP-FPM run on the same server, configure PHP-FPM to listen on a Unix socket and update your Nginx site configuration to use the socket path instead of 127.0.0.1:9000. The latency reduction per request is small (1 to 5ms typically) but it adds up under concurrent load and requires no trade-offs.

Web server configuration for lower TTFB

Enable HTTP/2 on your web server if it is not already enabled. HTTP/2 uses a single multiplexed connection for multiple requests rather than opening a new TCP connection per request, which reduces the connection overhead that contributes to TTFB for pages with many sub-requests. On Nginx, add http2 to the listen directive. On Apache with cPanel, HTTP/2 is managed through the Apache configuration in WHM. Ensure keep-alive is enabled to prevent TCP connection teardown and re-establishment between requests from the same browser session. These settings are typically correct by default on well-configured Canadian VPS installations but worth verifying.

Measuring TTFB accurately for Canadian visitors

Browser DevTools and Google PageSpeed Insights measure TTFB from the geographic location of the test runner. PageSpeed Insights runs from a US data centre, so its TTFB reading for your Canadian site reflects US-to-Canada latency rather than Canadian-to-Canada latency. To get an accurate TTFB reading from a Canadian perspective, use WebPageTest.org with a Canadian test location selected (Toronto is available), or use a monitoring service with Canadian probe locations. GTmetrix allows you to select Toronto as a test location. These Canadian-origin measurements give you the number your actual Canadian visitors experience, which is the number that matters for your Core Web Vitals field data collected through Google's Chrome User Experience Report.