When the marketing department talks about Core Web Vitals, it usually means Google rankings. That is only half true. For a mid-market store, page speed is above all a conversion lever and only after that a ranking signal. The customer does not see your Lighthouse score. They see that the product page loads in one second instead of three, and they reach the cart more often.
This article explains the three Core Web Vitals metrics in plain language and then goes deeper into the one number that governs the rest: TTFB. We will show what drives it, why we aim below 200 ms and what specifically to do on Shopify Plus, PrestaShop, WooCommerce and Sylius. At the end you will find a checklist to go through in your own store today.
Core Web Vitals in one paragraph: LCP, INP, CLS
Core Web Vitals are the three metrics with which Google describes real user experience — measured not in a lab, but on real traffic from your customers' browsers. They are worth knowing, because this is the language in which performance is discussed with both the technical team and the board.
LCP — how quickly the most important content becomes visible
Largest Contentful Paint measures how long it takes for the largest content element to appear on screen: usually the product photo or the heading. It is the metric closest to what a user would simply call "the page has loaded". Target: below 2.5 seconds. Above 4 seconds the customer starts wondering whether to go back to the search results.
INP — how quickly the page responds to a tap
Interaction to Next Paint measures the delay between a click and a visible reaction from the page — a menu opening, an add to cart, a product variant opening. In 2024 it replaced the older FID metric and it is considerably more demanding, because it covers the whole processing time and not just the first reaction. Target: below 200 ms. High INP is most often the fault of overly heavy JavaScript — an overloaded browser main thread.
CLS — does the content jump under your finger
Cumulative Layout Shift measures how much the page layout moves during loading. Everyone knows the moment: you are about to click "buy now" and at the last second a banner loads in and you click something else. Target: below 0.1. The culprits are usually images without reserved dimensions, ads and late-loading fonts.
These three metrics describe what you can see. But before the browser starts rendering anything at all, it has to receive the first byte of the response from the server. And this is where a number comes in that is not on the official Core Web Vitals list, yet decides whether the others have any chance of turning out well.
TTFB: the number off the list that governs all the rest
TTFB (Time to First Byte) is the time from the moment the browser sends a request to the moment the first byte of the server's response comes back. It consists of several stages: the DNS lookup, establishing the TCP connection, negotiating TLS encryption, and then — usually the largest, controllable part — the time in which the application server actually builds the response.
TTFB is not one of the three official Core Web Vitals metrics. It is something more important: it is their foundation. LCP cannot be faster than TTFB, because content cannot be rendered before the first byte arrives. If the backend needs 900 ms to generate the HTML, an LCP below 2.5 seconds is still achievable, but you are fighting for it with one hand tied behind your back. If the backend responds in 150 ms, all the remaining front-end optimisation has something to work with.
Every millisecond of TTFB is a millisecond that LCP will never get back. Optimising the front end on a slow backend is painting the grass green.
That is why in technical audits we treat TTFB as the first measurement, not a footnote. It tells you whether the performance problem lies on the server side or in the browser — and where to start at all.
Field data, not data from your laptop
One trap ruins most conversations about TTFB: measuring it in the wrong conditions. A Lighthouse result on your laptop, connected to the company fibre with a warm cache, is lab data — useful for debugging, but useless as a picture of reality. Google assesses a page on the basis of field data, that is real measurements from users' browsers, collected in the CrUX report. These are two different numbers and they regularly diverge.
The practical conclusion: measure TTFB where your customers are, on the hardware and connections they actually use, and on the first, uncached hit. A single measurement is an anecdote — you need a distribution, and people usually look at the 75th percentile, because that is what decides the assessment and how many customers are actually waiting. Continuous real user monitoring (RUM) will tell you what a one-off test never shows: that TTFB rises during peak hours when the database is under load — which is exactly when you lose the most carts.
What really drives TTFB
When TTFB is high, the cause almost always falls into one of four areas. It is worth knowing them by name, because "the site is slow" is a useless diagnosis — whereas "the backend renders the product page in 700 ms because the catalogue runs 40 unindexed queries" is not.
Backend time and database queries
This is the most frequent culprit in mid-market stores. The application code builds the page: it fetches the product, prices, availability, recommendations, cart data. If it does so inefficiently — the classic N+1 problem, where a loop over 30 products fires 30 separate queries, missing indexes, heavy queries on statistics tables — backend time grows linearly with the catalogue. In one of our legacy projects, queries against the monolithic database could take several seconds each. No CDN will fix that, because the problem is in the code and the database schema.
Cache — at every level
Cache is the cheapest way to lower TTFB, because the fastest query is the one you do not run. It works at several levels at once: OPcache keeps compiled PHP bytecode so that the code is not compiled on every request; object cache (Redis, Memcached) keeps the results of repeated database queries; full-page cache (e.g. Varnish) serves ready HTML for anonymous traffic without touching the application at all. A store without an object cache usually repeats the same queries thousands of times a day.
Hosting and the PHP version
Shared hosting for PLN 30 a month and a dedicated server with correctly configured PHP-FPM are two different TTFB worlds. The number of PHP-FPM workers, the available CPU and I/O, and the PHP version itself all translate directly. Jumping from PHP 7.4 to 8.2 often means several dozen milliseconds recovered without a single line of code changed — newer versions simply execute the same code faster.
TLS, the network and a CDN
The TLS handshake and the physical distance to the server cost too. A customer in Kraków connecting to a server in Frankfurt pays a tax on every kilometre. A CDN shortens that distance by serving content from a node closer to the user, and modern protocols (HTTP/2, HTTP/3, TLS session resumption) reduce the overhead of establishing a connection. For static content, and sometimes for the whole HTML, that is several dozen milliseconds for free.
Why below 200 ms is the right target
Why 200 ms exactly? Because that is the threshold at which the backend stops being the bottleneck. Below 200 ms the server hands over the first byte practically immediately and leaves the entire remaining time budget — those 2.5 seconds for a good LCP — for what the front end actually influences: images, fonts, JavaScript. It is an engineering target, not a marketing one: it gives the team a buffer instead of forcing it to make up losses from the first millisecond.
The other side of the coin is financially hard. In our projects and in industry data, a TTFB above 500 ms correlates with a 5–10% drop in conversion. This is not a linear fall in Google rankings — these are customers who close the tab before the page responds. For a store doing several dozen million złoty in annual turnover, those few percent are an amount at which investing in Redis and query optimisation pays back in weeks, not years.
To be honest: not every store should drop everything to go from 250 to 180 ms. If your real problem is high INP due to overloaded JavaScript, or poor LCP due to uncompressed hero images, that is where your money is, not in the backend. That is why the order is always the same: first measure where the milliseconds are actually leaking, and only then invest. But if TTFB regularly exceeds 500 ms, it is almost certainly your cheapest and fastest-paying improvement.
A TTFB below 200 ms is not about boasting a number in a report. It is a time budget you hand back to the customer — and to conversion.
Bogart Meble: proof that this is not theory
Specifics instead of theory. In the migration of the Bogart furniture store from 12-year-old legacy (PHP 5.4, a custom framework, a monolithic database) to Symfony 6.4, the starting point was database queries taking several seconds each. The product page load time, measured as LCP, was several seconds.
After rewriting the logic, adding Redis as a cache and session layer, moving product search out to Elasticsearch and optimising queries, LCP fell to below one second — several times faster. There was no magic in it and no single silver bullet: there was an object cache where the same queries were being repeated, improved queries with indexes and relieving the database of operations that do not have to block page rendering. The business effect after three months: a clear rise in conversion (in combination with a new checkout). We described the whole case in our projects.
Concrete steps, platform by platform
TTFB is optimised differently on each platform, because on each of them you control something different. Below is a map: where the bottleneck usually is and where to start.
PlatformTypical TTFB bottleneckThe first move with the biggest returnShopify PlusApp bloat and heavy Liquid; you do not control the serverAn audit of apps and third-party scripts, simplifying the templatePrestaShopNo OPcache, weak hosting, suboptimal queriesOPcache + PHP-FPM + full-page cacheWooCommerceNo object cache, plugin bloat, a slow databaseRedis as an object cache + a review of pluginsSylius / SymfonyDoctrine queries (N+1), no cache and no queuesRedis + query optimisation + Messenger for async tasks
Shopify Plus
On Shopify you do not touch the server — the HTML is served from the platform's global edge/CDN, so raw TTFB is usually good out of the box. Your bottleneck is elsewhere: in app bloat and in the template. Every installed app adds its own JavaScript, CSS and often external scripts; heavy, nested loops in Liquid can inflate rendering time. Steps: review the list of apps and remove the unused ones (bearing in mind that paid ones often cost USD 80–300 a month — bloat costs twice), defer third-party scripts, simplify Liquid and avoid loops over large collections. When the template hits its limits, the answer is Hydrogen — a headless front end in React rendered at the edge, giving full control over what loads and when. A realistic target for a well-executed implementation is Core Web Vitals 90+. More on the architecture on the Shopify Plus platform page.
PrestaShop
You host PrestaShop yourself, so TTFB is 100% in your hands — and that is good news. In order of biggest return: enable and configure OPcache (and check its hit rate), tune the number of PHP-FPM workers to the available CPU, enable the built-in Smarty template cache and asset combining (CCC), and for anonymous traffic add a full-page cache or Varnish. On the database side: find slow queries in the slow query log, add missing indexes, clean up bloated statistics and connection tables. Finally, make sure you are on PHP 8.x and on hosting that is not shared with a thousand other sites.
WooCommerce
In WooCommerce (that is WordPress plus a store layer) the biggest lever is the object cache. Adding Redis, which intercepts repeated queries — options, transients, product meta — can cut TTFB dramatically, especially since the cart and checkout cannot be fully cached and every database query counts there. The second front is plugin bloat: every plugin adds queries and entries in autoloaded options; review the list without sentiment and clear expired transients and an overgrown wp_options. The third: hosting. Managed hosting for WooCommerce with PHP 8.x, OPcache and PHP-FPM is a different level from a generic shared package. For anonymous traffic add a full-page cache; for logged-in users rely on a fast backend and an object cache.
Sylius / Symfony
With custom builds on Symfony you control everything — and the whole toolbox is open. Redis as a cache pool and session store is the starting point (that is exactly the move we made at Bogart). On the Doctrine side: track down N+1 queries, enable second-level cache where it makes sense, manage eager and lazy loading deliberately. Move heavy operations — sending emails, indexing, webhooks, ERP synchronisation — into queues via Messenger, so that the request returns to the customer immediately instead of waiting for work that can wait. On top of that the production basics that are easy to forget: APP_ENV=prod, an optimised autoloader, a warmed cache and OPcache with preloading. Product search is worth handing over to Elasticsearch so as not to load the main database.
Checklist: what to verify in your own store
A checklist to go through regardless of platform. If the answer at any point is "I do not know" — that is precisely where to start.
Measure TTFB in production conditions, from the locations of your customers, and not from the browser cache on your own laptop.
Check how long the backend rendering alone takes. Above 500 ms look for the cause in the database and the cache, not in the front end.
Make sure OPcache is enabled, and check its hit rate.
Add an object cache (Redis or Memcached) where the same queries repeat.
Find N+1 queries and slow queries in the slow query log; add the missing indexes.
Move heavy operations (emails, indexing, webhooks, synchronisations) into asynchronous queues.
Serve static assets — and if possible the HTML as well — from a CDN close to the customer.
Check the PHP version. A jump from 7.x to 8.x is often several dozen milliseconds for free.
Limit the number of plugins, apps and third-party scripts to those that really do work.
Set up continuous monitoring of TTFB and Core Web Vitals with alerts. Measuring once a quarter is not monitoring.
Summary
Core Web Vitals are not an SEO checkbox but a conversion lever — and TTFB is its foundation, because it governs everything that happens later on the page. Aim below 200 ms, treat 500 ms as an alarm signal, and look for the biggest returns where they always are: in the database and in the cache. The Bogart example shows that going from several seconds to under one second is not esoterica, but orderly engineering work.
If you want to know where exactly your milliseconds are going and how much they really cost in conversion, that is where we start every project — our store audit measures TTFB, LCP, CLS and INP in the context of your industry and your competitors, with a forecast of the impact on sales. We will gladly show you how it looks in your case — write to us via our contact page.