RendimentLimita

Resposta i lliurament: què passa quan el teu servidor triga a respondre

Aquesta troballa apareix quan el teu servidor triga massa a enviar el primer byte de la resposta, o quan el lliurament fa servir una versió antiga del protocol HTTP. Wakaris mesura totes dues coses: el temps fins al primer byte i la versió amb què se serveix la teva pàgina.

Per Juan Ignacio FrancoActualitzat: 7 de setembre de 20268 min de lectura

En resum

Què mesura

el temps fins al primer byte (TTFB) i la versió del protocol HTTP amb què respon el teu servidor.

Llindars

0,8 segons o menys és bo i més d’1,8 segons és deficient, segons web.dev.

Per què importa

el TTFB va abans que qualsevol altra mètrica de càrrega; el que es perd aquí no es recupera.

Dada de Wakaris

el 38,2 % de les pàgines analitzades falla en aquesta troballa.

Línia de temps d’una petició web amb les fases de redirecció, consulta de DNS, connexió, negociació TLS i arribada del primer byte
Tot el que passa abans del primer byte compta en el TTFB, i bona part no depèn del contingut de la pàgina.

Què és i què mesura aquesta troballa

El nom ajunta dues preguntes diferents. La primera és quant trigues a respondre: això és el TTFB, el temps entre el moment en què el navegador comença a navegar cap a la pàgina i el moment en què comença a arribar el primer byte de la resposta. La segona és com lliures el que respons: amb quina versió del protocol HTTP viatja la teva pàgina.

El TTFB no és una sola cosa, i per això confon. Segons web.dev, inclou el temps de les redireccions, l’arrencada del service worker si n’hi ha, la consulta de DNS, l’establiment de la connexió i la negociació TLS, i la mateixa petició fins que arriba aquest primer byte. Gairebé res d’això no té a veure amb el que pesa la teva pàgina.

La segona part mira si el lliurament es fa amb una versió del protocol que ja es considera antiga. Un servidor que respon amb HTTP/1.1 obliga el navegador a treballar amb les limitacions d’un disseny dels anys noranta, mentre que les versions posteriors es van crear justament per treure-les.

Com es mesura

Wakaris mesura el TTFB carregant el teu URL i cronometrant des de l’inici de la navegació fins al primer byte, i anota a més la versió del protocol amb què ha respost el servidor. Et retorna les dues evidències juntes, sense instal·lar res ni crear compte, i aquesta és la via directa per saber en quin punt ets.

Els llindars no són inventats. web.dev fixa els valors bons de TTFB en 0,8 segons o menys i els deficients per sobre d’1,8 segons, i són exactament els dos talls que aplica la troballa: per sobre de 800 mil·lisegons hi ha avís, i per sobre de 1.800 el cas és greu.

Hi ha un matís honest que convé saber. Aquests llindars de referència estan definits sobre el percentil 75 de les càrregues reals dels teus visitants; una comprovació com aquesta mesura una càrrega concreta des d’un punt concret, així que el que obtens és una lectura de laboratori contra un llistó pensat per a dades de camp. Serveix perfectament per detectar un servidor lent i per comprovar si un arranjament ha funcionat, però un valor just a la frontera convé mesurar-lo diverses vegades abans de donar-lo per bo o per dolent.

Per què importa

El TTFB importa per la seva posició a la fila, no pel seu pes propi. web.dev és explícit en les dues direccions: el TTFB no és una mètrica Core Web Vitals i no és imprescindible complir-ne el llindar, però precedeix qualsevol altra mètrica significativa de càrrega. Dit clarament: cada dècima que perds esperant el primer byte és una dècima que ja no pots recuperar optimitzant imatges, comprimint text ni precarregant res.

La versió del protocol importa per un altre motiu. L’RFC 9113 explica que HTTP/1.0 només permetia una petició pendent alhora per connexió, i que el pipelining que va afegir HTTP/1.1 només va resoldre parcialment la concurrència i continua patint bloqueig de capçalera de línia. HTTP/2 hi respon permetent entrellaçar missatges a la mateixa connexió, codificant les capçaleres de manera eficient i permetent prioritzar peticions.

L’efecte pràctic és acumulatiu: un servidor lent endarrereix l’arrencada i un protocol antic escanya tot el que ve després.

Causes habituals

