Vitesse du site / performance -> influence sur le SEO

[kawet]

Bonjour,

Alors que mon site est responsive et s'adapte bien pour les smart-phone, nous avons constaté une baisse de classement suite à la mise a jour de gg à ce sujet.
Les causes peuvent être multiples, mais je pense qu'il est possible que l'une d'entre elles soie une mauvaise performance du site pour les mobiles.
Avec Google PageSpeed, sur une page type, Google me donne 95/100 en expérience utilisateur, mais descend à 67 / 100 pour la vitesse mobile (83 pour les ordinateur), Alors que sur Gmetrix, j'obtiens A pour le test "page speed" et C pour "Yslow".

Question 1 : Ce 67 / 100 en vitesse peut-il expliquer une partie de la baisse du trafic ?

Ensuite, j'ai fait de nombreux tests sur un environnement de dev sur ce qui impacterait le plus ce score. Le point rouge que m'assène google est le suivant :Éliminer les codes JavaScript et CSS qui bloquent l'affichage du contenu au-dessus de la ligne de flottaison
Pour les js, j'ai trouvé comment résoudre le problème. Pour les css, c'est plus compliqué. je ne parviens pas à déterminer ce qu'il considère bloquant.

J'ai tenté l'expérience suivante:
j'ai injecté tous les css directement dans le html, (l'affichage ce fait ainsi instantanément après avoir téléchargé la page).
Le résultat est surprenant: un gain de plus de 25 points à la note total ! J'écope du coup de l'indication "alléger votre code html", forcément, mais pour google, c'est mieux!
Je pourrai crier victoire et m'arrêter à cette solution, plus quelques petits détails, j'arrive ainsi a 95/100 en vitesse. Mais je pense que c'est le contraire du principe d'une page web, qui doit s'afficher au fur et à mesure du téléchargement du contenu.

Il y a aussi le temps de réponse du serveur: il est énorme, entre 0.3 et 0.5s. je pensais qu'en le réduisant à 0.05 / 0.07 (ce que je considère comme un temps de réponse "normal"), je récupérerai beaucoup de points.
Après test, je ne récupère que 2 ou 3 points...

donc question 2 : l'outil de google est il fiable comparer a outils de Gmetrix?

Je pensais donc au compromis suivant: injecter la base des framework css dans le html, la base de mes propres styles, et le reste en source externe comme traditionnellement. Mais cela va quand même augmenter sensiblement la taille de mon flux html, qui pour moi doit être LE fichier le plus léger.

Donc questions 3 : passé d'un html de quelque ko à un html supérieur a 100 voir 150ko est-il une bonne idée, si cela permet un affichage dès réceptions du html comme le veut google ?

Merci d'avance pour vos éclaircissements !

 

[Bigb06]

Bonjour,

Sans connaitre l'url de votre site, difficile de répondre.
Quelques points à noter cependant :
- une mise à jour Google (Quality Update) a été déployée juste après la mise à jour Google Mobile. Cette mise à jour a été beaucoup plus importante, sur desktop et mobile.
- la vitesse influe à mon avis comme un critère secondaire : plus le site répond aux besoins des internautes, plus ils vont visiter de pages, revenir (ou ne pas aller ailleurs). Dans ce sens la vitesse va influer sur le positionnement puisque l'engagement utilisateur sera meilleur.
- Le site http://www.webpagetest.org/ est un bon moyen de tester votre site en "conditions réelles" en modifiant les paramètres de vitesse (par exemple mobile 3G) et le navigateur utilisé (IE à la place de Chrome).

 

[MikeR]

L'analyse GTMetrix me semble plus pertinente que PageSpeed google. Mais en définitive, une très grosse amélioration du temps de chargement n'a en rien influé sur le positionnement de la page, ni son traffic. Par contre, le RPM adsense a augmenté de 50% du jour au lendemain (pour revenir lentement sur 2-3 mois à sa valeur précédente).....

 

[kawet]

j'ai améliorer les perf de 15 pts en moyen, on sent la différence.
J'ai effectivement constater un plus grand nombre de page vue, mais du jour au lendemain c'est trop tôt pour parler ^^.

Je vais de ce pas me renseigné sur la quality Update. Si la vitesse est secondaire, je vais me limité à ces améliorations pour le moment et me concentré sur les autres points.

