Quin és el moment de desviar-se i com millorar-lo al vostre lloc web de WordPress

Potser heu escoltat la frase Temps a primer byte però d’alguna manera el concepte sembla escapar a algunes persones. Ja sigui perquè sembla increïblement orientat a la tecnologia o perquè sembla un concepte abstracte, no tan important per a l’ús quotidià. Res podria estar més lluny de la veritat.


Time to First byte no és realment un concepte o una idea que només la gent de tecnologia hauria d’entendre. Tothom hauria de poder comprendre el seu sentit i aplicar-lo a la pràctica.

En aquest article us explicaré en poques paraules: què és Time to First Byte, com afecta això al vostre lloc i per què heu de prestar molta atenció en aquest tema si voleu oferir als vostres lectors la millor experiència possible a l’hora de navegar pel vostre lloc.

Què és el temps de First Byte?

Time to first byte (TTFB) és una mesura utilitzada com a indicació de la resposta d’un servidor web o d’un altre recurs de xarxa.

TTFB mesura la durada des de l’usuari o client que realitza una sol·licitud HTTP fins al primer byte de la pàgina que rep el navegador del client. Aquest temps es compon del temps de connexió de socket, del temps que s’envia per enviar la sol·licitud HTTP i del temps que s’obté per obtenir el primer byte de la pàgina. Tot i que de vegades es mal entès com a càlcul post-DNS, el càlcul original de TTFB en xarxes sempre inclou la latència de la xarxa en la mesura del temps que triga un recurs a començar a carregar-se..

D’aquí ve l’explicació “techie” directament Viquipèdia. Traduïm això a un de més senzill que serveixi a tothom.

Time to First byte és el temps que triga a presionar aquest botó per carregar un lloc web fins al moment en què es comença a presentar. Si parléssiu en termes de jocs, el temps a primer byte seria semblant a la “latència” o “retard” que teniu mentre feu jocs. La latència és una representació directa de la capacitat de resposta percebuda del vostre lloc.

Quins factors afecten el temps al primer byte?

El temps de subtes pot ser representat per diversos factors, però com que es tracta d’un article de WordPress, ho reduirem tot al que s’està afectant quan WordPress estigui al seu lloc..

  • Temps de resposta DNS
  • Configuració i rendiment del servidor (PHP i servidor web)
  • Plugins / Tema de WordPress
  • Cache HTML activat / desactivat

Tots i cadascun d’aquests factors afegeix una latència addicional fins al temps que triga el vostre lloc a començar a presentar-se. Això significa que tot suma. No és això alguns d’aquests factors poden afectar la latència, tot d’aquests factors contribueixen a una major latència! Així que podeu suposar que per a un escenari ideal, tot hauria de ser ràpid per obtenir un temps molt bo al First Byte i si alguna cosa d’aquesta cadena triga més temps a processar-se, el vostre temps final al First Byte patirà..

Això és important perquè Time to First byte afecta tot el que feu o els vostres lectors al vostre lloc. Cada cop que un lector fa clic en algun enllaç, imatge, publicació de bloc o pàgina, es tindrà en compte Time to First Byte. Podeu veure que un mal temps a First Byte significarà que el lector tindrà una situació similar a un jugador connectat a un servidor deficient. Cada clic tindrà un retard considerable i això afectarà l’experiència.

Nota: A partir d’aquest moment, faré servir l’acrònim TTFB per indicar Time to First Byte només per accelerar una mica les coses.

1. Temps de resposta del DNS

La resolució DNS és el primer factor de l’equació. Sempre assegureu-vos d’utilitzar bons servidors DNS i que tenen nodes repartits per tota la paraula per obtenir la millor resolució possible. Una bona manera de reduir TTFB en aquest pas és utilitzar un bon servei global com CloudFlare com aquest tipus de servei s’implementa Memòria cau DNS global. Aquest mètode és extremadament bo per reduir el TTFB mitjançant la memòria cau de resolucions addicionals.

2. Configuració del servidor

El segon pas de la latència TTFB és el servidor real. Aquí és on s’aconsegueix el vostre allotjament. El tipus de configuració del servidor web que utilitza i les tècniques de memòria cau ho faran reduir molt TTFB. Per exemple, si el vostre servidor implementa l’antic intèrpret de PHP 5.4, obtindreu un TTFB molt elevat, mentre que l’ús d’una configuració moderna de PHP 7.1 reduirà aquest temps en un factor de 2 o més.