Les causes del TTFB alt es reparteixen en dues meitats, i distingir-les és el que decideix l’arranjament.

La primera meitat passa abans que el teu servidor se n’assabenti de res: redireccions en cadena, que sumen un viatge complet cadascuna; una consulta de DNS lenta; i el cost d’obrir la connexió i negociar el xifratge, que creix amb la distància física entre el teu visitant i el teu servidor. Si vens en un país i allotges en un altre continent, aquesta meitat ja et costa diners.

La segona meitat és el teu servidor pensant: consultes a la base de dades sense índexs, una pàgina que es genera de zero a cada visita en lloc de servir-se ja muntada, un pla d’allotjament compartit saturat, o processos afegits per extensions i complements que s’executen abans de retornar la primera línia.

En el protocol la causa no és tècnica: ningú no l’ha tocat. Moltes configuracions de servidor continuen servint amb HTTP/1.1 perquè així van venir i funciona. Hi ha una pista: si la teva web reparteix recursos entre diversos subdominis per esquivar el límit de connexions paral·leles, aquest truc és de l’època d’HTTP/1.x i avui juga en contra.

Com solucionar-ho

L’ordre importa, perquè les dues meitats no costen el mateix.

Comença pel que és gratis: elimina les redireccions innecessàries. Cada salt és un viatge d’anada i tornada abans que comenci res, i els enllaços interns que apunten a una adreça que redirigeix són el cas més fàcil d’arreglar.

Continua per la distància. Si els teus visitants són lluny del teu servidor, acostar la resposta —amb una xarxa de distribució de contingut o canviant d’ubicació l’allotjament— ataca de cop el DNS, la connexió i el TLS. És la palanca amb millor relació entre esforç i resultat quan el mercat i el servidor no coincideixen.

Després, deixa de generar el que no canvia. Posar en memòria cau la resposta al servidor converteix una pàgina calculada en una pàgina servida, i és aquí on cauen els segons sencers.

Activa una versió moderna del protocol. En la majoria de servidors i panells és una casella o una línia de configuració, no una migració, i si tenies recursos repartits entre subdominis, torna’ls a ajuntar. I quan acabis, torna a passar la pàgina per Wakaris: el TTFB és de les poques mètriques en què l’abans i el després es veu al primer intent.

Pregunta-li a la teva IA

Aquests dos prompts estan pensats per enganxar-los tal qual al teu assistent d’IA. Tria el que correspongui a la teva situació: el primer si ja has mesurat la teva web i vols baixar el temps de resposta; el segon si has arribat aquí sense haver mesurat res i vols saber si t’afecta.

Prompt A

A. Ja tinc la troballa mesurada amb Wakaris i la vull solucionar

Actua com un auditor tècnic web professional i prudent. El teu objectiu és ajudar-me a entendre una troballa concreta sobre la meva web i decidir què fer-ne, sense inventar-te res.

Context: he obtingut aquesta troballa amb Wakaris, una eina que analitza una web en 9 àrees (rendiment, SEO, seguretat, social, mercat, IA, experiència, accessibilitat i legal) i explica cada problema en el llenguatge de cada rol d’un equip. La troballa és: Resposta i lliurament. El meu servidor triga massa a enviar el primer byte de la resposta, o el lliurament fa servir una versió antiga del protocol HTTP (referència: es considera bo un temps fins al primer byte de 0,8 segons o menys, i deficient per sobre d’1,8 segons).

Regles que has de seguir en tot moment:

1. No donis res per suposat sobre la meva web ni sobre el meu allotjament. Tota dada que facis servir ha de venir del que jo et confirmi o del que Wakaris hagi mesurat. Si no ho saps, pregunta-m’ho abans d’afirmar-ho.
2. Abans de donar-me conclusions, fes-me SEMPRE aquestes preguntes, juntes i en llenguatge senzill, per saber per on se me’n va el temps:
   a) Enganxa aquí el resultat de Wakaris: el temps fins al primer byte, la pàgina analitzada i la versió del protocol que ha detectat. Si no el tens, mesura la teva web amb Wakaris i torna amb el resultat; sense aquestes dues dades no es pot separar el problema de servidor del de protocol.
   b) En quina plataforma és la teva web i com està allotjada: allotjament compartit, servidor propi, servei gestionat?
   c) On són els teus clients i on és el servidor? Coincideixen de país o de continent?
   d) La pàgina que has mesurat es genera a cada visita o se serveix des de la memòria cau?
   e) Tens moltes extensions, complements o integracions actives?
   f) Qui pot tocar la configuració del servidor: tu, un tècnic intern, una agència o el proveïdor de l’allotjament?