Autre chose, mais je devrais peut être ouvrir un autre post a ce sujet :
Dans web master Tool, j'ai une ogmentation constante d'erreur 404.
Nous avions procédé a une grosse refonte il y a 3 mois, et j'ai fait les redirections 301 qui s'impose. Je n'ai pas rediriger 100% des URL, celle ci aillant grandement changer, et aillant plusieurs millier de page. J'ai simplement rediriger toute les pages de destination des 3 derniers mois et sur le coup cela a fonctionné: aucune perte de trafic, voir même une améliorations.
Ce qui est étrange, c'est que les 404 que me trouve gg Webmaster sont des page référencé par d'autre page qui n'existe plus...
Plus étrange encore, ces url ne sont pas indexé par google (en tout cas pas de résultat si l'url est cherché).

J'ai donc travaillé a rediriger toute ces vielle URL, même si personne ne les empruntaient...
Cela peut il aussi avoir une influence ?

 

[zeb]

Si la vitesse est secondaire, je vais me limité à ces améliorations pour le moment et me concentré sur les autres points.

Chez moi j'ai des expériences qui me disent totalement le contraire, savoir que la vitesse de la page est un critère très important.
Concernant le CSS inline (à la place q"un unique fichier externe) c'est un mauvais choix car tu chargera le CSS a chaque page et tu ne profitera donc pas du "cache navigateur" qui est important côté utilisateur ...
Dans les critères "vitesse" il faut en revanche regarder deux choses :
* la vitesse de transfert de la page (document plus dépendances)
* la vitesse de rendu par le navigateur.

Si le premier point est "facile" à optimiser le second en revanche est moins évident avec les designs alambiqués.

 

[kawet]

Bon ba j'y retourne alors :mrgreen: .
Oui pour le css c'est bien ce qu'il me semblai ! Les score du gg Page Speed la dessus mon bien dérouté.
Mais d'un autre coté cela montre que pour google, la vitesse de rendu est presque plus importante que celle de téléchargement de la page !

Mais comment faire lorsque l'on utilise des framework tel que jQuery et foundation 5 ? à eux deux sa totalise dans les 300ko, et pas d'affichage possible ou presque sans eux...


Concernant les images, j'avais pensé a me tourné vers le lazy loading. (ne charger que les images qui sont dans le viewPort, au fure et a mesure du défilement). Sur certaine page j'ai plus de 20 ou 30 images, même si ce sont des vignettes optimiser, sans CDN je pense que sa peut être efficace.
J'utilise déjà l'interchange Responsive content de foundation.
Les images sont chargé en JS, mais j'avais lue que google ne pénalisais pas cette technique. Je commence a avoir des doute, qu'en pensez vous?

 

[zeb]

Mais comment faire lorsque l'on utilise des framework tel que jQuery et foundation 5 ? à eux deux sa totalise dans les 300ko, et pas d'affichage possible ou presque sans eux...

On vire et on code a la mano bienvenu dans le monde des vrais le web qualité c'est pas du légo ...

Concernant les images, j'avais pensé a me tourné vers le lazy loading. (ne charger que les images qui sont dans le viewPort, au fure et a mesure du défilement). Sur certaine page j'ai plus de 20 ou 30 images, même si ce sont des vignettes optimiser, sans CDN je pense que sa peut être efficace.

lazy loading > c'est pas mal niveau temps de rendu de page (je suis dans le même cas que toi avec parfois plus de 100 photos par page). Le CDN n'influe pas au même titre car il est censé délivrer les images a proximité géographique ce qui est un autre point visant a accélérer le chargement final de la page et son rendu. Les deux sont complémentaires mais pas remplaçables.

Les images sont chargé en JS, mais j'avais lue que google ne pénalisais pas cette technique. Je commence a avoir des doute, qu'en pensez vous?

J'ai mis une balise image réelle pleine définition en <noscript> pour chaque photo "lazy-loadée" le truc étant récent j'ai pas encore analysé l'impact. Toutefois je ne me base pas sur le viewPort pour cela j'affiche en mode normal systématiquement au moins 4 photos optimisées (servies a l'échelle, compressées comme il faut). Entre 4 photos et 50 ou 100 il y a de toute façon pas photo sur le gain obtenu. Si jamais les photos supplémentaires ne sont pas aussi bien prises en compte j'en ai au moins 4 qui sont candidates SEO de façon classique.

 

[NicolasWeb]

Mais comment faire lorsque l'on utilise des framework tel que jQuery et foundation 5 ? à eux deux sa totalise dans les 300ko, et pas d'affichage possible ou presque sans eux...

Sur les bons framework CSS il est possible de récupérer la version de développement et de compiler les CSS et JS avec uniquement ce qu'on veut à l'intérieur. Sinon il y a parfois un outil en ligne qui permet de générer un fichier allégé - c'est le cas chez Foundation je crois...

Cela permet d'utiliser ces composants tout fait et d'alléger grandement les dépendances.

Pour jQuery, vu que généralement on utilise que 2% de ce qu'il propose, on peut se tourner vers un équivalent plus léger (Zepto pour commencer et après il faut fouiller).

Sinon, on peut le faire à la main aussi c'est pas compliqué de ce faire une petit lib avec un sélecteur et deux trois fonctions qu'on utilise souvent. A ce sujet je rejoins totalement Zeb.

 

[kawet]

On vire et on code a la mano bienvenu dans le monde des vrais le web qualité c'est pas du légo ...

Pas du tout d'accord. Je suis plus dev backend que front et seul sur un énorme projet comme cela, je préfère m' appuyé sur de grosse communauté. Je n'utilise pas jQuery que pour faire du jQuery, mais pour les plugins développé avec (bien plus rapide a modifié qu'un plugin js pure). De plus, a moins que ce sois une priorité absolue, je trouve sa triste et régressif (voir un peut prétentieux ) de réinventé la roue dans le seul but des performances.

Pour moi, la programmation, c'est aussi une histoire de compromis, et rechercher une solutions a chaque problème, plutôt que de dire immédiatement qu'une technologie est inutilisable.

Mais c'est un tout autre débat

Pour revenir dans le sujet ^^:
Pour le CDN, je croyait aussi qu'il permettais également de délivré un plus grand nombre de fichier en parallèle (plutôt que 4 par 4 )?
Dans ce cas est-ce utile pour un site basé en france, avec 99.99 des visite venant de france ?

Merci pour les conseils sur le lazy loading.

Sinon il y a parfois un outil en ligne qui permet de générer un fichier allégé - c'est le cas chez Foundation je crois...

Yep, taille du js et du css de fdt réduit de 70% en ne gardant que ce que j'utilise, c'est a dire le 3/4 :mrgreen:

Pour jQuery, vu que généralement on utilise que 2% de ce qu'il propose, on peut se tourner vers un équivalent plus léger (Zepto pour commencer et après il faut fouiller).

Foundation a abandonné Zepto avec la version 5, et je suis un peut d'accord a eux: zepto a de bien plus mauvaise performance a l'exécution que jQuery, ce qui est problématique pour les téléphones. Et les plugins que j'utilise son sous jQuery...je sais je peut en trouver en js pure mais je vais pas me re-justifier
Par contre, je pense que je vais charger tout sa de manière asynchrone avec Modernizr, en retravaillant un peut le css je devrais avoir un affichage correct avant la fin du chargement du js.

 

[Bigb06]

Pour moi, la programmation, c'est aussi une histoire de compromis, et rechercher une solutions a chaque problème, plutôt que de dire immédiatement qu'une technologie est inutilisable.

+1 jquery ne pose pas forcément de problème une fois minifié et gzippé dans la majorité des cas.

Pour le CDN, je croyait aussi qu'il permettais également de délivré un plus grand nombre de fichier en parallèle (plutôt que 4 par 4 )?
Dans ce cas est-ce utile pour un site basé en france, avec 99.99 des visite venant de france ?

Je pense qu'il y a confusion entre CDN et multiples sous domaines ( https://developer.yahoo.com/performance/rules.html#split )
L'intérêt de proposer les ressources sur plusieurs sous domaines (ou noms de domaine) afin de maximiser le nombre de téléchargements en parallèle s'est grandement réduit car les navigateurs ont tous évolué et ont augmenté le nombre de ressources téléchargeables en parallèle, et le gain n'est pas toujours évident puisqu'il faut une résolution DNS supplémentaire. La encore tout dépend le projet.

Merci pour les conseils sur le lazy loading.

Pour le lazy loading, attention la encore a analyser si la page nécessite cette technique : si il y a beaucoup d'images et qu'elles ont une probabilité importante de ne pas être affichées car bas dans la page, c'est intéressant. Sinon...

 

[zeb]

Je suis plus dev backend que front et seul sur un énorme projet comme cela, je préfère m' appuyé sur de grosse communauté. Je n'utilise pas jQuery que pour faire du jQuery, mais pour les plugins développé avec (bien plus rapide a modifié qu'un plugin js pure). De plus, a moins que ce sois une priorité absolue, je trouve sa triste et régressif (voir un peut prétentieux ) de réinventé la roue dans le seul but des performances.

Je n'ai rien contre ta vision du problème ni contre tes méthodes qui sont effectivement les plus rependues (quantité qualité chacun a son opinion), mais tu mélange pas mal de choses et de problématiques différentes.
Je ne cherche pas non plu a te convertir, c'est pas le propos et j'en ai strictement rien a faire.
Ceci étant posé voila pourquoi je ne suis pas d'accord :

* "réinventer roue" doit être l'expression première apprise par tous les dev avec "hello world", c'est éculé dépassé et sans aucune valeur dans le cas présent. Mise en avant a l'heure de l'objet elle prend toute sa signification mais "copier coller" n'a rien a voir avec "réinventer la roue" là on est dans un cas plus précis : "prendre une pelleteuse pour déterrer une taupinière".

* "Je suis plus dev backend que front" j'ai envie de dire la belle affaire pour moi c'est simple on est dev ou pas point barre. les paradigmes du développement sont assez généraux pour ne pas souffrir de la destination du projet, donc soit on code soit on fait du légo mais faut pas chercher midi a 14 heures on se contente de brasser des datas et de les envoyer dans un tuyaux.
D'ailleurs pour avoir pratiqué dans plein de secteurs depuis la glorieuse époque des processeur 4 bits dans un peut tous les langages, le web est le parent pauvre du dev on peut pas dire que ce soit du hight tech c'est même assez "merdique" dans le principe.

* "je n'utilise pas jQuery que pour faire du jQuery, mais pour les plugins" bah oui tout est dit ... on parle d'optimisation, je met le doigt sur la structure légo qui est contre-productive en terme de performance et tu me parle de plugin. Entre guillemet l'expression "en remettre une couche" prend là tout son sens car si l'objectif est de gagner en performance faut justement virer les couches, les plugins etc ... Pour du code sur mesure. IL y a pas photo au pire fait un bench mais si tu vire du code générique lourd pour du dédié tu dois forcement y gagner sauf a coder comme un sac.

je trouve sa triste et régressif (voir un peut prétentieux ) de réinventé la roue dans le seul but des performances.

Triste peut être car c'est un sentiment qui n'engage que toi prétentieux j'en doute car c'est mesurable et indiscutable. Maintenant on peut aussi se contenter d'un compromis moyen tu a raison sur ce principe mais en ce cas ce qui est prétentieux c'est d'annoncer faire du performant, ou de parler d'optimisation, alors que c'est faut ou pas traité du tout. C'est un choix tu as raison, mais ce n'est pas une réalité.

dire immédiatement qu'une technologie est inutilisable.

Perso je ne pense pas avoir dit cela.

Pour le CDN, je croyait aussi qu'il permettais également de délivré un plus grand nombre de fichier en parallèle (plutôt que 4 par 4 )?
Dans ce cas est-ce utile pour un site basé en france, avec 99.99 des visite venant de france ?

Le CDN c'est la proximité géographique rien d'autre. Pour un site avec un rayonnement si faible (France) c'est inutile en effet sauf a dire que tu veux en mettre plein la vue a google en ayant un centre de data a côté de chez lui.

+1 jquery ne pose pas forcément de problème une fois minifié et gzippé dans la majorité des cas.

Moi je ne dis pas qu'il pose problème, je dis que le cumul de X fichier JS pose problème ... Même si accessoirement la pluspart des effets utilisés que je croisent sont faisable avec du CSS3 et/ou 50 instructions de JS natif.

Faut observer historiquement les OS pour se rendre compte ce que la philosophie de la couche génère comme soucis. Les machines de bureaux ne font rien de plus qu'avant pourtant elles sont de plus en plus pointues niveau hardware. mais comme le software augmente aussi vite bah t'as plus de confort mais pas plus de performance dans 80% des cas d'utilisation.
Les bibliothèques dans beaucoup de cas c'est de la gestion de patch par des intégrateurs mais pas des vrais codeurs ...

 

[indigene]

Mais comment faire lorsque l'on utilise des framework tel que jQuery et foundation 5 ? à eux deux sa totalise dans les 300ko, et pas d'affichage possible ou presque sans eux...

Tu peux essayer de charger les scripts à la fin du code, juste avant le /body

 

[kawet]

Désolé de répondre que maintenant : vacances vacances.

j'aime, ce sujet provoque toujours de houleux débat :mrgreen: .
Ne te fait pas de souci quant à me faire changer d'avis par contre, du haut de mes petits 4ans de dev je ne cherche qu'a apprendre encore et encore, tout opinion étant excellant à prendre, je jette rien moi .

Je ne vois pas en quoi l'adage "ne pas réinventé la roue" est "éculé et dépassé". Ni pourquoi elle "n'a aucune valeur dans la cas présent".

Oui, le web est le parent pauvre du dev, historiquement il était fait pour des non codeur, mais sa n'a pas empêchés les dev d'investir la place et c'est bien eux qui l'on fait évoluer jusqu’à maintenant, html5 /css3 et touti cuanti, sans eux IE serai encore a faire du cssIE, php serai encore une cuillère à soupe html, et les site web aurai encore des chatons et des sapin qui clignote en background.

Oui, ok, j'ai compris c'est rentré dans ma petite tête, si je veut de la mega perf, je doit hardcodé, pas de souci, je suis pas chiant moi.
Donc onn pousse tout dans le tuyaux comme tu dit: on se pose, on pousse et on tire la chasse, j'ai peut être mal compris le principe.
Je suis pas ironique, j'ai été convaincu sur ce point, en plus je suis pas du genre a remettre en place les ancien, je suis pas fou.

Mais je ne comprend pas pourquoi tu me parle de légo, la je comprend pas. J'ai un programme, je développe mes propres fonctions, mes propre classes, je cherche à suivre des principes, suivre des méthodologie et bouf de la doc jusqu'à l'indigestion.
Simplement mon programme puise dans l'existant, moi j'étais pas la au tous début mais il me semble que tout le monde fait sa depuis un bon bou de temps.

je ne fait pas de copier coller : Il me semble que la logique d'un langage c'est l'utilisation de fonction, de class, et de bibliothèque, ce que je fait justement.
dans n'importe quel autre programme, je pense que tu te sert de bibliothèque, nine ?
Si tu fait un soft avec de la 3d, en C par exemple, tu peut utilisé openGL une bibliothèque de rendu 3D, et tu va utilisé des module, selon ce que tu veut faire.


Mon peut d'expérience jusqu'ici me dit ceci :
Compromis, Compromis !
et dans le cas présent, j'avais une montagne a produire tout seul, donc il me fallait une pelteuse, même si elle creuse aussi dans le couscous et que moi je creuse dans la moutarde, il me la fallait.
Je vais même te faire hérissé les poi-poile sur la tête: coté serveur j’utilise Zend Framework 2 / Doctrine 2

Et puis autre exemple:
Prenons un prog web: il y a 10ans il se chargeai en 0.5s. maintenant prenons le même, il ce charge en 0.05s. Pourquoi ne pas profité de la hausse de patate?
Je peut maintenant faire 10 x plus de truck qu'il y a 10ans, ou codé 50 x plus vite. Voir les deux. Surtout les deux en faite =) . Bon ok il se charge pas en 0.05s, mais en 0.250s -> compromis !

Et c'est pour cela que je venait ici, au juste.

J'ai donc plutôt bien avancé: j'ai maintenant plus que entre 2 et 4 fichier pour chaque page, deux pour la base (jquery + foundation) qui ne totalise plus que 60 ko tout les deux compressé et gzipé, plus deux autre de quelque ko, avec les js/css spécifique a la page courante.

Merci indigene mais c'est déjà le cas =)

http://www.webpagetest.org me met des A partout sauf pour le serveur CND, mais du coup suite a vos conseil je m'en fiche,

Me reste à
- améliorer la vitesse de réponse du serveur, mais je sais d'ou sa vient donc y'a plus qu'a
- Accélérer la vitesse de rendu au dessus de la ligne de flottaisons.

Mais c'est sur à l'avenir, le poix d'un plugin serra pour moi un vrai critère de sélection, merci Zeb .

PS: désolé pour les fautes, je sais que sur un texte un peut long sa picote

 

[zeb]

Désolé de répondre que maintenant : vacances vacances.

Profite c'est sacré ;-)

Je ne vois pas en quoi l'adage "ne pas réinventé la roue" est "éculé et dépassé". Ni pourquoi elle "n'a aucune valeur dans la cas présent".

car tu est dans une démarche d'optimisation et de vitesse (c'est le titre) donc je vais au bout du truc. Après ...

Mais je ne comprend pas pourquoi tu me parle de légo, ... mais il me semble que tout le monde fait sa depuis un bon bou de temps.

Légo = assemblage de bloc de code (bibliotèques) donc contre productif niveau vitesse sauf a dire que ton code maison est plus mal foutu (plus gros et moins performant). les lenteurs du web c'est le réseau (goulet d'étranglement), donc vitesse = moins de data à faire transiter. Et puis pour le nombre de personne qui font ainsi c'est pas forcement une référence ;-) regarde depuis combiens de temps on se tape sur la gueule au lien de profiter de la planète et s'éclater en mode respect vacance ...

Si tu fait un soft avec de la 3d, en C par exemple, tu peut utilisé openGL une bibliothèque de rendu 3D, et tu va utilisé des module, selon ce que tu veut faire.

Oui mais dans le domaine web je ne trouve pas que ce soit pareil, on est sur du client serveur avec deux inconnus :
* la machine cliente (capacité)
* la qualité du réseau (vélocité)
Donc on ne parle pas du déploiement d'une solution logiciel dans un environnement contrôlé on parle de toucher même le trou du c*l du monde au mieux (bon certes tu est en France et tu vise la France).
Et aussi on parle de faire mieux que la concurrence qui elle pense souvent "légo".

Prenons un prog web: il y a 10ans il se chargeai en 0.5s. maintenant prenons le même, il ce charge en 0.05s. Pourquoi ne pas profité de la hausse de patate ?

Pour garder tes 0.05s et pas repasser à 0.5s en alourdissant avec la nouveauté sachant que par cette démarche tu te replace dans un niveau de performance d'il y a 10ans ... a Quoi bon mettre en jeu des serveurs plus puissant alors si c'est pour faire la même chose en plus coûteux ?

PS: désolé pour les fautes, je sais que sur un texte un peut long sa picote

Te tracasse pas pour ça en tous cas pas pour moi je respecte ça on ne peux pas être bon partout ;-) Seul les imbéciles lisent la forme sans comprendre le fond.

