Pages d’erreur

Rappelez-vous : cool URIs don’t change (les URIs sympa ne changent pas), et mieux, autant que possible elle ne disparaissent pas non plus. Reste que beaucoup d’éditeurs ne tiennent pas compte de cette recommandation, et que les développeurs ne peuvent s’abstenir de faire des erreurs quand ils font des liens. 

Ces pages d’erreurs donnent une piètre expérience à l’utilisateur, je ne l’apprend à personne. Je me concentre ici sur l’aspect performance mais sur cet aspect aussi il y a des conséquences.

Les URIs sympa ne changent pas

C’est toujours bon d’insister : les URIs sympa ne changent pas, et ne disparaissent pas. La solution unique et permanente à tous les problèmes d’erreurs est de ne pas en faire. Les erreurs 404 sont très souvent la faute des développeurs ou des éditeurs du site où elles arrivent :

Ne cassez pas les liens, qu’ils soient internes ou en provenance de l’extérieur. Laissez vos contenus à leur adresse actuelle, quitte à ne plus les lier nulle part et qu’ils soient là juste en archive au cas où. C’est simple à dire mais c’est aussi la règle la plus importante.

Pour vous y aider n’hésitez pas à jeter un oeil régulier à vos journaux d’accès pour repérer les 404 et les pages référantes à fixer. Faites aussi tourner des robots sur vos pages pour détecter les liens morts. Des outils comme les outils webmaster de Google peuvent vous y aider. Ils vous montreront tous les liens morts internes et externes que fait votre site.

Les page d’aide ou page d’erreur ?

Quand votre serveur renvoie une erreur, il retourne souvent une page complète. C’est le cas par exemple pour l’erreur 404 (page inexistante), l’erreur 403 (accès interdit) ou les erreurs 500 (problème serveur). La page en question sera affichée dans le navigateur du visiteur, avec une explication et parfois une aide ou un formulaire de recherche.

La page peut être un peu grosse mais elle a un rôle dans l’expérience utilisateur. C’est parfois une page d’aide autant qu’une page d’erreur (pour les erreurs 404 par exemple). Jusque là il n’y a rien de criticable, au contraire : le contenu sur la page d’erreur est un vrai plus s’il est bien fait.

De la taille des erreurs

Mais quand l’erreur survient sur un appel javascript, une feuille de style ou une image ? Votre serveur renvoie probablement la même bonne grosse page HTML. C’est 4ko pour les plus petites (Yahoo, Google) mais plus souvent 8 à 10ko (Le Monde, pages dynamiques de Skyrock blog) voire plus (Microsoft avec 18ko). Dans ces cas là vos 15ko de contenu sont totalement inutiles. Ils sont téléchargés mais ne seront jamais affichés. Plus votre page d’erreur est petite, mieux c’est.

Vos liens en erreur n’ont pas plus de raison d’être faits vers des pages HTML que vers des javascript, des images ou des feuilles de style. Il est même probable que vos erreurs suivent le même ratio html/autre que vos requêtes habituelles, ce qui revient certainement à dire que les erreurs sur des balises <script>, <img>, <link> ou des url() dans les CSS sont plus fréquentes que les erreurs sur des liens classiques <a>. La majorité des contenus téléchargés suite à une erreur l’est inutilement.

Quand bien même votre page d’erreur doit aider l’utilisateur, elle doit aussi rester la plus petite possible car le plus souvent votre contenu est inutile. Pire qu’inutile, il va occuper la bande passante et les fils de téléchargements de votre visiteur. Les 4ko de Yahoo sont raisonnables, Les 18ko de Microsoft ne le sont pas. Le site Légifrance fournit ainsi un logo, une description de l’erreur des liens vers la page d’accueil, la page précédente, le plan du site, la page de contact … le tout en moins de 1ko.

Si vous utilisez un CDN (et vous devriez), les pages d’erreur sur ce dernier ont tout intérêt à contenir le strict minimum elles aussi. Selon toutes probabilité le visiteur ne les verra jamais. Celles du serveur statique de skyrock blog est par exemple d’à peine 120 octets. Sans en arriver forcément là, pensez à rester en dessous de 1ko.

Des redirections

Après une erreur 404 sur le site du premier ministre, nous arrivons sur la page d’accueil, 8ko. Ce n’est déjà pas glorieux mais c’est habituel. Par contre nous y arrivons après une redirection HTTP. Une redirection implique une seconde requête HTTP, avec tous les cookies.