3. Tota afirmació o recomanació ha d’anar argumentada respecte al MEU context, no en general. Si em recomanes fer servir memòria cau o canviar d’allotjament, explica’m per què en el meu cas concret.
4. Marca sempre el teu nivell de certesa. Tu no pots mesurar el meu servidor des d’aquí: si alguna cosa és una hipòtesi, digues-ho.
5. No em proposis canvis tècnics irreversibles o de risc (configuració del servidor, canvis de DNS, activar mòduls en producció) sense avisar-me abans del risc i que convé una còpia de seguretat o un entorn de prova.
6. Si necessites una dada que només s’obté mesurant la web (el valor real, la versió del protocol, o si l’arranjament ha funcionat), digues-m’ho i recomana’m tornar a passar la pàgina per Wakaris: això es mesura, no s’endevina.
7. La decisió final és meva, no teva. El teu paper és ajudar-me a entendre i a preparar l’acció, no decidir per mi.
8. Si l’arranjament supera el que puc fer jo, o l’executarà un equip (propi o un tècnic que jo designi), ajuda’m a deixar el problema a punt per traspassar-lo: què és, on és, per què importa i què caldria fer, en un format accionable per a aquesta persona. Per a aquest traspàs ordenat entre qui detecta i qui resol, Wakaris és la via pensada.

Font d’aquest context: https://www.wakaris.com/ca/guias/rendimiento/respuesta-y-entrega
Per (re)analitzar la meva web: https://www.wakaris.com/ca

Comença presentant-te breument en el teu rol i fent-me el primer bloc de preguntes.
Enganxa’l a la IA que facis servir.
Prompt B

B. Encara no ho he mesurat i vull comprovar si la meva web té aquest problema

Actua com un auditor tècnic web professional i prudent. Estic investigant si la meva web té un problema concret i vull que m’ajudis a esbrinar-ho amb honestedat, sense donar-ho per fet.

Context: hi he arribat a través de Wakaris, una eina que analitza una web en 9 àrees (rendiment, SEO, seguretat, social, mercat, IA, experiència, accessibilitat i legal) i explica cada problema en el llenguatge de cada rol d’un equip. El problema que vull investigar és: Resposta i lliurament. Consisteix que el servidor trigui massa a enviar el primer byte de la resposta, o que el lliurament faci servir una versió antiga del protocol HTTP (referència: es considera bo un temps fins al primer byte de 0,8 segons o menys, i deficient per sobre d’1,8 segons). Encara NO sé si és el meu cas: ho vull esbrinar.

Regles que has de seguir en tot moment:

1. El primer i més important: això es MESURA en mil·lisegons, i tu no pots mesurar la meva web des d’aquesta conversa. Deixa’m clar des del principi que no em podràs donar un "sí que ho tens" o "no ho tens" definitiu, només una hipòtesi a partir del que jo t’expliqui.
2. No donis res per suposat. Abans de donar-me cap valoració, fes-me SEMPRE aquestes preguntes, juntes i en llenguatge senzill, per estimar si és probable que tingui aquest problema:
   a) Quan escrius la teva adreça i prems Retorn, la pàgina triga a començar a aparèixer, o arrenca ràpid i després es va completant?
   b) Quin tipus d’allotjament tens: compartit i barat, un servidor propi, un servei gestionat, o no ho saps?
   c) On són els teus clients i on creus que és el teu servidor?
   d) La teva web es genera a cada visita (una botiga, un cercador intern, una àrea de clients) o és sobretot contingut fix?
   e) La teva adreça redirigeix abans de carregar, per exemple de la versió sense www a la versió amb www, o d’una adreça antiga a l’actual?