Això és degut a que l’intèrpret de PHP juga un paper important en el procés. Cada vegada que demaneu una pàgina web o una publicació de bloc que sigui sense cobrir, el servidor ho haurà de fer processar els fitxers PHP en qüestió per convertir-les en format HTML al vostre navegador. Com més complexos siguin els fitxers PHP, més temps es necessita per processar-los prèviament i enviar-los al navegador.

Podeu veure que el rendiment del servidor també participarà de manera important en tot el procés. Com més ràpida sigui la CPU i més recursos l’assigna el vostre hosting, més ràpid processarà aquests fitxers i, per tant, el vostre TTFB serà més petit.

A més, si el vostre allotjament implementa una memòria cau PHP, es reduirà encara més a la segona sol·licitud, ja que proporcionarà una versió en memòria cau d’aquest fitxer en lloc d’haver de processar el fitxer PHP de nou..

Ara podeu veure que hi ha 2 tipus de negoci d’allotjament, els serveis generals (sense accés) i els serveis d’allotjament exclusius de WordPress que solen implementar una mecanisme de caché de PHP, reduint el TTFB en el procés.

3. Complements i tema de WordPress

El tercer pas de l’equació de TTFB és el vostre lloc real. Aquest és el factor més important i vaig a mostrar-vos per què.

Normalment, WordPress donarà al vostre allotjament diversos fitxers PHP per processar-los i, com més complexos siguin, més temps trigarà a processar-se. WordPress és servit per plugins i aquells plugins afegeix codi addicional al processament final de PHP, per tant, podeu tenir clar això més connectors tinguis instal·lats, més temps necessitarà que el teu hosting el processi i per tant, augmentarà el vostre TTFB.

Com menys, millor

Per regla general, menys plugins sol ser millor. Per descomptat, un complement poc codificat pot ser molt pitjor que deu complements codificats expertament o és possible instal·lar dos connectors que pugin en conflicte. Però, en general, condensar el nombre de connectors us facilita la gestió de les actualitzacions i millora la velocitat del vostre lloc. A continuació, es mostra un exemple d’una quantitat raonable de plugins per a una instal·lació.

Temps al primer byte: menys complements

Aquest següent exemple pot ser problemàtic (de nou, depèn parcialment del que hàgiu instal·lat).

Temps al primer byte: més complements

I, per descomptat, és probable que qualsevol cosa passada la barrera dels 30 plugins no sigui bona per a la vostra latència. Podeu estar segur que un lloc web amb més de 40 connectors tindrà un TTFB molt alt, fins i tot si està allotjat en un servei d’allotjament espectacular i us mostraré el perquè.

4. Memòria cau HTML

L’últim factor és el més important i està relacionat amb el mecanisme de caché decidiu implementar-lo a la instal·lació de WordPress. Tot i que hi ha diversos tipus de mecanismes de caché a WordPress, el més eficaç de tots és Cache HTML.

Tenir un bon complement com Activador de caché KeyCDN tindrà un impacte enorme en el TTFB, més encara que el propi hosting. Convertirà tots aquests fitxers en HTML de manera que una vegada que la memòria cau estigui activa, els lectors no hauran de passar pel preprocessador PHP del vostre hosting i serà només el servidor web en si responsable de servir el vostre contingut. Fins i tot podeu accelerar el procés encara més si decidiu fer servir un allotjament que inclogui nginx en lloc d’apache com a principal servidor web com us explico en aquest article.

Temps per cobrir els primers casos: per què és important

Ara deixeu-me mostrar-vos de què parlem. Els estudis de cas següents són exemples de la vida real de configuracions de llocs web en diversos servidors, amb un còmode resum de referència al final.

Un lloc web lent en un servidor lent

Tenir un lloc lent pot suposar un dolor per a TTFB i si no es preocupa d’un bon servei d’allotjament, haureu d’estar preparats per afrontar el pitjor resultat possible..

Temps al primer byte: lloc lent, rendiment lent del servidor

Analitzem aquest lloc en detall. Amb aquest propòsit, faré servir Pingdom Tools perquè és una eina excel·lent per deixar-vos veure el TTFB. El truc és obrir el programa detall a la primera sol·licitud feta al lloc.

Temps de primer byte: lloc lent, resposta del servidor lent

Com podeu veure, el lloc té un TTFB de menys de 4,2 segons! Això significa que passen 4 segons complets fins a obtenir cap indicació que el lloc web estigui realment disponible.

