Depuis que je fais du dev, la question des perfs n’a jamais été aussi présente qu’aujourd’hui dans l’écosystème web SEO. Ce sujet me plait énormément car j’ai pu avoir la preuve récemment que la vitesse de chargement peut avoir un effet direct avec le positionnement sur Google (bien sûr il faut faire le taff aussi côté SEO pour en maximiser l’impact).
Alors voilà, je viens tout juste de me lancer en freelance et je souhaite démarrer cette merveilleuse aventure en me spécialisant sur ce point : les perfs d’un site internet, plus précisément sa vitesse de chargement. Je dispose d’une bonne base et je souhaite creuser ce sujet le plus loin possible. Je trouve ça passionnant qu’un sujet 100% tech puisse répondre aussi directement à un besoin business/marketing.
Si des personnes sont intéressées par ce sujet, je vous invite à poser vos questions ici ou à me contacter en MP. Je me ferai une joie d’échanger avec vous.
Sinon à part ça, je vous pose ces questions : quel est la place de la question des « perfs » au sein de vos projets digitaux? L’incluez-vous dans vos stratégies business & SEO? Travaillez-vous d’ores sur le sujet? Quels sont vos plus grandes difficultés par rapport à ça? Qu’avez-vous réussi à faire aujourd’hui? Quel sont vos feedbacks sur le sujet?
Les perfs sont importantes pour le référencement mais aussi pour la fidélisation.
C’est un sujet complexe parce qu’il faut maîtriser l’ensemble du stack web, serveur, dev, sql, scalabilité, sécurité et j’en passe.
En général, les perfs personne ne s’en occupe jusqu’au jour ou ça commence à ralentir, et la, c’est la panique !
Il vaut mieux, je pense mettre des sondes en amont, afin de pouvoir diagnostiquer les ralentissement à chaud ou même en amont. On va beaucoup plus vite pour les résoudre quand à déjà des indices (par exemple si la perte de perf apparaît suite à une mise en prod, ben on peut en déduire que c’est sûrement le nouveau code qui consomme trop).
Pour ma part j’ai utilisé TICK (Telegram, InfluxDB, Chronograf, Kapacitor). InfluxDB est une base de donné de série temporelle (un NoSQL dédié) qui m’a rendu service plusieurs fois pour surveiller des sites Drupal. L’avantage c’est qu’il dispose de sondes pour tout un tas de services système et qu’il peut centraliser la surveillance de plusieurs serveur et mettre tout ça en graphique et en alertes. Bien sûr il y a les systèmes classiques munin, nagios & co, mais TICK m’a semblé plus moderne, versatile et intuitif.
Sinon, après, quand on doit retrouver un bottleneck dans le code, la, il faut des outils plus spécialisés pour instrumenter le code et repérer les parties consomatrices. Ca dépends des langages utilisés. Pour ma part en PHP j’ai utilisé XHProf pour l’analyse, et locust.io pour la montée en charge.
En terme de carrière, c’est un positionnement intéressant pour un indépendant je pense. En étant bien pointu, je pense qu’on peut vendre des interventions à un bon tarif, dans la mesure ou ça se justifie parfaitement : il vaut mieux payer un spécialiste 3j très cher que laisser galérer l’équipe de dev sur le sujet pendant des semaines (parce que les perfs c’est vraiment tricky).
C’est un effet un sujet complexe et les solutions efficaces dépendent souvent du contexte.
Je crois qu’il ne faut effectivement pas trop investir sur le sujet trop vite, justement parce qu’on ne sait pas précisément a priori où l’effort se révélera le plus payant mais en même temps, il faut avoir cette problématique en tête dès le départ, histoire de ne pas tomber dans les pièges qui pourraient être évités sans coûter plus cher…
Un exemple simple : mettre en ligne une image de 200 Ko ou de 5 Mo demande à peu près le même effort et pourtant il y en a une qui va se charger bien plus vite que l’autre alors même que la différence de qualité à l’oeil pourra passer inaperçue.
(c’est vrai que là j’ai choisi un cas très simple).
Bonjour,
Comme cela l’a été évoqué c’est une problématique complexe qui va dépendre de différents aspects.
Naturellement, l’architecture va influencer sur la performance de la solution mais, il n’y a pas que cela.
La manière dont le code peut être rédigé, les outillages (composants) utilisés, etc.
Le soucis de la performance mais, aussi de l’optimisation environnemental doit être pris en compte dès le début du projet. Hors, je regrette que l’enseignement en école soit peu présent sur ces points.
N’oublions pas que les utilisateurs sont demandeurs à la fois de performances, fiabilité, qualité mais, aussi d’accessibilité et d’ergonomie. Cela représente un sacré paradigme surtout quand on y ajoute la problématique environnementale (consommation énergétique).
4 - On va voir le site de réservations de la SNCF et aura ainsi un bon résumé de tout ce que l’on doit éviter de faire (pas en ce moment car l’accès aux comptes persos y est planté depuis 3 jours).
pour les perfs, ce n’est pas qu’un sujet SEO à mon sens … au dela de 3 secondes de chargement, ton visiteur se fait la malle car trop long, pas de temps à perdre, etc …
donc selon si tu fais du mediabuy (adwords & co), et bien c’est important de ne pas perdre les leads pour une raison débile : le temps de chargement.
@ybabel trop cool je ne connaissais aucun de ces outils. Du coup pas mal de lecture en perspective, merci.
@cadorable@flibaud Oui, ce serait un point à voir en tout début de projet dans la théorie. Mais dans la pratique si il n’y a pas de tech puriste dans l’équipe, c’est mort dans 99,9% des cas. C’est souvent un des points abordés qu’après, une fois que la machine à cash est engrangée (ce qui peut se comprendre).
