Fin 2013, j’écrivais un billet sur la refonte du site de mon agence, une histoire de CSS responsive en mobile-first.
Allez savoir pourquoi, je n’avais pas pu y revenir !
J’exprimais quelques regrets sur la CSS, notamment des problèmes de factorisation. Un peu plus d’un an après, j’ai eu un (tout petit) peu de temps, et il y a quelques changements pas inintéressants à partager avec vous.
Sass, un an après
Le plus dur a été de faire redémarrer Sass un an après, c’est dire si c’était difficile après… quelques minutes. J’avais utilisé Sass pour industrialiser certaines tâches, notamment la gestion des très nombreuses icônes dans leurs divers formats, impossible à faire à la main.
Du coup, j’ai repris ces classes et j’ai fait exactement ce que j’aurais dû faire à l’époque, utiliser des classes icon-service-48-<ici_le_service>
, qui me permettront de cibler tous les éléments correspondants via un simple [class*=icon-service-48-]
.
Certes, l’économie semble mineure. Toutefois, sur une longue liste d’icônes (avec des surcharges en prime), l’économie a été plus que substantielle, cela s’est compté en dizaines de kilo-octets. Pas négligeable et bien plus propre en prime !
Les micro-datas changent
Bon, disons-le clairement, ça aurait pu me passer sous le nez. Le schéma a légèrement changé, rendant invalides certaines des micro-datas que j’avais semées ici et là.
Notamment, la relation makesOffer
ne peut plus offrir de itemtype="http://schema.org/Product"
mais bien un itemtype="http://schema.org/Offer"
. Ce qui peut sembler logique, mais à l’époque, on pouvait offrir des produits, maintenant on ne peut plus offrir que des offres ! (exemple avec les Rich Snippet Tools)
Autre curiosité, si vous précisez un logo pour une corporation
, il faut préciser un itemprop="url"
sinon le validateur va gueuler en vous disant que c’est obligatoire !
Rien de bien gênant, quelques tests et quelques corrections règleront cela rapidement.
SVG, mon amour
J’avoue ne pas avoir été très longtemps fan du doublement de résolution pour des images pour les écrans retina. In fine, c’est plutôt lourd à gérer et ça m’a amené plus de problèmes qu’autre chose pour les icônes (les graphistes ne sont jamais contents du rendu en prime).
Comme ces dernières venaient d’Illustrator : passage immédiat en SVG !
J’ai installé en prime un Modernizr (il n’y en avait pas). Au lieu de mettre à disposition les images en PNG et de surcharger avec celles en SVG (ce que j’aurais fait à l’époque), j’ai pris le parti inverse (on est en 2015, mer… !) : d’abord le SVG et une solution de repli en PNG via le no-svg
ajouté par Modernizr.
Surprise : les images des sprites en SVG semblaient plus lourdes que leurs équivalents en PNG. Mais avec la compression GZIP activée (hé oui !), elles furent quand même bien moins lourdes (presque deux fois plus légères pour certains sprites).
Des ajouts qualitatifs
Quelques rapides tests sur Dareboost me rappelleront d’ajouter quelques éléments que je ne connaissais pas à cette période : Header set X-Frame-Options "DENY"
, Header set X-XSS-Protection "1; mode=block"
, Header always set X-Content-Type-Options "nosniff"
pour des aspects de sécurité (à retrouver dans mon fichier htaccess de référence).
Quelques bêtes oublis comme <meta property="og:type" content="website" />
seront corrigés.
Au passage, l’ajout des webfonts au format WOFF2 permettra encore d’alléger un peu le site.
En conclusion
Ce n’est pas parfait, c’est toujours améliorable… mais c’est toujours mieux que ce que c’était. Rendez-vous à la prochaine salve d’améliorations.
Merci pour ce billet (et son précédent sur le sujet), des mines d'infos ! Je suis en train de terminer mon 1er mobile-first, et c'est plutôt plus facile que je ne pensais, du moins sur un site simple.
J'avais une question sur les sprites SVG : comment les génères-tu ? Via sass/compass ?