Blog // Exirel.me

Retrouvez tous les articles liés au tag #trolldredi via le flux rss dédié à ce tag.

Mélanger redirection, SEO et Webperf...

Par Florian Strzelecki - 01:12 - 07.07.2012

Tags : Web, Bonne pratique, Optimisation, Technique, #trolldredi

Je suis toujours fasciné par la capacité de mes contemporains à chercher la moindre petite bête, le moindre petit détail, là où il n'y a pas besoin de le faire. Ou à, plus précisément, tenter de résoudre un problème qui n'existe pas.

Suite à l'article Réconcilier SEO et WebPerf au niveau des redirections de (sous-)domaines j'ai discuté rapidement sur twitter... mais manifestement mes objections n'ont pas été comprises (mais c'est difficile avec des tweets de débattre de ça).

D'ailleurs, je vous invite à lire les commentaires de l'article, car deux personnes ont déjà soulevé ce que j'ai essayé de dire. Comme le sujet m'intéresse un peu (et que nous sommes vendredi), je vous livre mes réflexions sur le sujet.

Quel est le problème ?

Première question : quel est le problème ? Non mais, vraiment, où est le soucis d'une redirection (de www vers no-www, ou no-www vers www) ?

Si votre site est bien fait - et il l'est, puisque nous sommes des experts, n'est-ce pas ? - vous n'exposez, au monde extérieur, aucun lien incorrect. Les liens de ces immondes boutons collés avec des scripts externes (et qui suivent à la trace vos utilisateurs qui n'ont rien demandé) utilisent le bon nom de domaine, tout comme vos flux rss, vos newsletters, etc.

Bref, de votre côté, tout est bon, et il n'y a donc pas lieu de craindre ni pour votre référencement, ni pour vos performances. Vous assurez grave, bravo !

Considérons ensuite vos utilisateurs, ces gens bizarroïdes qui utilisent "cmd+entrée", et tapent directement le nom de votre site dans leur barre d'adresse. Concrètement, s'ils perdent 75 millisecondes à attendre que leur navigateur trouve la bonne adresse, puis redirigent vers le bon domaine, je pense que ce n'est vraiment pas un soucis. Par contre, si la moindre petite redirection chez vous implique une seconde, je pense que vous avez de sérieux problèmes à résoudre avec votre serveur.

Quant à ceux qui n'indiquent rien (ni TLD, ni sous-domaine), les comportements varient selon les navigateurs et les configurations : avec un label bien placé sous Firefox, cela revient à cliquer sur un favoris, et sans label, à faire une recherche Google (je viens de re-tester à l'instant, histoire d'être sûr).

Dernier petit point que je souhaite soulever : quel est l'importance d'éviter une redirection totalement minoritaire, alors que nous savons tous - vous le savez n'est-ce pas ? - que les scripts des publicités, comme tous les autres chargement de ressources externes et en dehors de votre contrôle, sont bien plus à même d'effectuer des redirections qui pénaliseront le chargement de la page. Pas seulement le chargement de la première requête, mais bel et bien pendant l'ensemble du chargement de la page. C'est à dire, en même temps que le chargement de vos images, de vos scripts et feuilles de style externes. L'échec complet quoi.

Bref, un non-problème. Mais on va dire que c'est quand même un problème, rien que pour parler des solutions.

Quelle est la solution ?

L'internaute moyen ne vois pas où est le problème d'attendre 75 millisecondes de plus dans le chargement de sa page pour une seule et unique redirection. Par contre, il râle lorsque le site affiche plusieurs publicités, chacune faisant perdre plusieurs secondes à sa navigation. Je dis ça, je ne dis rien. Enfin si, je dis quelque chose, je sous-entends même un petit peu que c'est chercher à résoudre un non-problème, mais je l'ai déjà dit plus haut.

Quant aux moteurs d'indexations, ils doivent être considérés comme des utilisateurs comme les autres. Si vous voulez leur parler, vous avez les codes de réponse HTTP (2xx, 3xx, 4xx mais aussi 5xx). Vous avez aussi les robots.txt et les sitemap.xml - mais je ne vais pas vous apprendre le métier.

Si vous cherchez à les cibler plus particulièrement, vous pourrez tout aussi bien avoir de bonnes comme de mauvaises surprises. Les User-Agents n'ont rien de fiable ni de sûr, ils peuvent changer, ne pas être utilisé comme vous le pensé (je suis toujours aussi surpris du fonctionnement de certains User-Agent), et tout un tas d'autres trucs que seuls les robots qui rêvent de moutons électroniques peuvent comprendre.

