Gtmetrix - Bien comprendre le Waterwall ?

[noren]

Bonjour

Je suis confronté à un problème de temps de chargement des pages de mon site un peu trop long selon le WGT entre 500 et 800 ms en moyenne. Ce qui me semble beaucoup trop

cela ne provient pas de mes requetes SQl, j'ai vérfié.

J'ai vérifié avec getmetrix et je constate ce waterwall :



Et a mon avis quelque chose cloche mais je n'arrive pas à voir quoi et pourquoi. Je ne sais pas interpréter ce tableau :?

Voici le tableau des temps de chargement sur le WGT :



On voit une grosse variation pouvant aller de 300ms à 800ms

Mais en gros je suis sur une moyenne de 700ms

 

[loubet]

le 1er graphique, ce sont tous les éléments de la page (html + images + javascript), donc cela dépend du temps de génération de la page html mais aussi du nombre de ressources nécessaires pour afficher la page.

le second, seulement la page html. les différences s'expliquent surtout par la charge du serveur, par d’éventuelles coupures à un moment qui font accroitre fortement le temps de génération des pages, donc la moyenne. après 700ms de moyenne, c'est déjà beaucoup.

 

[Madrileño]

Bonjour,

Cela ressemble à un problème d'optimisation de page.

Cordialement.

 

[noren]

@loubet : Ce que j'aimerais comprendre c’est pourquoi il y a ces longs temps de blocking (zones marrons clairs) avant de charger mes éléments (images etc.)

GTmetrics m'indique : Page load time 4.5s, total page size 269kg, request 30
Quand je compare avec d'autres sites dont WRI je suis très bien situé , il n'y a pas de problèmes apparents par rapport a ces valeurs
page speed score : 86%, yslow score :90%

@Madrileño : j'ai beau tourné viré je ne vois pas ce qui pourrait provoquer ces temps de chargement. mes images sont légères et optimisées pour le web, je charge mes scripts js en asynchrone en bas de mes pages, je n'ai pas 50 fichiers css et js et mon code html n'est pas très lourd.

C’est vraiment ennuyant de n'avoir aucune piste lorsqu'on a un problème, et de ne pas savoir ou chercher.

Et comme dit plus haut j'ai un log pour vérifier mes requêtes jugées lentes, et je n'ai aucun soucis.

 

[loubet]

si tu charges des scripts en asynchrone, et que ces scripts nécessitent de nouvelles ressources, le chargement de ces ressources ne commencent qu'une fois que le script est exécuté, et non dès le chargement de la page. c'est donc normal.

 

[spout]

cela ne provient pas de mes requetes SQl, j'ai vérfié.

Ma voiture ne roule pas vite pourtant les pneus sont gonflés :lol:
:arrow: Il y a tant d'autres paramètres.

Je comprend ton désarroi, sur mon dernier site j'avais +/- 130 ms pour le GET "/", j'étais pas content, j'ai mis cache d'output dans Redis, résultat: +/- 40 ms
(cependant je charge bcp plus d'assets que toi et là c'est moins cool)

 

[DareBoost]

Hello,

" il y a ces longs temps de blocking" > Sur un nom de domaine donné, un navigateur web ne téléchargera (en général, cela dépend du navigateur et de sa version) pas plus de 6 requêtes en parallèle. C'est l'une des causes principale du blocking.
Le domaine sharding est une technique utilisée pour s'affranchir de cette limite en utilisant un sous domaine (ou plusieurs) pour les ressources statiques, mais vu ce qui est évoqué, cela ne me parait pas pertinent dans ton cas.

Sinon, je t'invite à utiliser www.dareboost.com, qui va bien plus loin que GT Metrix dans les recommandations apportées.

 

[noren]

alors, lorsque je fais pagespeed insights, pour une meme page, le temps de reponse serveur varie entre moins de 200ms et plus 800ms. Incomprehensible
A priori ca viendrait d'un probleme avant l'affichage de la reponse html : affichages des images, scripts etc. Donc je pense qu'il est inutile que je me penche de ce coté la. Le soucis doit venir du cote serveur. Mais ou exactement :/

Est ce que le fichier .htaccess peut provoquer ca en fonction des regles qu'on met?
peut etre un soucis au niveau de mon mvc perso dans sa structure mais je ne vois pas vraiment ce qui pourrait provoquer ca et surtout avec autant de variation.

J'essayerais deja de faire le test sur une simple page html sans traitement php et qui ne passe pas par mon mvc. Si ca deconne aussi, ca ne viendra pas de mon mvc.
Je pourrais faire le test que jeudi :/

