Comment réduire le temps de premier octet ou le temps de premier chargement
J'ai développé un site joomla 3.2. Je l'ai testé avec webpagetest.org et j'ai obtenu les résultats suivants
First Byte Time-F
Keep-alive Enabled-A
Compress Transfer-A
Compress Images-A
Progressive JPEGs-F
Cache static content-A
Effective use of CDN-yes
lien pour le résultat - http://www.webpagetest.org/result/140205_RX_DE5/1/details/ www.webpagetest.org/result/140205_RX_DE5/
J'ai activé le cdn sur mon site. Maintenant, je veux réduire le temps d'octet sur mon site, car je reçois F en temps sur un octet. Comment puis-je améliorer les performances de mon site? Et, comment puis-je convertir des images en images progressives car j'ai également obtenu F en JPEG progressif?
Voici le lien vers mon site - http://www.guru99.com
S'il vous plaît aidez-moi à améliorer les performances du site.
J'avais environ 0.8/1s ttfb avec hébergement mutualisé. Transféré vers VPS a changé de service d'Apache à nginx et PHP-FCGI
N'était pas encore assez. TTFB était 250/400 A recherché sur Internet pendant 3 jours. Sans aucun résultat, en réduisant ttfb.
Jusqu'à ce que j'ai trouvé ceci: http://help.directadmin.com/item.php?id=567
OpCache m'aide à réduire ttfb à 0,12/0,2 ms pour mon site joomla.
Je dois admettre que votre question m'a inspiré et que j'ai passé les deux derniers jours à l'optimisation. Après des tests extrêmes, j'ai obtenu le temps du premier octet à B. Pour ce faire, j'ai fini par utiliser le plugin JCH Optimize . En ce qui concerne les paramètres, j'ai tout mis en oeuvre en combinant CSS et JS, ce qui a entraîné une erreur de console.
Cela réduisait le temps de chargement de la page d'un montant tarifaire. J'ai également activé l'option G-Zip dans la configuration globale de Joomla. Cependant, j'ai désactivé la mise en cache intégrée de Joomla, car cela peut causer des problèmes avec certaines extensions.
En ce qui concerne les images, toutes les images .jpg que j’utilisais, j’ai ouvert dans Photoshop et CTRL + Shift + ALT + S et sélectionné l'option " progressive ". Une fois fait et téléchargé, j’ai refait le test et obtenu un A pour JPEG progressif .
Essayez de faire de même et voyez quel est le résultat. J'espère que cela t'aides
Comme mentionné, il s’agit principalement de deux choses, votre serveur et votre application.
Vous semblez être sur une adresse IP/hôte partagée à Hivelocity, cela affectera donc votre TTFB. Pour un hôte partagé, cependant,
619 ms First Byte Timen'est pas horrible. Rappelez-vous qu'unAn'est que de 192 ms, donc obtenir unFreprésente une demi-seconde de plus.Vous utilisez un modèle basé sur la structure Gantry, qui est probablement l'un des plus lourds pour les modèles Joomla (bien qu'aucun des fournisseurs commerciaux Joomla ne soit vraiment léger). RocketTheme fournit sa propre extension de cache à utiliser avec ses modèles. Vous voudrez peut-être essayer cela bien que je ne sois pas sûr de l'impact que cela aura sur le reste de vos statistiques.
Pour les clients qui en ont besoin, nous mettons en place des serveurs Web et des bases de données dédiés, c’est-à-dire des machines distinctes pour chaque fonction, ce qui vous permet de pousser beaucoup plus loin Joomla. Pour les applications internes non Joomla que nous avons créées, nous avons essayé HHVM avec de bons résultats (HHVM a toujours un quelques problèmes en suspens avec des projets plus volumineux).
Pour le JPEG progressif, nous utilisions auparavant Optim , il s’agit également de GitHub .
La chose à retenir est que TTFB est juste une métrique (et IMHO une sans valeur) la métrique la plus importante est la page prête. Jetez un œil à ce post de CloudFlare .
Je suis d'accord avec l'utilisateur cppl que TTFB n'est pas nécessairement une mesure significative et qu'il allait créer un lien vers le même article sur Cloudflare . L'article souligne ce point: "Du point de vue de l'utilisateur final, TTFB est presque inutile ... en fait, il est corrélé négativement avec le temps de téléchargement: plus le TTFB est mauvais, meilleur est le temps de téléchargement."
Dans la plupart des cas, placer votre balise sur la page le plus rapidement possible pour que l'utilisateur puisse l'examiner pendant que d'autres fichiers se chargent en arrière-plan est un bon moyen de donner à l'utilisateur le sentiment que votre site "fonctionne" correctement, même si un dev peut juger les performances selon des critères légèrement différents.
Pour répondre à votre question sur l'amélioration des performances du site, j'ai exécuté votre site via YSlow et découvert quelques éléments susceptibles d'améliorer les performances du site du point de vue de l'utilisateur final:
- Il existe des demandes HTTP pour 26 scripts JavaScript externes et 15 feuilles de style externes. Avez-vous envisagé de combiner au moins certains d'entre eux dans moins de fichiers? Un grand fichier .js peut être préférable à plusieurs petits fichiers .js, et la même chose avec les fichiers CSS.
- Déplacez vos fichiers javascript au bas de votre page d'index (juste à l'intérieur de la balise body) au lieu de les charger dans l'en-tête du document. Dans certains cas exceptionnels, vous aurez peut-être besoin d'un fichier .js particulier à charger avant le balisage de la page, mais dans la plupart des cas, il est judicieux de charger javascript au bas de la page, afin de pouvoir afficher le balisage sur la page en premier. .
- Réduisez vos fichiers javascript et CSS lorsque cela est possible.
TTFB est lié principalement à 2 choses: Votre serveur et votre application.
Le serveur peut avoir des problèmes qui causent un TTFB élevé, par exemple, il peut avoir des règles de pare-feu complexes ou des problèmes de routage. Vous devrez vérifier auprès de votre société d'hébergement.
En ce qui concerne la réduction de la TTFB pour Joomla, assurez-vous d’activer la mise en cache (attention, la mise en cache de Joomla est payante).
Si votre page Web récupère une énorme quantité de données, vous devez différer le chargement de celles-ci à l’aide de ajax ou de panneaux de mise à jour. Cela réduira certainement le TTFB.