Qu'est-ce qui cause le temps d'attente avant le chargement de mon HTML?


12

J'ai un site Web qui semble se charger très lentement. Lorsque j'exécute un test de vitesse, je vois qu'il semble y avoir un écart de 6 secondes avant le chargement du HTML. Les images et les scripts JS se chargent très rapidement après ce point.

Vous pouvez voir sur la photo ci-dessous les barres jaunes "temps d'attente":

Le chargement du fichier HTML a pris plus de 5 secondes, tandis que la plupart des autres actifs se chargent en moins d'une seconde

Cela semble cohérent quel que soit le contenu HTML de la page.

Ce site utilise un CMS (ModX Revo) donc le HTML est réellement stocké dans une base de données SQL et mis en avant par PHP, mais je n'ai jamais rencontré ce problème auparavant.

Quelqu'un pourrait-il savoir ce qui cause cela et comment je pourrais l'accélérer?


Est-ce une nouveauté? Autrement dit, ces pages ont-elles fonctionné normalement auparavant et fonctionnent-elles maintenant mal? Ou s'agit-il d'une installation / d'un site plus récent? Pouvez-vous nous en dire plus?
closetnoc

1
À moins qu'il n'y ait un réseau intermédiaire qui retarde cela, alors cela semble être le temps que prend votre serveur pour générer la réponse? Vous dites "quel que soit le contenu HTML" - du contenu HTML via votre CMS, ou littéralement une page HTML statique? J'essaierais certainement une simple page HTML statique "Hello World" si vous ne l'avez pas déjà fait. Notez également que les serveurs de pingdom sont à l'autre bout du monde en Australie (qui, je suppose, est l'endroit où vous êtes hébergé)?
MrWhite

1
OMI, le problème est principalement lié à cette seule page - votre serveur / CMS semble prendre beaucoup de temps pour générer la réponse. Requête SQL inefficace ?? Les autres pages de votre site semblent relativement rapides. (?)
MrWhite

Réponses:


13

Le terme technique pour l'attente est considéré comme le temps du premier octet et détermine la réactivité d'un serveur Web ou d'autres ressources réseau.

Voici quelques raisons courantes pour lesquelles le délai de premier octet est élevé:

  • Réseau surchargé (hébergement normalement partagé)
  • Serveurs de mauvaise configuration
  • Distance de vous et du serveur (la géolocalisation joue un rôle mineur)
  • Erreurs de serveur (sauts)

Généralement, ce problème est souvent constaté dans l'hébergement mutualisé en raison de la grande quantité de sites Web et de personnes qui les visitent, ce qui augmente bien sûr le temps d'octet du réseau. Une autre cause possible est une erreur sur le réseau quelque part, comme un saut ou parce que votre serveur ne se trouve pas à l'emplacement de votre public cible, par exemple un serveur britannique «BON» aura un temps d'octet inférieur à celui d'un serveur américain ciblant des utilisateurs dans le Royaume-Uni, en raison de la distance à laquelle les données doivent être envoyées et reçues (normalement une augmentation d'environ 100-200 ms).

Peut-être un temps pour trouver un nouvel hôte

Dans le passé, je devais passer d'un serveur à l'autre en raison du décalage du temps au premier octet, vous pourriez être dans la situation d'avoir à choisir un nouvel hébergeur ou à mettre à niveau votre package actuel.

Des tests fiables

Tester la vitesse de votre site Web à partir de votre haut débit à domicile est très biaisé car cela peut être un problème avec votre haut débit qui ne répond pas au site Web. Vous devez tester votre site Web en utilisant plusieurs connexions à partir de plusieurs serveurs ... Je recommande le test de page Web et l'exécution de plusieurs tests à la fois à partir de différents emplacements et de nombreux dans le public géographique ciblé. Cela vous donnera un meilleur aperçu de ce qui se passe, si son premier octet, je vous recommande de contacter votre hébergeur avant toute autre chose.

Pinging et trace route le serveur

Si vous essayez d'exécuter un ping sur le serveur, les résultats peuvent s'afficher ou non, le ping utilise ICMP plutôt que UDP ou TCP, ce qui ne signifie pas qu'il interroge le serveur sur le port 80 sur lequel votre httpd s'exécutera. Vous pouvez utiliser trace route pour identifier les serveurs sur la route qui pourraient provoquer l'augmentation du premier octet, encore une fois ... il ne questionne pas le serveur httpd sur le port 80 et si traceroute utilise Windows, il utilisera ICMP et Mac / Linux les machines utiliseront UDP. Cela vaut la peine d'être testé parce que c'est une chose si rapide et facile à faire, mais si les résultats reviennent bien, cela ne signifie pas nécessairement qu'il n'y a pas de problème quelque part.


