Vitesse du site / performance -> influence sur le SEO

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

 

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

 

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.

 

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

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.

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.

 

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.

 

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

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.

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

 

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.

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

Perso je ne pense pas avoir dit cela.

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.

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

 

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

 

Profite c'est sacré ;-)

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

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

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

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 ?

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

 

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/

 

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.

 

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

 

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

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 ?

 

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 !

 

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.

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 >

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.

 

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)

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.

 

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.

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

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

 

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