Ara multipliqueu aquest temps per tots els clics que feu al lloc i podreu veure el dolor que podria tenir un lector. Per descomptat, cal afegir TTFB al temps total que el lloc fa que es mostri. El resultat serà catastròfic per al rendiment ja que el lloc trigarà tant com sigui 7 segons per presentar de vegades pròpiament.

La combinació de diversos factors condueix a això. Un lloc web mal optimitzat sense un mecanisme de memòria cau, un servei d’allotjament molt lent i un intèrpret de PHP completament desfasat, que encara funciona amb PHP 5.4. Fins i tot quan el lloc utilitza el cloudflare com a mecanisme de memòria cau extern, no es pot fer res per millorar la situació, si el vostre lloc i el vostre allotjament no cooperen.

Un lloc web ràpid en un servidor mitjà

Anem a veure què passa quan posem un lloc molt ràpid en un servidor mitjà que utilitza Apache i PHP 7.1

Temps al primer byte: lloc ràpid, resposta mitjana del servidor

Amb un lloc que tingui menys de 10 connectors sense caché, el resultat és almenys 5 vegades millor que l’anterior. Podeu veure que TTFB ara s’estableix en 521ms. Això vol dir que el lloc trigarà 0,5 segons a començar a presentar-se al navegador, des del moment en què va des del servidor fins al moment en què arriba al vostre ordinador..

Temps al primer byte: lloc ràpid, resposta mitjana del servidor 2

Què passa quan activem la memòria cau en aquest lloc web? La màgia passa. Un servidor generalment mitjà que funciona amb Apache pot donar excel·lents resultats amb només 152ms de TTFB. Podeu veure quant a bon caché de WordPress mecanisme que afecta els resultats.

Un lloc web molt lent en un servidor ràpid

Ara anem a veure el contrari. Què passa si posem un lloc molt lent en un servidor molt ràpid.

Temps al primer byte: lloc lent, resposta del servidor ràpid

Un servidor optimitzat que executi Plesk amb nginx i PHP 7.1.11 trigarà 1,29 segons en mostrar un lloc ple de plugins (més de 27).

Temps al primer byte: lloc lent, resposta ràpida del servidor 2

Però, quan activem la memòria cau a WordPress mitjançant el bonic enclavador de caché KeyCDN, el resultat és increïble. El lloc molt lent fa que el TTFB es redueixi a només 400ms.

Un lloc web ràpid en un servidor ràpid

Ara anem a veure la situació òptima. Un lloc web ràpid que s’executa en un servidor ràpid.

Temps al primer byte: lloc ràpid, resposta del servidor ràpid

El mateix servidor que estava donant un TTFB d’1,29 segons en un lloc lent respon en menys de 500ms en un lloc ràpid sense caché.

Temps al primer byte: lloc ràpid, resposta ràpida del servidor 2

Si activem la memòria cau, els resultats són simplement increïbles. Un servidor ràpid, combinat amb un lloc web ràpid i amb caché activat proporciona menys de 150 ms de TTFB!

Resultats de referència

Anem a veure els resultats en un gràfic gran per als amants de la referència.

Benchmarks de temps a primer byte

Podeu veure que l’allotjament té un paper important a l’hora de reduir el TTFB i millorar la latència i el rendiment percebut del vostre lloc, però el que feu amb el lloc té més impacte en el rendiment..

Embalatge

Si tingueu una bona mètrica de TTFB, us garantireu que disposeu d’un lloc ràpid i sensible, reduïu el temps de representació general i us proporcionarà una excel·lent mètrica per determinar el rendiment. Normalment, com més elevat sigui el TTFB, més lent serà el vostre lloc. Tenir en compte TTFB quan feu referència al vostre lloc és primordial, ja que aquest temps també es pot utilitzar per determinar els colls d’ampolla a la instal·lació de WordPress. Podeu fer un exercici senzill simplement desactivant tots els complements i canviant a un tema bàsic i després mesureu el TTFB. Els resultats us sorprendran.

Vull acabar aquest article dient que aquesta no és en cap cas la “mètrica única per regir-los”, ja que hi ha altres factors a considerar, com ara el rendiment de la base de dades, l’amplada de banda disponible i la velocitat de la xarxa. Però, com que TTFB sol afectar tots aquests factors, és una bona indicació de colls d’ampolla en qualsevol altre lloc.

Esperem que aprofiteu per experimentar amb el TTFB. Deixa els teus comentaris a continuació. Ens encantaria saber sobre les teves pròpies proves o ajudar-te amb les preguntes que puguis tenir.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map