Le SEO ça sert à rien

Du moins c’est ce que je disais à mon pote Matthieu qui critiquait (à raison) la qualité de mon référencement.

Tous mes clients étaient issu de mon réseau ou du bouche à oreille, et ça m’allait très bien. Il me fît remarquer que mon site avait un assez bon trust rank et que le domaine existait depuis longtemps, donc que c’était quand même un peu con que mes titres de pages ne renvoient rien de pertinent, que les <title> soient tous identiques, que je n’aie pas de balises description remplies ou que je n’aie aucun contenu textuel sur les pages de premier niveau.

Et c’est vrai que c’était un peu con.

Mais bon, même en sachant que c’était pas optimisé, je m’en foutais un peu car j’avais surtout peur que le référencement m’amène moult demandes de stages reloues et prospects peu qualifiés que j’aurais dû gérer en perdant du temps.

Ceci étant dit, avec la flexibilité de Kirby, je me suis dit que ça ne mangeait pas de pain de faire ces 2-3 optimisations.

Il m’a donc refait un petit topo sur la meilleure stratégie à adopter, et a rafraichi mes connaissances SEO avec les derniers potins, outils, et manières de définir ses mots clés, et je me suis mis au travail.

Concrètement je n’ai rien fait de fou ni de révolutionnaire, juste le B-A-BA : j’ai cherché les meilleurs mots clés sur lesquels me positionner avec Google trends (par exemple, qu’est-ce qui est le plus recherché en France entre “web design” et “webdesign”), puis j’ai mis ces mots clés dans mes <title> et <h1>, avec un mot clé par page, bien identifié et cohérent.

J’ai ensuite ajouté du texte sur ma page d’accueil et rédigé des petits paragraphes pour la description de chaque page dans le champ sémantique de chaque mot clés (la base quoi).

J’ai aussi créé des pages dédiées à mes activités, chose que je voulais éviter au début, mais mon site n’ayant aucun contenu textuel, j’ai bien dû en passer par là. Je me suis attaché au fait que les pages ne soient pas désagréable à lire pour les humains (même si c’est pas du Victor Hugo) car je ne voulais pas transformer mon site en ferme à mot clés.

À la fin j’ai passé tout le contenu rédigé dans la moulinette SEO review tools (il en existe plein mais j’ai trouvé celle-ci assez agréable et pédagogique) pour vérifier que c’était bon, et j’ai mis en ligne.

Bilan SEO

Le LENDEMAIN je me suis retrouvé 1er sur le mot clé “directeur artistique freelance” alors que j’étais absent des résultats avant. Évidemment ça n’est pas un mot clés super concurrentiel, mais c’est exactement mon métier et c’est celui que j’avais ciblé, donc ça me va bien.

Ça me fait mal de l’admettre mais sur le coup mon pote avait donc raison, google n’attendait qu’un peu de contenu pour que mon portfolio remonte dans les résultats. Bien sûr cette optimisation est un des aspects, d’autres paramètres ont compté (domaine connu, backlinks etc).

Pour ma crainte de demandes de stages, elle s’est un peu confirmée, mais bien moins que ce que je craignais. Quant aux prospects peu qualifiés ou peu sérieux, je n’en ai eu aucun, le positionnement sur “directeur artistique” filtrant déjà efficacement les visiteurs, qui sont soit des agences qui savent ce qu’ils cherchent et connaissent les tarifs, soit des entreprises qui cherchent une compétence précise.

Il en va de même pour les autres mots clés choisis comme “identité visuelle”. Je pense qu’il en aurait été différemment en se positionnant sur “création de logo” ou “création de site internet”.

Contrairement à ce que je pensais également, les gens recherchent sur internet (fou non ?).

Je veux dire que dans mon créneau, où tout marche par le réseau, j’imaginais mal une agence dire “oula j’ai besoin d’un DA je vais le chercher sur google et prendre le premier inconnu qui apparait sur la 1re page”.

Et pourtant si, plus que je ne ne le croyais au départ, surtout quand le DA habituel est en congé ou que les projets sont urgents, ce qui est logique.

Résultat : le SEO a plutôt bien fonctionné, on ne parle pas de centaines d’appels entrant, mais suffisamment pour faire un petit complément de chiffre d’affaires sur l’année passée.

Mon taux de transformation a baissé à (étant donné qu’avant chaque devis émis était signé à coup sûr) mais L’investissement en temps à été rentabilisé.

Le https ça sert à rien

Ça faisait bien longtemps que je voulais passer mon site en https, mais je repoussais toujours ce moment que j’imaginais long et fastidieux.

Puis quand les navigateurs ont commencé à changer l’affichage des sites non sécurisés, je me suis dit en soufflant qu’il allait fallait bien que je m’y mette, surtout que mon site contenait quand même un formulaire pour se connecter au backoffice.

Quelle ne fut pas ma surprise de constater qu’en fait, le SSL était en place sur mon domaine depuis le début ! (et si le vrai SSL, c’était l’amitié ?).

