Réduire les délais d'attente au temps de rendu des pages Web?

Question

J'ai effectué quelques tests sur mon site Web à l'adresse webpagetest.org et bien que le temps au premier octet soit inférieur à 200 ms, il semble que dans tous les tests que j'ai exécutés dans différents navigateurs situés à différents endroits, la page s'affiche à l'écran beaucoup plus tard. La première page HTML a été complètement téléchargée.

J'ai fait un test sous firefox depuis New York en utilisant leur connexion native et cela montre que le rendu commence à 600 ms, mais que le premier octet téléchargeable (TTFB) est prêt à 100 ms:

Voir: http://www.webpagetest.org/result/150614_G7_KR7/1/details/

J'ai ensuite essayé d'essayer chrome à partir du même ordinateur avec les mêmes paramètres. TTFB est à peu près le même mais le rendu commence à 350 ms:

Voir: http://www.webpagetest.org/result/150614_56_KTJ/1/details/

Je décide alors d'essayer IE 11 de Californie avec d'autres paramètres identiques. TTFB est un peu plus long que prévu, mais le rendu refuse de démarrer avant 600 ms:

http://www.webpagetest.org/result/150614_T3_KYC/

Mes pages sont gzippées et je vide les tampons entre la sortie des en-têtes HTTP et la sortie des données de la page Web.

Je vais essayer d'augmenter le niveau de compression, mais s'il y a autre chose, je peux faire côté serveur pour voir immédiatement la première page chargée au lieu d'attendre que les navigateurs décident quand ils sont prêts et prêts à l'afficher.

De plus, si vous voyez la vue en pellicule de chaque test, vous verrez mon problème sans répit, car rien ne s'affiche à l'écran avant 500 ms.

Je m'excuse si cette question finit par être mise en attente, mais je pense que c'est un problème qui a besoin d'une solution, et je suis sûr qu'au moins une autre personne a eu des résultats similaires avec leurs sites Web.

Tim Fountain · Accepted Answer

Cas intéressant, car la page est assez simple. Tout d'abord, je suis d'accord avec le commentaire de closetnoc sur le fait que votre page est déjà assez rapide - il est clair que vous avez passé du temps à travailler sur la vitesse, de sorte que tout gain supplémentaire sera au mieux une micro-optimisation. (Un DNS plus rapide serait certainement utile, comme vous l'avez dit.)

Mes pages sont gzippées et je vide les tampons entre la sortie des en-têtes HTTP et la sortie des données de la page Web.

Je suppose que vous voulez dire par la suite que vous êtes à la fin de la section HTML <head>? Il n'y a pas beaucoup d'avantages à envoyer uniquement les en-têtes HTTP du navigateur.

'Flush early' est donné comme conseil général, car il permet aux navigateurs de commencer à récupérer les ressources externes spécifiées dans la section <head> en attendant que le reste de la page HTML soit téléchargé. Mais puisque vous n'avez aucune ressource externe liée dans le <head>, et que votre page est téléchargée en 10ms, je ne m'inquiéterais vraiment pas pour cela.

Je vais chercher à augmenter le niveau de compression

Votre page HTML est 5Kb (compressé). En augmentant le niveau de compression, vous économiserez au mieux quelques octets. En outre, l’augmentation du temps de calcul requis du côté serveur peut avoir un effet négatif.

En supposant que vous souhaitiez améliorer encore cette fonctionnalité, vous constaterez que le navigateur est occupé à "exécuter des tâches" entre la réception de la page HTML et le rendu, et qu'il n'y a pas de ressources externes, en attendant, tout ce que vous pouvez faire est d’essayer de rendre la page plus simple à afficher. Je suggère deux choses:

Vous avez beaucoup de CSS pour une page avec une mise en page assez simple (environ 50% de la source HTML). Peut-être cela peut-il être simplifié? Il était une fois les guides nous auraient dit de jeter un coup d'œil à l'utilisation de sélecteurs CSS plus efficaces (en évitant des choses comme #mp DIV DIV A et #mp DIV DIV), mais ceci ne semble pas être vraiment un problème ces jours . (Et je vois que Page Speed Insights ne suggère plus de regarder cela.)
Vous avez quelques lignes de javascript en ligne, dont l'objectif semble permettre aux annonces Google de se charger le plus tôt possible (de manière invisible), puis d'être placées dans la bonne position. Au lieu de cela, il peut être préférable de scinder votre annonce Google JS afin que l'appel async adsbygoogle.js se trouve dans la section <head> et que la balise ads <ins> apparaisse à l'endroit où vous souhaitez les rendre. Ensuite, vous pourrez vous débarrasser complètement de votre JS en ligne et des règles CSS associées.