Si vous avez des pistes que je pourrais tester ? sachant que je suis sur mutualisé

Avec dareboost ca m'indique que c'est la partie request/ traitement serveur qui rame et pas la partie response

Donc a priori inutile que je m'attarde sur l'optimisation des images' du code html, des scripts js, css ou encore sur de la cache coté navigateur. Le probleme est a la source :/
Je vais quand meme reduire encore le nombre d'images en utilisant les sprites css, mais ca sera uniuqment du bonus et ne rgelera pas mon probleme.

 

[spout]

sachant que je suis sur mutualisé

Ceci explique cela.
Quelle version de PHP ? (Les version plus récentes améliorent bien la perf)

 

[noren]

J'utilise la 5.6, la derniere
moi aussi je soupconne le mutualisé, car je vois vraiment pas ce qui peut provoquer de telle temps de chargement et aussi aleatoirement. Passer de moins de 200 ms a plus de 800 ca fait quand meme de grosses variations.

Dans le doute je vais quand meme faire plusieurs tests etape par etape avec mon mvc pour etre certain que ca ne vienne pas de mon code. Mais bon ce genre de soucis peut vite devenir galere a identifier. Je deteste les problemes qui paraissent aleatoires.
Peut etre aussi un soucis du coté du PHP-FPM sur ovh. Leurs offres performances me semblent pas trop au point. :/

 

[spout]

Si tu veux savoir si c'est ton code qui est lent et la cause, Xdebug a un profiler intégré.

 

[noren]

Xdebug sur mutualisé n'est pas possible, et le test doit etre fait sur le serveur. En local pour des soucis de performances ca ne sera pas suffisant (les conditions ne sont pas du tout les memes). Je ferais des test a l'ancienne. Mais il y a plusieurs points qui me laissent penser que c'est vraiment un probleme du coté d'ovh

Je vais essayer de retirer des regles sur le htaccess (juste par precaution)
Virer le php fpm ( pas impossible que ca vienne de la)
Et verfifier etape par etape mon script. Mais a priori ca vient pas de la, jàvais une page simple qui passait meme pas par mon mvc et qui pourtant depasse aussi parfois les 500ms (testé avec pagespeed insights)

Depuis 2-3 ans je suis de plus en plus decu par la qualité du service chez ovh :/

 

[spout]

Xdebug sur mutualisé n'est pas possible

Je sais mais tu px faire tourner ton script en localhost pour ces tests.

 

[noren]

Le truc, c'est quand localhost je ne suis pas configure pareil que sur les mutualisé. Donc les tests en local ne seront pas vraiment concluant. Mais apres ca coute rien d'essayer.

Ce qui pourrait justifier que ca vient d'ovh et pas de moi c'est qu'on dirait qu'acertains moments de la journée c'est bcp plus rapide qu'a d'autres. Lorsqu'il y a un probleme de script et de conception generalement, c'est tout le temps.

Quoi qu'il en soit, a l'ancienne a coup de var_dump, backtrace, microtime... J'espere pouvoir identifier le pb si il y en a un. Je pourrais faire des essais seulement vers jeudi et vous tiendrez au courant :wink:

Ps: bon il semblerait que le soucis ovh soit confirmé, je viens de voir une tache dans les travaux d'ovh concernant un soucis de charge sur mon filerz. Et c'est vrai que ce matin en faisant des pages speed je ne constate pas de pb. A suivre

 

[noren]

Bon je ne comprend pas.

Il semblerait que la réponse serveur soit beaucoup plus longue lorsque je n'ai pas reçu de visite depuis 2-3 minutes (ce qui évidement est souvent le cas vu que mon site est jeune avec quasi aucun visiteurs).
Sinon si j'ai visité une page il y a moins de 2-3 minutes et que je la revisite elle répondra en moins de 200ms..

- Je me suis penché à nouveau sur un éventuel problème de requêtes mysql (et de cache mysql sur le serveur) en baissant mon niveau d'alerte pour les slow query. J'ai mis 0.02 s comme niveau d'alerte. Et aucun soucis.

- Je me suis dit que ça pouvait venir de la cache PHP-FPM. Que je le désactive ou non, même soucis.

- Il ne s'agit pas d'un soucis côté "cache navigateur" étant donné qu'il s'agit d'un problème de temps de réponse niveau serveur...

- Ca aurait pu éventuellement être un pb de CDN, mais il n’est pas activé sur mon site. :roll:

Donc pour l'instant je n'ai pas avancé d'un poil. Je continuerais mes tests demain. Mais si jamais vous avez une piste ? ( Il y a peut être une explication lorsqu'il s'agit d'un hébergement mutualisé ? )