L’objectif de Google, avant tout, c’est la performance. Ils publient d’ailleurs des conseils pour optimiser l’affichage du navigateur.
A la trappe les standards, la beauté, la clarté du code. Extraits choisis.
Prefer class and ID selectors over tag selectors
Mettre uniquement des .class et des #id et pas de a{ color:#0072c;} ou de input{ font-family:Arial,sans-serif;}. Mouais. Faut mettre une classe sur tous ses liens alors ? Génial.
Remove class selectors qualified by tag selectors (when a class is only used for one tag, which is a good design practice anyway)
En gros, pas de a.maClasse et de p.maClasse. Créer plutôt 2 classes : .maClassePourUnLien et .maClassePourUnParagraphe, même si les deux classes partagent les mêmes propriétés, à une près (sinon quel intérêt de les différencier). Mouais, bof. Si je veux que .maClasse soit d’un style particulier mais que les liens ayant .maClasse aient une propriété différente, je vais pas m’amuser à créer une autre classe juste pour ça.
Use class selectors instead of descendant selectors
Je reprends le mauvais exemple de Google :
/* Ne pas mettre */
ul li {color: blue;}
ol li {color: red;}
/* Mais mettre */
.unordered-list-item {color: blue;}
.ordered-list-item {color: red;}Bien sûr. Je vais mettre une classe sur tous mes <li>…
Avoid the :hover pseudo-selector for non-anchor elements
Pas de :hover en CSS mais des onmouseover en JS. Et si le gars a pas de JS ?
Bref, pour optimiser votre code, mettez des classes sur tous vos éléments! Merci Google!