Bonjour @SunWKim J'ai mis à jour ma réponse avec ce que vous avez demandé. Regardez au bas de ma réponse.
Simon Hayter

Je suis d'accord sur vos raisons courantes pour le délai de premier octet. Dans ce cas, cependant; Je crois que cela a plus à voir avec le code JavaScript.
dim

Le premier octet peut être causé par un large éventail de choses, mais JavaScript n'en fait pas partie car la réponse de l'en-tête est avant les éléments en ligne tels que JavaScript, CSS, Images, etc. Ne confondez pas le premier octet avec les éléments et fichiers réels.
Simon Hayter

Je ne confond pas les deux. Peut-être que si vous avez visité mbff.com.au et avez vu par vous-même, vous pourriez être convaincu que ce n'est pas une question de temps pour le premier octet. Le retard se produit après la première réponse d'en-tête.
Dim

1
The delay is occurring after the first header responsealors ce n'est pas le premier octet. Le premier octet est la première réponse.
Simon Hayter

4

1) Vous avez Adobe TypeKit qui ne se charge pas de manière asynchrone avec le code actuel. Essayez de le remplacer par le code asynchrone avancé: http://help.typekit.com/customer/portal/articles/649336-embed-code

Ce code d'intégration standard tire parti du fait que les balises bloquent le rendu de la page pour empêcher le FOUT [Flash of Unstyled Text]. Pendant le chargement du script Typekit, le rendu de la page est bloqué, donc le texte ne commencera pas à s'afficher avec les polices de secours.

2) Testez avec le nouveau TypeKit. Comment est le temps de chargement maintenant? Mieux? Passez à l'étape 3.

3) Remplacez votre Google Analytics par un JavaScript mis à jour qui fournit la dernière syntaxe asynchrone: https://developers.google.com/analytics/devguides/collection/gajs/

4) Test. Le chargement de la page est-il encore meilleur?

5) Enfin, pensez à optimiser des images telles que pattern.jpg. Je l'ai converti en PNG et j'ai pu réduire la taille du fichier de 199 Ko à 56 Ko. Cela réduit le temps de réception du fichier: https://www.dropbox.com/s/i06jx509bmprhhh/pattern.png?dl=0

J'espère que ça aide.


3

Éléments PHP et éléments non PHP

Si vous comparez vos temps de chargement des actifs non PHP à vos temps de chargement basés sur PHP, vous verrez que le serveur répond rapidement si PHP n'est pas impliqué.

Cela indique généralement un problème interne à votre script PHP.

Le problème pourrait être dans la couche PHP ou la base de données. L'utilisation d'outils de débogage avancés comme XDebug ou NewRelic peut vous aider à repérer rapidement le goulot d'étranglement.

Les problèmes de délai avant le premier octet peuvent être causés par des contraintes matérielles, une mauvaise configuration ou un code inefficace. Sur l'hébergement mutualisé, les contraintes matérielles et une mauvaise configuration sont les plus probables.

Dans tous les cas, résoudre le problème signifie généralement un ou tous les éléments suivants:

  • Plus de matériel
  • Meilleure programmation
  • Ajouter la mise en cache

Un matériel plus rapide est une solution évidente mais souvent coûteuse si vous disposez déjà de ressources dédiées.

Une meilleure programmation peut ne pas être possible si le problème est interne au code que vous ne maintenez pas ou manque de ressources de développeur.

La mise en cache est utile en réduisant le nombre de demandes qui doivent toucher les ressources sous-jacentes et peu performantes.

Essai

Lorsque vous utilisez des outils de test, assurez-vous d'effectuer plusieurs exécutions. Les pics de réseau et de serveur temporaires peuvent facilement vous conduire sur le mauvais chemin, vous devez donc essayer de les moyenne.

Hébergement

Si vous êtes sur un compte d'hébergement partagé, envisagez de passer à des services de type cloud ou VPS afin de mieux comprendre les problèmes de performances. À moins que vous n'utilisiez une technique de mise en cache (service de type CDN ou Cloudflare), la correction des problèmes de performances sur les systèmes d'hébergement partagé de masse peut être très difficile car vous manquez de contrôle suffisant sur le serveur.


-1

Essayez de définir les cookies tiers comme visités uniquement.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.