Dernier point : si vous commencez à avoir des règles conditionnelles de réécriture d'URL pour ça il est peut-être temps de se demander où vous mène toute cette complexité. Oui, je sais, la simplicité, c'est un truc de hipster-bobo-indépendant-hackiviste. Mais quand même, la simplicité, c'est souvent une bonne pratique de WebPerf.

Un A dans YSlow

Il y a un soucis que je me pose avec cette recherche d'une bonne note de WebPerf. Je ne veux pas remettre en cause la note ou sa recherche. Mais par contre, quel est l'intérêt de tester des liens avec le mauvais sous-domaine ?

Parce que, concrètement, si le fonctionnement normal et principal de votre site, c'est sans le sous-domaine (ou avec, vous remplacez mentalement par l'inverse), en dehors d'une éventuelle phase de transition, vous n'avez aucune raison de tester la mauvaise version. Ou alors uniquement pour vérifier que votre serveur sait faire une redirection rapidement et efficacement.

Le reste, ça n'a pas d'importance.

On me souffle à l'oreille qu'un A dans YSlow n'est pas vraiment un bon objectif. Et je vous épargne la citation exacte pour vos chastes oreilles.

Bootstrap : addendum

Par Florian Strzelecki - 15:10 - 02.06.2012

Tags : #trolldredi, css, lesscss, twitter bootstrap

Bon, j'ai bien ri, peut-être que vous aussi, mais je ne pouvais pas laisser cet article sur la bootstrapite aiguë sans quelques explications supplémentaires.

Dérives