Tu vois un truc qui m'éclate avec un nouveau PC c'est de virer l'OS livré avec et de mettre ma vielle distribution (qui fait tout ce que je veux depuis des lustres) sur cette machine ... Du jour au lendemains je passe d'un voiture poussive et fatiguée a une formule 1. Là j'ai l'impression d'avoir claqué du fric pour qque chose ;-)

C'est aussi ce qui dicte mes changements de serveur, c'est pas forcement pour faire plus c'est pour faire ce que je fais mieux (quantité / qualité).

C'est amusant car on en parle en ce moment ici

 

[Bigb06]

les lenteurs du web c'est le réseau (goulet d'étranglement), donc vitesse = moins de data à faire transiter.

Faux c'est la règle d'or de l'optimisation web... 80% du temps est passé coté navigateur !

source : http://www.stevesouders.com/blog/2012/02/10/the-performance-golden-rule/

 

[zeb]

80% du temps est passé coté navigateur !

D'où l'importance de minimiser ... Accessoirement on parle de ce qu'on peut optimiser côté serveur et sur la ligne pas chez le client là on a aucun choix (la machine), soit on lui fait bouffer du mega soit on se contente de quelques kilo.

 

[Bigb06]

Zeb je t"invite à lire les bouquins de Steve Souders, il explique bien le problème. Même avec une page statique et un serveur local, le temps de chargement d'un site se passe à 80% coté navigateur. Ce qui implique chargement des fichiers, décompression, évaluation, reflows du navigateur...

 

