Obres la web d’un proveïdor i la pantalla es queda en blanc un instant massa llarg abans que aparegui fins i tot el logotip. Aquella pausa inicial no és només «internet lent»: mesura el TTFB (Time to First Byte), el temps que triga el servidor a enviar el primer byte de la resposta HTML. El 2026, amb hosting compartit, CDN i APIs de contingut, continua separant una web d’empresa àgil d’una altra que sembla abandonada.
Aquest article explica què inclou el TTFB, quins llindars usar com referència, com es relaciona amb l’LCP, el CLS i l’INP, i quines accions concretes solen escurçar l’espera del servidor sense reescriure tota la web.
Què és el TTFB i què mesura exactament
El TTFB mesura l’interval des que el navegador sol·licita un document (normalment la URL de la pàgina) fins que rep el primer byte de la resposta. Inclou, de forma simplificada:
- Resolució DNS i establiment de la connexió (TLS en HTTPS).
- Temps de processament al servidor (PHP, plantilles, consultes a base de dades).
- Cua al hosting si hi ha saturació o límits de concurrència.
- Primer salt de xarxa fins a l’origen o el node del CDN més proper.
No és el mateix que la «càrrega completa» ni que l’LCP: pots tenir un TTFB acceptable i un LCP dolent si l’hero pesa massa, o un TTFB alt que retarda tot el demés encara que les imatges estiguin optimitzades.
La guia de web.dev sobre TTFB detalla com encaixa en el desglossament de temps de navegació i per què convé mesurar-lo en pàgines HTML, no només en recursos estàtics.
Llindars orientatius el 2026
No hi ha un «Core Web Vital» oficial només per al TTFB, però la comunitat de rendiment i eines com Lighthouse solen usar aquestes referències pràctiques per al document principal:
- Bo: per sota de 800 ms.
- A millorar: entre 800 ms i 1,8 s.
- Dolent: per sobre de 1,8 s.
Interpreta sempre el percentil 75 d’usuaris reals als teus mercats. Un servidor a Europa amb trànsit llatinoamericà pot mostrar TTFB alt al CrUX encara que a la teva oficina sembli ràpid. Compara inici, contacte i les landings que més leads generen.
TTFB davant LCP, CLS i INP
Els Core Web Vitals mesuren l’experiència percebuda quan el navegador pot pintar i interactuar. El TTFB és el preludi: si l’HTML tarda a arribar, el navegador no pot ni començar a analitzar recursos crítics, aplicar CSS ni reservar espai per evitar salts de layout.
Prioritza el TTFB quan PageSpeed assenyala «Reduce initial server response time», quan després d’un desplegament totes les URL empitjoren a la vegada, o quan el backend consulta la base de dades en cada vista sense memòria cau.
Causes habituals en webs d’empresa
- Hosting just mentre el marketing creix: CPU o PHP-FPM al límit en hora punta.
- Consultes N+1 o llistats sense índex en blog, catàleg o àrea de clients.
- Plugins o mòduls que executen lògica pesada en cada petició (geo, personalització, A/B).
- Sense memòria cau de pàgina o d’object en rutes que podrien servir-se gairebé estàtiques.
- TLS o xarxa mal configurats entre CDN i origen (revalidacions constants).
- APIs externes síncrones en el render (preus, estoc, CRM) que bloquegen l’HTML.
La compressió Brotli o Gzip redueix la mida transferida, però no substitueix un TTFB alt: el primer byte arriba després que el servidor hagi generat la resposta.
Com mesurar el TTFB amb eines accessibles
- PageSpeed Insights / Lighthouse: mètrica «Time to First Byte» a l’informe d’oportunitats.
- Chrome DevTools → Network: columna «Waiting (TTFB)» en recarregar amb memòria cau desactivada.
- WebPageTest: desglossament per fase (DNS, connect, SSL, TTFB) des de diverses regions.
- Search Console i RUM: correlaciona URL lentes amb caigudes de conversió en formularis clau.
- Monitorització d’uptime: alertes si l’origen respon 5xx o supera un llindar de latència.
Mesura sempre la URL del document HTML, no només el CSS o el JS. Repeteix la prova després de netejar memòria cau de servidor i de CDN per veure el pitjor cas real d’un visitant nou.
Accions que solen reduir el TTFB
Memòria cau de pàgina i de fragments
Activa memòria cau HTTP en rutes públiques (inici, serveis, entrades de blog estables) i memòria cau d’object per consultes repetides. Alinea el TTL amb el flux editorial: publicar un post ha d’invalidar només les claus necessàries. Complementa amb la memòria cau del navegador per recursos versionats, no per HTML personalitzat sense criteri.
Optimitzar backend i base de dades
Revisa consultes lentes, índexs en filtres de catàleg i eager loading en llistats. Evita treball en cada petició que es pugui moure a cua (correu, sincronitzacions). En Laravel o CMS similars, desactiva debug i autoload innecessari en producció.
CDN i connexió a l’origen
Serveix HTML estàtic o semi-estàtic des del vora quan sigui possible. Configura keep-alive entre CDN i origen, i evita que cada petició obri un circuit TLS nou. Si l’origen està lluny dels usuaris, valora regió d’hosting o preconnect només com complement, no com pegat a un servidor lent.
Retardar treball no crític
No bloquegis l’HTML esperant analytics, xat o mapes. Aplica la mateixa disciplina que en scripts de tercers: el que no és imprescindible per al primer pintat ha de carregar després.
Escalar infraestructura amb dades
Si el TTFB creix en hores punta però el codi està optimitzat, revisa límits de PHP-FPM, workers i pla d’hosting. Un upgrade puntual sol costar menys que perdre leads en campanyes de pagament.
Errors que mantenen el TTFB alt
- Confondre TTFB amb temps total de càrrega i només optimitzar imatges.
- Posar memòria cau agressiva en HTML amb sessió o preus dinàmics sense variar per cookie.
- Afegir «micro-optimitzacions» de front sense mesurar l’origen.
- Ignorar redireccions en cadena (301 mal planificades) que sumen latència abans del document final.
Checklist abans de tancar una millora
- Ha millorat el TTFB a DevTools amb memòria cau freda a la URL de l’HTML?
- WebPageTest des de la regió del teu client objectiu confirma la millora?
- LCP i CLS en les mateixes URL no empitjoren després d’activar memòria cau?
- Formularis i àrees privades continuen mostrant dades actualitzades?
Conclusió
El TTFB respon a una pregunta directa: «Quant triga el teu servidor a començar a parlar amb el navegador?». En una web d’empresa, cada centèsima de segon abans del primer byte retarda tot l’arbre de recursos i la confiança del visitant. Mesura en les URL crítiques, combina memòria cau sensata, backend afinat i infraestructura acord al trànsit, i revisa l’impacte juntament amb la resta de mètriques de rendiment.
Si vols prioritzar velocitat i Core Web Vitals amb impacte mesurable en conversió, a AATSOFT auditem origen, CDN i plantilles clau i proposem canvis acotats al teu stack actual.
