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

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":

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?

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.

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.

É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.

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