[zeb]

Et tu défend que "plus de code" va arranger les choses ?
Quand on regarde justement les graphes de ton article plus on limite les ressources (en nombre et taille) plus on gagne du temps.
Après ce que le navigateur fait vite ou pas ça tu n'as aucun contrôle supplémentaire dessus (d'ou l'importance de lui en faire faire le moins possible).

Même avec une page statique et un serveur local, le temps de chargement d'un site se passe à 80% coté navigateur.

Bah là en supprimant le trafic réseaux forcement que le reste du temps consommé prend proportionnellement plus d'importance ... mais c'est pas une révélation c'est juste une évidence.

Tu cherche a expliquer quoi avec "le navigateur est lent" ? qu'il faut renoncer a toute optimisation ?

 

[Bigb06]

Pfff Zeb ce n'est pas agréable de discuter avec toi...
La génération d'une page et le téléchargement des ressources ne comptent que pour 20% du temps. C'est clair ?
Ce n'est pas moi qui le dit mais le chef de l'équipe d'optimisation Google qui était avant chez Yahoo! Qui a passé des années à se pencher sur le sujet, a pondu des dizaines d'études et 2 bouquins.

Donc les optimisations doivent se faire ailleurs !

Pas forcément besoin de passer du temps du coté de la base de données pour gagner quelques ms, alors qu'en optimisant la manière dont s'ont chargées les ressources peut faire gagner beaucoup plus !

 