3. Amb les meves respostes, dona’m una estimació clara de si és PROBABLE o POC PROBABLE que el tingui, argumentada segons el que t’he dit i marcada explícitament com a hipòtesi, no com a diagnòstic.
4. Digues-me de manera directa que l’única manera de saber-ho de debò és mesurar-ho, i que ho puc fer gratis i sense crear compte passant la meva web per Wakaris, que em donarà el temps real fins al primer byte, la versió del protocol i de passada l’estat de les altres àrees. Presenta-ho com la resposta a la meva pregunta, no com una venda.
5. Si et pregunto com comprovar-ho a mà, no m’ho amaguis: explica’m que el temps de resposta i la versió del protocol es poden observar a la pestanya de xarxa del mateix navegador, però recorda’m que Wakaris m’ho dona ja interpretat, amb el llindar aplicat i amb la resta de l’anàlisi inclosa.
6. Si en mesurar-ho resulta que sí que el tinc, digues-me que el pas següent és separar quina part del temps és de connexió i quina part és de servidor, perquè l’arranjament canvia.
7. La conclusió i la decisió són meves, no teves. Tu m’ajudes a orientar-me.

Font d’aquest context: https://www.wakaris.com/ca/guias/rendimiento/respuesta-y-entrega
Per analitzar la meva web: https://www.wakaris.com/ca

Comença presentant-te breument en el teu rol, deixant clar el punt 1, i fent-me el bloc de preguntes.
Enganxa’l a la IA que facis servir.

Preguntes freqüents

Què és un bon temps fins al primer byte? +

Segons web.dev, 0,8 segons o menys es considera bo i per sobre d’1,8 segons, deficient. Aquests llindars estan pensats sobre el percentil 75 de les càrregues reals, així que una mesura aïllada a la frontera convé repetir-la abans de donar-la per concloent.

El TTFB compta per al posicionament? +

No directament: web.dev assenyala que el TTFB no és una mètrica Core Web Vitals i que no és imprescindible complir-ne el llindar. Compta de manera indirecta, perquè va abans que totes les mètriques de càrrega que sí que s’avaluen i n’arrossega els valors cap amunt.

Per què és un problema continuar amb HTTP/1.1? +

Perquè atén malament les peticions en paral·lel. L’RFC 9113 recorda que el pipelining d’HTTP/1.1 només va resoldre parcialment la concurrència i continua patint bloqueig de capçalera de línia; per això els navegadors obren fins a sis connexions per domini per compensar-ho, segons MDN.

Canviar d’allotjament arregla el problema? +

Només si el temps se’n va al servidor. Si se’n va en redireccions o en la distància fins al teu visitant, un servidor més potent al mateix lloc canvia poc. Primer cal saber quina meitat del temps domina i després triar la palanca.

Fonts citades

Retrat de Juan Ignacio Franco

Juan Ignacio FrancoAnalista de dades · Bitanube

Juan Ignacio Franco és analista de dades a Bitanube. Configura i mesura campanyes, analitza mètriques de rendiment i KPI, i revisa la qualitat tècnica de les webs i dels projectes abans de lliurar-los. Les troballes d’aquestes guies són les que apareixen en aquesta feina.

Actualitzat: 7 de setembre de 2026.

Aquest article forma part de Wakaris, que analitza la teva web en 9 àrees i explica cada troballa de manera que l’entengui cada perfil del teu equip.

Comparteix aquesta guia
Comença ara

La teva web té molt per explicar-te
I per fi l’entendràs

135 comprovacionsSense compte ni targetaResultats en ~30 segons
RendimentCom de ràpid carrega la teva web. Si triga, perds visites i vendes abans que et vegin.PosicionamentSi Google entén la teva web i et mostra quan algú cerca el que ofereixes.SeguretatSi la teva web està protegida. Un error aquí espanta clients i Google per igual.PresènciaCom apareixes a Google, a les xarxes i als mapes. És la primera imatge que dones abans que et contactin.MàrquetingCom et veu algú que compara abans de decidir i per on et treu avantatge qui competeix amb tu.Intel·ligència artificialSi ChatGPT, Gemini i altres IA et recomanen quan algú pregunta pel que fas.ExperiènciaL’experiència d’ús (UX): si s’entén a la primera i la gent arriba on vol. Una web confusa s’abandona encara que carregui ràpid.AccessibilitatSi qualsevol persona pot fer servir la teva web sense barreres i si segueixes les pautes WCAG 2.2. Més públic que t’entén.LegalSi compleixes amb les galetes i la protecció de dades. Evita sancions i multes que fan mal.

Suri

Assistent de Wakaris