Pour une latence de 40ms, 2ko de cookie et une page d’accueil de 8ko, sur une ligne 2mb/s en réception divisée en deux fils d’exécution, 512kb/s en émission, c’est 75ms pour la première requête et 135ms pour la seconde. À chaque erreur dans l’adresse d’une image, votre navigateur perdra 210ms à télécharger quelque chose qui lui est inutile. Les téléchargements suivants seront différés d’autant. Imaginez 5 images en erreur, c’est une seconde de perdue.

Sur le site du premier ministre c’est en réalité 300ms qui sont perdues car le serveur met un temps inacceptable à retourner la redirection. C’est d’autant plus dommage que même quand j’aurai effectivement affiché la page d’erreur, l’utilisateur ne comprendra pas pourquoi il arrive sur la page d’accueil et ne pourra pas corriger une adresse mal tapée. La règle est simple : ne faites aucune redirection sur vos pages d’erreurs.

Du javascript

Le cas du javascript est d’autant plus gênant. Lors du téléchargement d’un fichier Javascript, tout autre téléchargement sur la page est interrompu. Le rendu et l’analyse de la page aussi. Si vous avez 300ms pour joindre votre page d’erreur comme dans le cas du site du premier ministre. C’est directement 300ms de plus pour afficher votre page principale si elle contient un lien javascript erroné.

Pire, votre navigateur retourne une page complète à la place du javascript. Comme les développeurs ont la mauvaise habitude de ne pas gérer correctement les types mimes, les navigateurs analysent parfois le contenu sans en tenir compte. Non content de bloquer pendant 300ms de téléchargement, votre navigateur va tenter d’analyser vos 8ko de html pour voir s’ils peuvent être interprétés comme du javascript. Suivant votre occupation processeur c’est autant d’attente en plus avant de débloquer l’analyse de la page.

Si vous pouvez vous le permettre, une solution peut être de détecter l’extension du fichier demandé. Si l’adresse finit en .js, alors renvoyez une page d’erreur vraiment minimale, de moins d’1ko, et sans redirection. Ce n’est pas idéal car peut être que l’adresse en erreur n’aura pas cette extension, mais cela couvre une majorité des cas.

Du CSS

Après avoir parlé de Javascript, il ne reste plus qu’à parler des feuilles de style. C’est Peter Frueh (encore un développeur web de Yahoo!) qui nous rappelle le comportement des navigateurs avec les images de fond en CSS : Si vous laissez un url() vide pour une image de fond, le navigateur téléchargera la page HTML courante, comme pour un lien <a> avec un attribut href vide. Au lieu d’une petite image de fond de 2ko, c’est souvent 10ko qui seront téléchargés. C’est même 300ms de perdu pour le site du premier ministre.

Même pour les <link> et les @import, comme nous l’avons vu dans le billet précédent, le rendu est mis en attente. Quitte à faire une erreur dans l’adresse, autant que le rendu ne soit pas différé de 300ms.

Là aussi, détecter les extensions .css, .png, .gif et .jpg pour générer des pages d’erreurs minimales dans ces cas est probablement une bonne pratique.

Des autres erreurs

J’ai beaucoup parlé des erreurs 404, probablement parce que ce sont les plus courantes. Vous pouvez traiter les autres erreurs 4xx de la même manière.

Les erreurs 5xx sont toutefois un peu différentes. Elles montrent une erreur du serveur et le plus souvent ces erreurs sont persistantes et globales à tout le site. Si j’ai une erreur 500, il est tout à fait possible que je ne puisse pas atteindre une autre page.

Le plan du site ou le formulaire de recherche risque de générer des requêtes supplémentaires sur un site surchargé et/ou en erreur grave. S’il s’agit d’une erreur globale ou inconnue, prévoyez plutôt une page d’erreur minimale qui n’incitera pas votre visiteur à relancer des requêtes immédiatement (et bien entendu alertez immédiatement votre équipe de support par un dispositif d’alerte d’urgence).

Vous devriez utiliser un CDN, mais si vous ne le faites pas, évitez d’inclure des composants externes sur votre page d’erreur 500. Le javascript et le CSS indispensable doivent être directement dans la page HTML, les images devraient être évitées. C’est moche pour l’utilisateur mais le faire attendre un contenu qui ne viendra pas c’est encore pire.

Quelques règles ?

Vous voulez aller vite ? voici quelques bonnes pratiques :

• ne pas faire de redirection sur une erreur,
• gardez des pages d’erreur petites (4ko est une bonne cible),
• faites des pages d’erreur minimales sur vos CDN (moins de 1ko),
• si l’adresse en erreur finit en .js, .css, .png, .gif ou .jpg, générez une page d’erreur minimale (1ko),
• dans le cas d’une erreur serveur globale, ne faites pas de liens vers d’autres pages de votre site (plan, accueil, recherche) ou vers des composants sur le même serveur (javascript, css, images).