[zeb]

Pfff Zeb ce n'est pas agréable de discuter avec toi...

Bah ça c'est ton ressenti j'y suis pour rien. Moi aussi il y a un tas de gens que j'ai envie de flinguer parfois
Je me doute bien que certains sont plus compatibles avec d'autres mais bon je suis pas insultant j'évite d'ignorer et je partage mon point de vu. Je te pose même des questions mais tu n'y répond pas en revanche j'ai l'impression que tu me répète trois fois de suite la même chose.
Me citer l'auteur ne changera pas grand chose.

La génération d'une page et le téléchargement des ressources ne comptent que pour 20% du temps. C'est clair ?
...
alors qu'en optimisant la manière dont s'ont chargées les ressources peut faire gagner beaucoup plus !

C'est exactement ce que je dis (ou pour le moins c'est exactement ce que je pense même si je le formule mal pour toi)
bien sur qu'il faut travailler les 80% les plus "bad" mais pour cela tu n'as accès qu'a ce qui se passe du côté des 20% (serveur et réseau), passé ce travail les 80% restant a faire pour que la page soit visible ne sont plus de ton ressort (tu charge pas un navigateur optimisé avec ta page).
Hors pour réduire ces 80% il faut envoyer le moins possible de choses (réduire le nombre de ressources nécessaires (cf "lazy loading" évoqué plus haut par exemple)) et faire en sorte qu'elles soient faciles à gérer chez le client (code concis et propre) Ce qui induit une démarche de minimisation et de simplification.