Hé oui, grâce à la généralisation de Let’s Encrypt (ou pas d’ailleurs, si ça se trouve c’était comme ça avant) il suffisait simplement de taper mon url avec https:// devant pour que tout fonctionne en SSL. Partant de là, je n’ai eu qu’à corriger quelques erreurs de mixed content (genre les fonts google que je ne servais pas en https), ajouter des redirections dans mon fichier .htaccess et ajouter une politique HSTS.

Bilan https

Une grosse amélioration de sécurité qui n’a pas demandé beaucoup de temps, c’est ça qu’on aime.

Les images responsive ça sert à rien

En faisant mon site, j’avais opté pour une solution passe-partout pour les images : je travaillais les compos dans photoshop en 2000px de large, puis je passais ça dans ma moulinette shrink-o-matic (un petit soft en Air qui n’existe plus mais que j’ai toujours conservé précieusement) et ça me sortait des jpg optimisés à 70% de qualité et 1500 px de large.

Je mettais ensuite les images dans mon site, et elles étaient affichées en 1140 px de large dans la version desktop. Kirby se chargeait ensuite de gérer toutes les vignettes relatives à ces images.

Avoir une taille unique un peu plus large me permettait de n’exporter et gérer qu’une seule image et qu’elle s’affiche à peu près bien partout, y compris sur les mobiles retina (et pas trop dégueu en desktop retina).

Le srcset

Je connaissais l’existence de pictures et srcset, et avec le système de génération d’images de kirby c’était très possible à mettre en place, mais je ne m’étais pas encore penché sur la question.

Avec la sortie du livre blanc images.guide, je me suis fait un tour d’horizon salutaire sur l’état de l’art des images sur le web. J’ai donc décidé de bosser dessus.

Je dois vous avouer qu’au départ c’est pas franchement intuitif (il faut comprendre qu’il faut d’abord estimer une taille d’affichage de l’image pour la fournir au navigateur via l’attribut sizes), mais avec les conseils de Vincent j’ai fini par comprendre à peu près l’histoire et mettre en place le markup.

Cloudinary

Devant le grand nombre d’images à générer (4 images responsive pour une image avant) et la lenteur de mon serveur pour effectuer cette tâche, je me suis intéressé à Cloudinary qui était conseillé dans le livre blanc.

Il s’agit d’un CDN (content delivery network), un site sur lequel vous mettez des éléments de votre propre site (ici les images) et qui se charge de les gérer pour soulager votre serveur.

Comme les CDN ont des serveurs rapides et distribués à travers le monde, en général ça aide bien à la performance.

Dans le cas de Cloudinary, le CDN ne se contente pas de servir vos images, mais également de les compresser et transformer à la volée grâce à une flopée de paramètres très faciles à définir. Par exemple, il peut choisir le meilleur format (jpg, progressive jpg, png, webp…) et la meilleure compression pour chacune de vos images instantanément selon le type d’image et le contexte du visiteur

Je n’aurais jamais pu faire ça moi-même, à moins de passer des mois sur l’optimisation et la génération de dizaines de variantes de l’image de base.

Un autre avantage de Cloudinary, c’est qu’il n’y a pas besoin d’uploader les images directement chez eux, ils peuvent se charger de le faire automatiquement simplement en accolant l’URL de Cloudinary avec ses paramètres à l’url de l’image originale. Ainsi, vous utilisez votre CMS de manière 100 % transparente, vous uploadez vos images sur votre propre serveur, et Cloudinary fait le reste.

Ce fonctionnement présente également l’avantage de ne pas avoir tous ses œufs dans le même panier et de rester maître de son contenu : si demain Cloudinary disparaît, tombe, ou triple ses tarifs (actuellement c’est gratuit pour les petits volumes d’images, largement suffisant pour le trafic de mon site, mais si vous voulez vous pouvez passer par ce lien pour augmenter mon quota, à vot’bon cœur) il vous suffit d’enlever le préfixe de l’url de vos images, et hop vous voilà de nouveau opérationnels.

J’ai poussé le vice jusqu’à ajouter un interrupteur dans mon backoffice (encore une fois merci la personnalisation Kirby) pour rendre le basculement entre images cloudinary et images natives auto-hébergées accessibles en 1 clic, comme ça je suis paré à toute éventualité.

Bilan des images responsives

Une fois compris le principe du srcset, le plus long est de prévoir et générer toutes les images responsives.

Pour cela, la mise en œuvre de Cloudinary est relativement aisée et ne demande pas de paramétrage compliqué, et le gain est bien supérieur à ce que vous pourriez obtenir vous même en optimisant vos images à la main (cf section suivante sur les perfs).

Cerise sur le gâteau, vous restez maître de vos images qui sont toujours gérées via votre site et peuvent toujours être servies depuis votre hébergement en cas de problème.

Utilisez donc les images responsives et envisagez l’utilisation d’un CDN pour vous aider dans cette tâche.

Les perfs ça sert à rien

Ce qui nous amène à la dernière amélioration : les performances et la qualité générale du site.