12 commentaires
©lems le 1 Jul à 10:53
Oh mais oui…merci Google !
Et où est le principe de la feuille de style…le mec qui a sorti ça doit certainement encore coder en html -0.12…
merci pour cette désinformation de Google ça a le mérite d’être drôle =)
nod le 1 Jul à 12:00
C’est pour la rapidité d’évaluation des styles. Pas pour faire un code plus court en HTML. Je vois pas l’intérêt de taper sur leur article quand les buts sont différents ici et là bas.
L’un d’entre vous a fait des tests pour vérifier que leurs conseils sont infondés ?
Jeremy le 1 Jul à 17:05
Le problème c’est que des web designers débutants vont prendre ces conseils là pour argent comptant. Ils iront pas chercher plus loin. Et franchement, à part lorsqu’on a le trafic de Google, il n’y a personne qui se soucie des millisecondes gagnées en temps d’affichage grâce aux CSS.
Un autre truc : si on suit les conseils de Google en CSS, tu gagnes en temps de rendu mais tu perds en temps de transfert (vu que ton code HTML est 2 fois plus long). Sachant que Google ne ferme pas certaines balises pour gagner en taille de fichier (et donc en temps de transfert), je vois pas pourquoi gagner du temps d’un côté si c’est pour en perdre de l’autre.
Dernière chose : la Team PHP (de Zend) a remis en cause les conseils d’optimisation de Google en termes de PHP. http://groups.google.com/group/make-the-web-faster/browse_thread/thread/ddfbe82dd80408cc?pli=1
Ok Google sont très forts, surtout niveau performance. Mais ils font surtout du Python. Ils s’y connaissent beaucoup moins dans d’autres langages (même si les CSS c’est pas de la prog). Bref. Je respecte beaucoup Google, et je veux juste avertir les gens qu’il ne faut pas croire tout ce qu’ils disent. Il faut garder un jugement modéré.
nod le 1 Jul à 18:11
Oui, modéré ; dans les deux sens.
C’est un article dans le cadre de leur truc page speed. Ils donnent la solution qu’ils ont trouvé et qui marche pour eux en ce moment. Avec tous les browsers en carton qui trainent sur le web, ils n’y sont pour rien dans le fait que cette solution soit optimale.
Bah voila, il ferment pas leurs balises pour compenser les classes… Vu que laisser le parseur régler les problèmes de balises doit être moins couteux sachant qu’il a été fait pour ça depuis le début.
Et puis franchement, quand on cherche la performance on doit s’assoir sur un certain nombre de bonnes pratiques tout simplement parce que les specs ne reflètent pas la réalité. C’est encore plus vrai pour le JS…
Après si les gens sont stupide et n’ont aucun recul sur leur travail, même google n’y peut rien.
nod le 1 Jul à 19:16
J’ai un petit lien que j’ai trouvé après quelques clicks à partir de la page incriminée :
http://www.youtube.com/watch?v=a2_6bGNZ7bA&feature=channel_page
Avancez vers 15 minutes.
Et c’est pas un type de google
Jeremy le 1 Jul à 22:12
J’ai regardé 5 min à part de la 15ème minute. Ca m’a permis de comprendre un peu mieux pourquoi certains sélecteurs prennent vachement de temps, et notamment les sélecteurs descendants parce que ça lit de droite à gauche. Merci pour la vidéo, je la regarderai en entier un des jours. Par contre, le gars il est chiant à écouter parler…
J’essaierai de faire un test entre 2 pages : 1 bourrée de classes, 1 bourrée de sélecteurs descendants. Juste pour voir.
Je me dis que franchement, niveau performance, en CSS, le temps d’affichage est négligeable. Y a que Google pour s’intéresser à ça. Et pour eux, c’est tout à fait légitime avec le trafic qu’ils ont. Mais pour nous, pauvres web designers, on va gagner quoi, 200 milli-secondes ? C’est pas sérieux.
nod le 1 Jul à 22:18
Franchement je pense que c’est beaucoup plus. J’ai été victime de la lenteur du :hover, l’opacité n’en parlons même pas.
Je vais faire quelques tests de mon coté aussi.
Jeremy le 1 Jul à 23:53
Le :hover, c’est possible. Mais c’est franchement dommage de passer par un JS je trouve. Faudrait que le :hover soit mieux implémenté parce que c’est vachement puissant et simple à mettre en place niveau CSS.
Binyamin le 5 Jul à 21:46
C’est vrai que c’est un peu abuser pour les CSS, mais en tout cas, pour le PHP, ca change vraiment.
J’ai fait la traduction sur mon Blog:
http://binyamin.net/blog/rendez-internet-plus-rapide-par-google-20090627-50
Pulupulu le 16 Jul à 17:56
Moi je suis complètement d’accord avec cette technique, pour une raison toute simple : la capacité d’évolution.
Si je décide du jour au lendemain de changer mon ‘li’ en ’span’ j’aurai juste à modifier le code html.
En fait au boulot on a eu beaucoup de soucis à cause de ça, car des styles étaient appliqués sur des ’span’ (ou des ‘p’ , etc), alors quand on a changé ces balises en ‘h#’… Ben le boulot était tout de suite plus conséquent
Et puis, sur des gros sites portail où on a 15 sortes de lien différents, les classes deviennent indispensables.
En conclusion, je pense que ça dépend du besoin de chacun, et aussi de ses habitudes
Jeremy le 16 Jul à 18:12
C’est vrai que je style quasiment plus de balises directement, genre span ou h3 mais j’utilise des classes. Comme ça, on peut modifier la balise html comme tu dis.
©lems le 17 Jul à 11:21
Je suis d’accord sur le faite qu’au niveau de la mise à jours d’un site ça peut être plus simple mais dans la création de tes css tu peux te retrouver avec une montagne de classe pour des balises identiques.
Pour moi s’il y a une modification de ta balise html il y aura (pas à 100%) modification de ton style.
@Pulupulu : “En conclusion, je pense que ça dépend du besoin de chacun, et aussi de ses habitudes
”
On ne peut plus d’accord avec ça, car le besoin varie en fonction du site…en ce qui concerne l’habitude…dommage pour ceux qui en ont de mauvaises