Si tu veux m'entendre dire "oui le goulet d'étranglement c'est le navigateur" tu va attendre longtemps car j'ai aucune option la dessus en tant que dev. En revanche si je veux prendre en compte se facteur pour gagner du temps et de la performance mes moyens sont réduire le trafic réseau et simplifier le code ...

Tu fait comment toi ? Autrement formulé tu propose quoi pour que le navigateur traite plus vite ta page ?

Reprenons ton exemple concret si tu veux bien :

et extrapolons de façon imaginaire ce que sont les ressources impactant le frontend pour se faire une idée. Ce graphe pourrait être une page quelconque qui charge son HTML (1er requête les 20% du travail serveur) partant de la le navigateur prend le relais pour charger les ressource utiles et nécessaires disons ensuite :
* un JS
* un CSS
* un truc (on peut imaginer une image par exemple > 333ms)
* un favicon (vu la taille c'est du pas lourd > 56ms)
* et disons une photo (479ms)
là tu est encore avant la ligne verte et tu n'as pas envoyé grand chose

Si on se met en contexte site pas optimisé tu en sera peut être encore a charger du JS mal foutu ou inutile, voir la Nième feuille de style (on vois ça ici tous les jours des pages avec 5 CSS 10 JS etc ...) voir aussi des JS externe pub etc ... et tu ne sera pas encore en mesure de commencer a effectuer un rendu dans le navigateur (pour lequel tu ne peux rien changer)

Bref si on s'arrête aux ressources avant cette pt1 de ligne verte là ça change tout ... Ton code applicatif (côté client) doit être pour cela concis et regroupé, ta feuille de style correctement faite (par exemple mentionner rapidement l'image de fond ou le logo). Le reste peut attendre ou sera superflu.