J’ai toujours été soucieux de la qualité de mes sites internet, en suivant les bonnes pratiques en vigueur et les checklists Opquast, mais force est de constater que plus on avance, plus le web se spécialise et plus il est difficile de suivre les dernières avancées du domaine.

Si jadis les bonnes pratiques étaient surtout du bon sens (= “ne lancez pas de la musique en fond de page pendant que vous transformez le curseur de l’utilisateur en horloge 3D”) elles sont devenues de plus en plus techniques (= “n’oubliez pas de régler la base-uri de votre CSP et de bien activer le HSTS mais attention au preload”).

Pour suivre la valeur ajoutée de ces optimisations, j’ai opté pour Dareboost, pour faire un état des lieux de certaines pages avant leur optimisation (c’est à dire avant même de mettre en place le srcset par exemple) puis suivre leur évolution.

Il est déjà apparu que le gain était important dès la mise en place des images responsives (forcément) et encore plus important avec la mise en place de Cloudinary et de son optimisation à la volée.

Le lazy loading venait parfaire le tout en limitant le chargement des images aux seules visibles par l’utilisateur.

Je reste toutefois mitigé sur le lazy loading, que j’ai du pour le moment désactivé sur certaines pages car la vitesse perçue avec lazyload activée était inférieure à celle perçue sans (à cause d’un bug dans les versions de chrome les plus récentes).

Merci à Thomas pour sa patience et pour m’avoir aidé à supprimer le reflow, ce phénomène gênant qui fait que la page est petite tant que les images ne sont pas chargées, et s’étend d’un coup lorsqu’elles le sont, faisant bouger toute la page. En réservant une hauteur pour les images en jouant avec le padding-top d’un container + un autre container pour limiter la taille maximale affichées pour les petites images (pas gagné avec des hauteurs d’images de talles variées) le problème a été résolu.

Après ces améliorations de performances les plus évidentes, je me suis attaché à appliquer toutes les bonnes pratiques prioritaires conseillées par Dareboost. Le gros du travail était fait, mais c’était intéressant de voir les optimisations que j’avais laissé de côté et des les corriger. Beaucoup d’améliorations critiques étaient des éléments techniques du serveur, et le .htaccess très pédagogique de Nicolas m’a bien aidé à comprendre les instructions et à y voir plus clair (ce fichier htaccess est à l’origine issu de la html boilerplate).

Les recommendations de Dareboost sont aussi très pédagogiques, avec des liens et des exemples qui permettent de comprendre et de corriger seul la majeure partie des problèmes rencontrés.

J’ai aussi mis en place un monitoring du site avec Status Cake pour savoir quand le serveur n’est plus accessible, ce qui n’est pas rare avec OVH (en attendant e trouver un meilleur hébergeur et surtout de me motiver à migrer)

Bilan de l’optimisation de performances

Sur une page de book de taille moyenne contenant exclusivement des images, le poids de la page est par exemple passé de 6,2 Mo à 445 ko, le temps avant le premier affichage d’un élément de la page a été divisé par 2 et le temps de chargement complet par 3. Le score de qualité Dareboost qui reflète la qualité de la page est passé de 70 % (bof) à 97 % (excellent). Je ne pourrais jamais atteindre les 100 % car je n’ai pas la main sur certaines améliorations coté serveur.

Avant : avant

Après : après

Le site est également remonté drastiquement sur certains mots clés, impossible de savoir si c’est 100% lié aux optimisations mais ça a sûrement joué.

Ces optimisations ont demandé pas mal de travail mais c’était une bonne chose à mettre en œuvre, je ne regrette rien. Next step : essayer de jouer un peu avec les micro datas (ce point rejoint celui du SEO)

Les conclusions ça sert à rien

Résumé des améliorations mises en place :

Bilan de tout ça, je suis toujours aussi content de Kirby qui facilite tout ce genre de petites améliorations progressives sans trop se prendre la tête ni installer 1 milliard de plugins, et qui facilite leur gestion via son backoffice ultra personnalisable, qui fait que quasiment chaque amélioration évoquée est retranscrite dans l’admin du site et modifiable rapidement (par exemple toute la partie SEO avec des champs dédiés pour chaque page).

Je constate aussi que plus ça va, plus le web se professionnalise et se spécialise, et qu’il devient difficile de suivre de front tous les domaines utiles à la publication et à la maintenance de son site perso (perf, SEO, front dev) quand on est soi même obligé de se spécialiser sur son métier principal (Directeur artistique en l’occurrence). C’est une bonne chose, ça veut dire que le média mûrit, mais pfiooo faut pas s’endormir si on veut encore être à même de faire ça tout seul (ou alors c’est que je deviens vieux mais c’est impossible).

Ça vérifie ma théorie de départ qu’il ne sert à rien de se bloquer pour sortir son book, et qu’il ne faut pas hésiter à sortir quelque chose d’incomplet mais future-proof plutôt que d’attendre d’avoir le site parfait, sinon on ne se lance jamais.