Bootstrap en lui-même n'est pas vraiment un problème. Il y a certaines choses que je n'aime pas du tout (notamment une "légère" perte de contrôle sur l'agencement des classes), mais avec lesquelles je peux vivre. Ou le fait qu'il faille modifier certains fichiers de bootstrap pour modifier des variables d'ajustement (comme le souligne @nautilebleu).

Les dérives peuvent vite venir. J'en parlais un peu en dénonçant ce système de grille, avec ses multiples classes .span* et .row. Pour reprendre la phrase d'un grand philosophe de ces 5 dernières années :

Des .span* et des .row c'est pas grave quand il y en a un ou deux, mais quand il y en a 50 bonjour les problèmes !

Le soucis, c'est qu'il faut passer par l'attribut "class" de vos éléments HTML. Ce qui veut dire que, pour chaque élément HTML que vous avez, vous devez considérer les classes, ce qu'elles font, et en ajouter/retirer au besoin. Donc modifier le code HTML uniquement pour des questions de style.

Ok, là vous pourriez me dire que c'est normal, que, quoi qu'il arrive, soit je modifie le CSS, soit je modifie le HTML, soit les deux, mais que je ne peux pas y couper. Mais je ne suis pas d'accord : vous ne devriez pas avoir à toucher au HTML pour modifier la tête de la bordure de vos éléments, mais seulement à une classe css.

L'intérêt de CSS, c'est de séparer le style de la structure. L'attribut class de mes balises HTML appartiennent à la structure de ma page, et pas au style. Par exemple si un tableau ou un bloc est lié à des données de clients, les classes CSS utilisées devraient avoir un rapport avec ça : "client_facture", "client_achat", ou encore "client_profil". Si j'affiche plusieurs fois ces éléments, je n'ai pas à m'inquiéter d'une longue liste de classes CSS à ajouter à tel ou tel endroit.

Mais si vous utilisez les classes de bootstrap, vous devrez alors ajouter partout où vous en avez besoin une montagne de classes : positionnement, typo, bordure, etc. Ce qui est trop, surtout que vous avez lesscss à côté pour faire des mixins à la place (mais il faut que ce soit compatible avec le fonctionnement de bootstrap, ce qui n'est pas assuré, surtout avec le jeu des imbrications).

Quelques pistes de solutions

Tout n'est pas si sombre. En tout cas, certainement pas aussi sombre que ce que je m'amusais à le décrire dans mon précédent billet (mais nautilebleu l'a fait remarqué, c'était un #trolldredi assumé).

Je pense que le concept de lesscss est une bonne façon de résoudre certains problèmes. Principalement grâce aux mixins. Au lieu de réutiliser les classes de bootstrap pour les assigner à votre code HTML, il serait préférable de les utiliser pour créer vos propres classes css.

Cela demande un travail différent, mais cela permet de conserver la partie style dans la feuille de style, et pas ailleurs. Retour à plus de sémantique, et moins de pollution dans le HTML (et moins de travail si vous avez beaucoup de pages et de vue dans votre application).

Bon, après, reste à tester tout ça, pour voir si ça fonctionne quand même (et cela demande de fouiller dans le coeur de bootstrap, et là, tout de suite, j'ai la flemme).

À noter aussi une idée de @nautilebleu : créer un preprocesseur de css (qui lit le langage less, ou sass ?), en python. Cela nous permettrait, à nous développeur python, de créer ensuite des ponts vers django-compressor et autres techniques. L'idée étant de créer d'autres preprocesseurs avec la même syntaxe, dans différents langages (et assurer une portabilité).

Bref. Il y a du boulot, mais l'idée de structurer le développement des CSS, ce n'est pas une mauvaise idée.

La bootstrapite aiguë

Par Florian Strzelecki - 01:15 - 02.06.2012

Tags : Framework, Technique, #trolldredi, css, lesscss, twitter bootstrap

Aujourd'hui, plutôt qu'un #loldev du jour, je préfère poster dans le #trolldredi. Et aujourd'hui, je vais troller sur Bootstrap by Twitter.

Préambule : ceci est un troll, vous avez le droit de répondre, mais n'oubliez pas que je ne me prends pas vraiment au sérieux (sauf sur certains trucs), et que, globalement, j'en ai pas grand chose à faire de bootstrap. Utilisez le si ça vous chante, ce n'est pas non plus le mal absolu.

Enfin, quoi que...

Je pense - notez l'usage du "je" d'une part, et du "pense" d'autre part - qu'il s'agit d'un fléau terrible, d'une maladie cataclysmique, d'une épidémie apocalyptique - je dis cela en toute modestie, bien évidement. De là à dire qu'il y a un lien entre #ZombieBukkake et Bootstrap il n'y a qu'un pas, mais je vous laisse le faire. Le pas, pas ZombieBukkake. Enfin, ça, ça ne me regarde pas.

D'ailleurs, si vous croisez quelqu'un dans la rue qui gémit un "boooostrappp" c'est peut-être qu'il faut l'achever à coups de pelle. Et vite, de préférence.

Bootstrap et Less

La documentation n'est pas spécialement claire sur le fonctionnement de bootstrap, mais vous risquez très vite de vous retrouver avec ceci directement en prod :

<link rel="stylesheet/less" href="/path/to/bootstrap.less">
<script src="/path/to/less.js"></script>

Enfin, ça, c'est si vous arrivez à trouver la bonne partie de la documentation (cela dit, c'est un peu plus simple en passant par le site de {less}).

Et là, j'entends déjà les prophètes noirs de ce "framework css" :

Hérétique ! C'est uniquement pour le dev, il faut compiler les fichiers .less avec lessc !

Je sais. J'ai fini par trouver les informations dont j'avais besoin pour :

  1. Comprendre de quoi il s'agit (rien que ça),
  2. installer tous les paquets, logiciels, bibliothèques, etc. requis, (j'en ai encore des cauchemars)
  3. prier 50 fois les dieux de mon choix, en sacrifiant un hamster avec des clés usb et en rebootant 3 fois mon ordinateur,
  4. obtenir les fichiers bootstrap.css et site.css dont j'avais besoin.

Si, comme moi, vous avez eu la mauvaise idée de ne pas utiliser une version minimisée des fichiers css, vous aurez droit à un fichier de 5000 lignes (mais sinon c'est super pour les mobiles).

Hérétique ! Il faut choisir uniquement les modules de bootstrap dont tu as besoins !

Oui, alors, là, je veux bien hein, mais c'est pas exactement ce que j'appelle "une documentation claire sur le sujet" que j'ai sous la main. C'est la documentation officielle (déjà, il faut comprendre où aller pour trouver toutes ces infos), et elle n'est pas claire pour deux sous.

Pour vous abreuver de variables à utiliser avec lesscss, ça, y a de quoi faire. Tout comme il y a largement de quoi faire des tableaux avec des divs et des classes aux noms génériques. Mais une putain d'explication simple, claire, et concise de comment faire son propre bootstrap propre et minimaliste, c'est la croix et la bannière !

Pourtant, sachez-le, je pense qu'il y a moyen de faire un truc "pas trop crade".

Bref, je n'ai rien contre less (enfin, si, j'ai un tas de trucs contre, mais je comprends l'intérêt de la chose, et je pense même l'utiliser), mais je résume par l'équation suivante :

bootstrap + less == grosse prise de tête.

Divite aiguë

Je pensais cette maladie oubliée, perdue, et disparue dans les tréfonds du web des années 2004-2006, lorsque CSS est devenu vraiment populaire, que Firefox sortait en version 1.0 puis 1.5 (j'ai une anecdote croustillante à vous raconter à ce sujet d'ailleurs, mais ce sera pour une autre fois), et que tout le monde s'accordait à dire "non mais, remplacer les <table> par des <div> partout en cascade, ça va pas être possible".

FAUX

Bootstrap permet aux plus neuneux d'entre nous de faire les plus ahurissantes combinaisons de cellules façon tableau 1998 à base de div. Et ouais, ces bonnes vieilles div.

Il y a même un nom pour ça : grid system et fluid grid system.

Comment dire. Je comprends parfaitement l'intérêt d'un design qui s'aligne sur une grille. Mais vous ne croyez pas qu'il y a un problème avec ce genre de code html :

<div class="row show-grid">
    <div class="span1">1</div>
    <div class="span1">1</div>
    <div class="span1">1</div>
    <div class="span1">1</div>
    <div class="span1">1</div>
    <div class="span1">1</div>
    <div class="span1">1</div>
    <div class="span1">1</div>
    <div class="span1">1</div>
    <div class="span1">1</div>
    <div class="span1">1</div>
    <div class="span1">1</div>
</div>
<div class="row show-grid">
    <div class="span4">4</div>
    <div class="span4">4</div>
    <div class="span4">4</div>
</div>
<div class="row show-grid">
    <div class="span4">4</div>
    <div class="span8">8</div>
</div>
<div class="row show-grid">
    <div class="span6">6</div>
    <div class="span6">6</div>
</div>
<div class="row show-grid">
    <div class="span12">12</div>
</div>

Avec ce genre de documentation :

With the static (non-fluid) grid system in Bootstrap, nesting is easy. To nest your content, just add a new .row and set of .span* columns within an existing .span* column.

Ce qui donne ce genre de règles pour css :

.row .span6 .row .span6 { /* ... */ }

Quoi ? La lisibilité ? Pour quoi faire ? On a un putain de grid-system-de-la-mort pourquoi on se ferait chier avec de la sémantique ou bien de la lisiblité.

lol noob.

Vous en pensez ce que vous voulez : moi, je n'en pense que du mal. Je comprends l'utilisation de technologie comme less pour factoriser le calcul des tailles des blocs pour chaque élément. Mais là, c'est exactement ce qui était reproché à la divite aiguë en 2007, et qui est toujours aussi désagréable.

Surtout que - excusez du peu - mais tant qu'à mettre un framework de css aussi lourd que bootstrap, autant utiliser des balises HTML5 (genre <aside>, <footer>, et autre <article>) avec un peu de JS pour supporter les anciens navigateurs. Après tout, ce ne seront que quelques ko en plus à télécharger.

Digression sur la notion de "standard"

Deux remarques de @revolunet :

C'est surtout l'aspect standardisation du markup qui est utile. Une bonne base pour themer, partager et faire evoluer des pages web

Deux remarques en un seul tweet. Je ne vais m'intéresser qu'à la première, puisqu'elle me révulse profondément. La seconde, j'en parle dans la suite, dans la partie des trucs biens.

La standardisation, justement, à quoi sert-elle ? Dans un cas comme bootstrap, à ce que tout le monde puisse parler de la même chose en même temps. C'est bien, c'est louable, mais il y a une chose qui manque : un sens à tout ça.

Ici, la standardisation ne sert qu'elle-même, et pas à donner du sens à ce que vous écrivez. Cette "standardisation" est l'exact contraire du travail de standardisation sur HTML5 & CSS3.

J'ai hâte que nous ayons un grid-layout en CSS3 implémenté partout et utilisable, mais je ne suis pas prêt à farcir mon code html d'une multitude de classes sans aucune sémantique.

Imaginez le bordel que ça doit être quand il faudra savoir si dans ce .row là il faut mettre un .span4 + .span2 ou deux .span4. Imaginez que cette question se pose dans un flot de .row .span4 les uns à côté des autres. Avec des .container dans les coins, histoire de vous faire un croche-pied.

Bon courage, mais je ne veux pas de cette standardisation là.

Ton .css tu ne comprendras plus.

Autre point qui me frustre particulièrement avec bootstrap. Que vous ayez un .less (et ses multiples import), ou un immense .css, comment comptez-vous vous y retrouver là dedans ? Comment allez-vous vous assurer, à chaque instant, de comment ça marche tout ce bordel ?

Et si, par malheur (et ça arrive tout le temps en réalité), quelqu'un se met à modifier certains fichiers .less de bootstrap, et pas seulement le local.less... bon courage !

lol noob c'est que du css on s'en fout !

Un intégrateur débutant qui mettait des #id partout pour tout. Il est mort dans d'atroce souffrance. IE6 overdose.

Je me suis retrouvé devant ce cas concret : on me file des .less, et à moi de me débrouiller avec. Problème de compilation parce qu'il manque un truc ? Débrouille toi ! Problème parce qu'un style ne fonctionne pas / ne fait pas ce qu'il devrait ? Débrouille toi ! Et surtout, paye toi tous ces fichiers dans tous les sens.

La doc n'est d'aucun secours, puisqu'il s'agit d'un problème que vous aurez entre votre html, vos css perso, et les règles de bootstrap. Ce ne serait pas un problème si c'était juste un reset de style, ou des classes ayant un sens sémantique...

... mais là, vous avez bootstrap, et son paquet d'éléments tous plus génériques les uns que les autres.

Et en prime, dès que vous voudrez changer le style de quelque chose, vous devrez modifier les classes css que vous utilisez pour cet élément (et donc le html)... #fear.

Là où c'est utile...

Bon, je vais cesser de troller pour aujourd'hui. Il y a un tas de trucs qui me dérangent avec bootstrap de twitter, mais il y a aussi des points positifs.

Comme le disait @revolunet c'est une façon de partager un point commun dans une équipe pour partager un style. Cela permet d'avoir un rendu "basique et standardisé" rapidement. Enfin, rapidement... je me comprends.

Standardiser des techniques d'utilisation de CSS

Je sais, mon précédent point était de dire que la standardisation de bootstrap c'était le mal. Et je n'en démords pas.

Par contre, l'effort de proposer une approche de "standard" est très intéressante - principalement pour le grid-system justement. Mais il aurait été beaucoup plus intéressant d'exposer des structures à réutiliser avec less, plutôt que des classes génériques à tout faire.

Après tout, une grille n'obéit qu'à quelques règles relativement simples, principalement, des règles mathématiques (je ne vais pas détailler, c'est un peu long et technique, mais ce n'est pas aussi compliqué que ça en a l'air).

Bref : bootstrap propose un concept intéressant, en cela qu'il démontre la logique mathématique derrière un tel système.

Un exemple pour la route :

Avec bootstrap, si vous voulez mettre un style à vos tables html :

<table class="table table-striped table-bordered table-condensed">
...
</table>

Ok... mais pourquoi ne pas simplement avoir des mixin less de ce style là :

# in table.less
.table-striped {
    /* style for striped table */
}
.table-bordered(@border: 1px) {
}

# in local.less
.customer_table {
    .table-striped;
    .table-bordered;
}
.product_table {
    .table-bordered;
}

Et voilà : vous obtenez le même résultat final, mais au lieu de rajouter plusieurs classes à votre élément <table>, vous ne lui ajoutez qu'une seule classe : la votre, celle qui a du sens customer_table pour vos clients, product_table pour vos produits. Si vous devez changer le style de ces deux tables, vous n'avez pas à changer le code html.

Et puis surtout si vous changez l'un vous ne changez pas l'autre par erreur...

Prototypage et application

Pour un prototype, bootstrap est peut-être une bonne idée. Je dis bien : peut-être. Je suis convaincu que, pour un petit site, il est une usine à gaz. Mais pour un prototype, il pourrait permettre de présenter quelque chose rapidement.

De même, pour une application web de type "intranet" ou "panneau de commande" réservée à un petit groupe qui utilise un système d'administration (de contenus par exemple, ou de gestion comptable, ou de ressources quelconques), il permet de standardiser rapidement le style de l'application. Mais cela reste un cas particulier - certes très utile (ce ne serait pas un mal à mon boulot par exemple), mais pas n'importe où n'importe quand.

Trolldredi, c'est fini pour aujourd'hui.

Allez, je m'arrête là, c'est déjà beaucoup de temps passé pour comprendre, analyser, et découvrir bootstrap. C'est un outil dont je n'ai pas besoin, mais il m'aurait fait mettre un doigt dans less. Ce qui n'est pas un mal en soi.

Il y a des bonnes idées à reprendre, mais en l'état : je dis non. Filez moi la même chose avec des mixin lesscss, et peut-être que j'y prendrai goût (mais c'est pas sûr).