Vois tu autre chose ? Savoir que le gros du temps c'est rendre la page est une chose faire en sorte que cela soit léger en est une autre.
Accessoirement pour avoir passé des pages de 3s a moins d'une seconde je confirme que ça impacte les positions contrairement a ton "faux" lancé je ne sais plus ou a ce sujet.

edit >

Pas forcément besoin de passer du temps du coté de la base de données pour gagner quelques ms, alors qu'en optimisant la manière dont s'ont chargées les ressources peut faire gagner beaucoup plus !

Oui enfin ça dépend de ce que tu fait avec ta page ... faut pas généraliser je connais des cas ou une page est amenés a travailler avec plusieurs bases de données et sur des requêtes très lourdes et là le résultat peut passer de plusieurs secondes a quelques milisecondes en fonction de comment tu fait bref ... si parfois il y a du temps a gagner même beaucoup mais c'est sur que sur un WP c'est pas forcement le cas sauf a mettre ça en parallèle avec un site a très gros trafic et là ça change tout.

 

[kawet]

Bin dit donc entre l'un ou l'autre on en apprend des truck ^^

[...] ta feuille de style correctement faite (par exemple mentionner rapidement l'image de fond ou le logo). Le reste peut attendre ou sera superflu.

Si tout est regroupé en un seul fichier, l'affichage attendra la fin du chargement du fichier pour tout interpréter non ?

Autre chose :

Moi je n'est qu'un 1js et qu'un css. sa d'accord. Mais sur ma page, j'ai :
- une google map
- un pt google + pour la page
- un like fb pour la page
- un twitter la page

et aussi
- liker la page facebook du site
- suivre le site sur google +
- suivre le site sur twitter

Ce qui nous fait...une 10aine de de fichier js (principalement pour la gg map)! 4 ou 5 iframe ! Merci les gars !

Bon c'est charger de manière asyncrone okay, ne bloque pas l'affichage du rendu, okay, mais c'est foutrement long a chargé...

Doit on s'en inquiéter ?

 

[zeb]

Si tout est regroupé en un seul fichier, l'affichage attendra la fin du chargement du fichier pour tout interpréter non ?

Oui il faut que le CSS soit chargé pour que les urls d'images soit prise en compte et puisse être chargées. Elles vont alors s'empiler dans la liste des ressource nécessaires.
De la veille a l'ordre des ressources et regroupe quand tu peux (sprite).
Tu peux aussi tirer profit parfois d'images encodée base 64 qui ne généreront donc pas d'appel supplémentaire (petite taille)

Moi je n'est qu'un 1js et qu'un css. sa d'accord. Mais sur ma page, j'ai :
- une google map
- un pt google + pour la page
- un like fb pour la page
- un twitter la page
et aussi
- liker la page facebook du site
- suivre le site sur google +
- suivre le site sur twitter
Ce qui nous fait...une 10aine de de fichier js (principalement pour la gg map)! 4 ou 5 iframe ! Merci les gars !

Ca c'est une vrai remise en question intéressante car tu sort des sentiers battus.
Beaucoup de widgets sont en effet associés a des JS qui même chargés de façon différés ont un impact direct sur le rendu et sur le temps de rendu de la page, la pub est aussi de ce nombre même si son cas est différent car dans l'idée elle doit être là coûte que coûte car après tout c'est l'objectif financier.

Perso je part du principe que les widgets genre sociaux sont inutile au landing sur la page donc je les remplace par une image évocatrice (genre le logo du ou des réseaux) Cette image est gérée "minimum" donc petite éventuellement en base 64.
Pour les maps genre google tu peux aussi appliquer le même principe si elle n'est pas "LE truc de la page" (comprendre que la carte est un plus et pas seulement l'unique contenu de la page)

Ce que je fais c'est que je donne la possibilité a l'utilisateur d'accéder au widget sans qu'il soit là en gros si tu clique sur l'image de remplacement JS met en oeuvre le widget instantanément.
Pour ça je met un onclick sur l'image qui déclenche une routine JS qui elle charge le widget dans une iframe a moi qui est déjà dans la page.
En gros les codes fournis par google facebook et consort sont sur une page non indexable sur le serveur si tu clique sur le logo carte ou Facebook j'attribue à l'élément Source de mon iframe (déjà présente dans la page) l'url de ma page de widget en passant (en get) les paramètres utiles et nécessaires (généralement url de la page et son titre). Ma page non indexable reçoit les paramètres les mets en forme et les utilise dans le code des widgets. Les boutons se forment ainsi dans l'iframe de ma page.

L'avantage c'est qu'a l'arrivée sur la page tu gère des éléments simples genre image qui eux sont faciles a minimiser et a rendre. Tu ajoute une iframe que tu positionne là ou tu veux tes widgets tu peut aussi la réduire a 0/0px de taille car il est facile de la dimensionner au moment voulu. Donc vis a vis du rendu de page c'est light et rapide et ça s'arrête là car tu ne fait aucun appel a des serveurs externes (FB, GG) qui parfois "cumulent" genre 3/4 requêtes pour un bouton a la con, tu ne pose aucun cookie 1/3, tout viens de chez toi. Tu peux aussi éviter le chargement du script JS externe. Bref souvent tu gagne une 10aine ou une 20aine de requêtes externes.

Pour l'utilisateur c'est que du bonheur, il est pas fliqué a chaque page, il a rapidement son rendu et en plus il peut bénéficier de ses petits gadgets fétiches ... Note que vis a vis de la CNIL le fait de cliquer sur le logo du widget vaux consentement tacite a mon avis ... (mais bon ça peut se discuter)

Pour ce qui est des liens genre page google là on est dans un contexte html pur il n'y a rien a gagner puisque ça ne fait pas de requêtes externes ...

Au début j'ai testé ça car en phase d'optimisation d'un site j'en avais mare de voir les lignes qui te suggèrent de minimiser le nombre de requête et que ça me gavais de me retrouver avec un cookie Facebook a chaque page. Depuis je généralise ce principe. Le rendu de la page s'en ressent visuellement car j'ai plus de latence ou de reflux puisque je ne charge qu'une petite image sur la page. 9A demande une dizaine de lignes de JS environ et faut créer autant de script/page dynamiques sur le serveur que tu as de zone de widget ce qui n'est pas insurmontable.

 

[kawet]

O

Pour ce qui est des liens genre page google là on est dans un contexte html pur il n'y a rien a gagner puisque ça ne fait pas de requêtes externes ...

Ce n'est pas seulement les lien vers les pages mais bien les bouton qui permettent de liké la page facebook, google, ou de suivre le #tag du site sur twitter.

De la veille a l'ordre des ressources et regroupe quand tu peux (sprite).

Jutilise autant que je peut du css et pour les picto, ce sont des svg, spriter en un seul fichier Gros avantage si on veut une même picto dans différent code couleur, si le svg est bien fait on peut les manipuler en css.

Ce que je fais c'est que je donne la possibilité a l'utilisateur d'accéder au widget sans qu'il soit là en gros si tu clique sur l'image de remplacement JS met en oeuvre le widget instantanément.

ok j'avais penser a quelque chose comme sa, sans les iframe.

Mais du coup pas moyen d'afficher les compteurs tous de suite de cette manière, non ?
Je ne sais pas si sa influence ou non l'utilisateur. Mais hé, j'ai moi même parler de compromis ^^.

Dans tout les cas pas le choix ! j'ai jeter un oeil sur gg Analityics dans la rubrique "temps de chargement du page" et j'ai une hausse de 5s en moyenne depuis que j'ai mis en place les réseaux sociaux, qui corrobore quasiment a la baisse de trafic !!!


Si la baisse venait de la et que je parvient effectivement a retrouver un temps de chargement correct, combien de temps pensez vous qu'il faudra à google pour réagir et me redonner des "bon points" ?

 

[zeb]

Mais du coup pas moyen d'afficher les compteurs tous de suite de cette manière, non ?

Non tu ne les auras pas par le widget mais ils me semble que tu as de script php pour récupérer ça donc au pire si vraiment tu y tiens tu peux envisager d'aller chercher cette info par toi même.

Dans tout les cas pas le choix ! j'ai jeter un oeil sur gg Analityics dans la rubrique "temps de chargement du page" et j'ai une hausse de 5s en moyenne depuis que j'ai mis en place les réseaux sociaux, qui corrobore quasiment a la baisse de trafic !!!

J'ai connu l'inverse quand j'ai viré les grigris le gain a été au rendez vous.

Si la baisse venait de la et que je parvient effectivement a retrouver un temps de chargement correct, combien de temps pensez vous qu'il faudra à google pour réagir et me redonner des "bon points" ?

dépend du site si il est revisité souvent par les bots ou pas ...

 

[kawet]

dépend du site si il est revisité souvent par les bots ou pas ...

Tout les jours ils semblerai, d'après webmaster tool.

J'ai connu l'inverse quand j'ai viré les grigris le gain a été au rendez vous.

Encourageant !

Je fait tout sa et je vous tien au courant, sa serra une bonne info pour beaucoup !

 

[zeb]

sa serra une bonne info pour beaucoup !

j'en parle depuis des lustres mais un retour de plus peut être utile.