En webmastering, je n’ai jamais cessé d’apprendre, depuis le début, et de corriger mes erreurs du passé. Voici une petite liste de choses qu’il faut ou ne faut pas faire. Ça n’a rien d’officiel, mais croyez-moi, vous me remercierez un jour.

Ces astuces permettront une mise à jour facile de votre site, une bonne capacité à évoluer et un code propre.
Notez que je code mes pages statiques dans un éditeur de texte et que mon site ne contient pas uniquement un blog. Certaines astuces ne s’appliquent donc pas à tout le monde ou seront dures à appliquer dans certains cas.
Ajoutez que je ne parle pas des bases des langages eux-mêmes (par exemple de toujours utiliser une police générique à la fin de font-family en css), que je considère comme acquis.

Les fichiers HTML, l’organisation des dossiers

  • Gardez les noms de fichiers courts, sans majuscules ni espaces. Donnez leurs des noms clairs et explicites.
  • Utilisez seulement des lettres minuscules, des chiffres, et favorisez les tirets « - » au lieu de l’underscore « _ » à la place des espaces.
  • Si vous avez plusieurs pages : utilisez des dossiers au lieu de pages (ex /a-propos/index.html et /contact/index.html au lieu de a-propos.html et contact.html) : c’est plus pratique, surtout quand vous voudrez ajouter des images pour chaque page.
  • utilisez des URL relatives partout : liens, images, styles, scripts… (très pratique si vous changez de nom de domaine ou qu’un dossier doit être déplacé).
  • Placez un fichier favicon.ico à la racine du site.
  • Si une page devient obsolète, indiquez-le sur la page. Ne supprimez jamais une page, au pire déplacez-la.

Pour le codage des pages

  • Préparez-vous un modèle de fichier HTML.
  • Donnez des extensions .php à vos fichiers : perso j’ai débuté avec des fichiers .html qu’il a fallu renommer en .php quand j’ai commencé à utiliser du PHP.
  • Avec PHP : préparez un fichier head.php (contenant les <head> avec les balises classiques) et foot.php (avec un nom de l’auteur, une licence par exemple) et utilisez ensuite un include() ou un readfile() : plus pratique pour changer le header ou le footer sur toutes les pages en une seule fois.
  • Utilisez un encodage de caractère dans la page (ça évitera au navigateur d’en choisir un au hasard).
  • Utilisez l’encodage de caractère UTF-8 au lieu de tout le reste : c’est le plus puissant, le plus universel et le plus pratique (et simple à retenir, en plus de ça), même si ce n’est pas l’ASCII que le W3C recommande.
  • Donnez des versions à vos scripts et à vos pages. Ajoutez (au moins en commentaires) la date de création et la date de dernière mise à jour.
  • N’utilisez jamais des liens raccourcis (dans le genre de tinyurl.com ou de bit.ly) : ils ne sont pas pérennes dans le temps.
  • Prenez le temps de faire un code valide W3C : c’est pas compliqué à faire. Codez un site web correctement ou pas du tout.

Pour les scripts, images, fichiers liés

  • Hébergez tout vous-même. Ne liez rien sur les sites externes (même pas les polices d’écritures de Google Font, ou les images-bouton « like » de Facebook ou Flattr). Idéalement il faut que votre site fonctionne et s’affiche à 100%, même si tous les autres sites au monde sont HS.
  • N’utilisez que des formats standards pour les fichiers : png et jpg au lieu de bmp et gif dans le cas des images, par exemple.
  • Pour les PDF, si vous utilisez l’intégration de Scribd, proposez un lien de téléchargement direct (des chatons meurent tous les jours à cause de liens directs qui manquent)…
  • Mettez des balises alt aux images (obligatoire et important pour la SEO) et des dimensions qui s’adaptent !

Pour le CSS

  • Utilisez du CSS pour le design et le JavaScript pour les évènements sur la page. Le JS ne doit pas être utilisé pour la mise en page.
  • Utilisez un fichier CSS externe pour plusieurs pages. Si vous le modifiez, ce seront toutes les pages qui seront mises à jour d’un coup !
  • Dans le CSS aussi, mettez tous vos fichiers en local, pas vers des @import sur des sites externes.
  • Bannissez les @imports : c’est très mauvais pour la vitesse de chargement des pages (ça aussi, ça tue des chatons et même des poussins !).
  • Si vous ajoutez des propriétés spécifiques pour un navigateur, ajoutez aussi ceux pour les autres navigateurs (-webkit-, -o-, -ms-, -moz-, -khtml-).
  • Ajoutez une feuille de style pour l’impression.
  • Restez au courant des nouvelles propriétés CSS, ainsi que leur support dans les navigateurs.

Dans tous les cas, évitez les trucs listés ici.

26 commentaires

gravatar
qwerty a dit :

Cool ça pour les newbies. A quand une checklist de choses à vérifier avant de lancer un site ?

gravatar
Zblorg a dit :

L'auto-hébergement n'est possible que pour les sites légaux :(

gravatar
Le Hollandais Volant a dit :

@JellyPie : il existe même un « -icab- » pour le très vieux navigateur d’OSX je crois, -rim- pour les BlackBerry, et -xs- pour le module de lecture auditive d’Opera.

Et même plein d’autres, destinées aux imprimantes ou aux télés, comme -hp-, -atsc-, -ah- : http://stackoverflow.com/questions/5411026/list-of-css-vendor-prefixes
Mais cette liste là, bien que longue est loin d’être exhaustive.

@Zblorg : que veux tu dire ? Je peux très bien héberger un site web chez moi, sur mon ordinateur, accessible sur un ordinateur via ma box.
Même si c’est un site à contenu illégal (tant que j’en répond devant la loi après…). De toute façon, un site déclaré illégal ne le sera pas en se basant sur le fait qu’il soit auto-hébergé ou non. Ou alors la France a atteint une atteint extrêmement grave à l’Internet, ses principe, son mode de fonctionnement et son intégrité.
(sinon j’ai sûrement aussi mal compris)

gravatar
Luc a dit :

Héhé :)
Transféré à mes étudiants !!

gravatar
silversthem a dit :
Avec PHP : préparez un fichier head.php (contenant les <head> avec les balises classiques) et foot.php (avec un nom de l’auteur, une licence par exemple) et utilisez ensuite un include() ou un readfile() : plus pratique pour changer le header ou le footer sur toutes les pages en une seule fois.

N'est valable que pour les petits projets, dans un projet de plus grande envergure, on préférera utiliser des templates (en poil plus dur à mettre en place mais une fois que c'est fait on peut difficilement s'en passer)

gravatar
tudok a dit :

Le plus important : faire un site valide. Une extension indiquant la validation en temps réel est très pratique.
Du coup, ça implique d'autres choses précédemment citées (alt sur image, css correct...)

Pour les images, au contraire de ce qu'écrit timo, il faut s'adapter au contenu :
- jpeg pour les photos
- png pour les images avec des niveaux de transparence
- gif pour les images avec un seul niveau de transparence.
Il faut être intelligent, le GIF est un format standard depuis très longtemps ! Et surtout plus efficace en terme de taille pour certaines images que le PNG.

Pour les propriétés spécifiques à un navigateur, au contraire, ne les mettez pas dans le CSS principal, votre site ne sera pas valide CSS ! Et puis ce n'est pas propre de mélanger des propriétés valides et d'autres non validées. Je conseille plutôt l'utilisation d'un CSS par navigateur, seulement pour ceux qui ne gèrent pas certaines choses (ex : un CSS pour IE8, un pour Firefox...). En les mettant à part, vous les retrouverez plus facilement et pourrez les enlever une fois l'instruction validée. Pour leur chargement, des IF en HTML fonctionnent très bien pour spécifier le navigateur qui doit les utiliser.


N'utilisez pas les dossiers pour stocker les pages : l'url rewriting est fait pour ça ! Au contraire, mettez toutes vos pages au même endroit, vous les retrouverez plus facilement. On n'est plus en 1996 !

Mes recommandations au niveau des dossiers :
- js
- css
- rss
- images
- html
- php (ou autre)

Et, mais cela ne s'adresse pas forcément aux débutants, compressez css/images/js/html. Un site comme Google Speed aide beaucoup.

Enfin, l'utilisation d'un cache améliore considérablement les temps de réponses. Utilisez les caches Etags (très très rapide) et un cache logiciel (jpcache ou autre).

gravatar
quent1 a dit :

Bonne checklist. Cependant, j'ai quelques critiques:

Avec PHP : préparez un fichier head.php (contenant les <head> avec les balises classiques) et foot.php (avec un nom de l’auteur, une licence par exemple) et utilisez ensuite un include() ou un readfile() : plus pratique pour changer le header ou le footer sur toutes les pages en une seule fois.

Moi je dis temporisation de sortie! On met tout son thème dans un seul fichier et on gère l'affichage avec des include et une page index.php centrale.

Utilisez un encodage de caractère dans la page (ça évitera au navigateur d’en choisir un au hasard).

Et même dans le header, grâce à PHP:
<?php
header('Content-Type: text/html; charset=UTF-8');
?>

C'est plus pratique et ça accélère (un peu) le chargement.

Donnez des versions à vos scripts et à vos pages. Ajoutez (au moins en commentaires) la date de création et la date de dernière mise à jour.

Mouais, le système de fichier fait déjà ça très bien en natif.

Prenez le temps de faire un code valide W3C : c’est pas compliqué à faire. Codez un site web correctement ou pas du tout.

Je ne sais pas si tu l'as remarqué, mais ton blog n'est pas valide W3C. Après je dis ça je dis rien, hein :D.

J'ajouterai également: optimisez la version publique de vos fichiers CSS/JS/HTML/PNG/JPG. Ça accélère le chargement et c'est bon pour la santé mentale de vos visiteurs.

gravatar
tudok a dit :

@quent1 : Il est presque valide HTML, il y a la balise hgroup, que je ne connaissais pas, qui est indiquée obsolète.

C'est plus au niveau du CSS que le site n'est pas valide. 16 erreurs plus 51 avertissements !!
Pour un moteur de blog, c'est dommage d'industrialiser les erreurs CSS.

http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Flehollandaisvolant.net%2Findex.php%3Fd%3D2013%2F02%2F18%2F20%2F52%2F05-conseils-aux-debutants-qui-commencent-un-site-web%23top&profile=css3&usermedium=all&warning=1&vextwarning=&lang=fr

gravatar
Le Hollandais Volant a dit :

@tudok : la balise hgroup est en effet obsolète depuis… quelques semaines ! Je dois encore mettre à jour mon thème^^.

Concernant le CSS, il est quasiment valide si je retire les éléments propriétaires. Mes ces éléments propriétaires sont ajoutés aux éléments « officiels ». J’ai toujours fait ainsi car l’ajout de ces éléments ne change aucunement le rendu des pages. Ce sont plus des fautes volontaires que des erreurs involontaires.

@tudok : qu’on mette les propriétés CSS -o- ou -moz- dans le fichier principal ou dans un fichier externe peut rendre le site valide CSS, mais ça ne change en rien le fait qu’il le soit réellement ou pas. Je préfère assumer le fait d’utiliser les trucs pas officiels, plutôt que de masquer mes pratiques « douteuses » au validateur.

Pour les images, au contraire de ce qu'écrit timo, il faut s'adapter au contenu :
- jpeg pour les photos
- png pour les images avec des niveaux de transparence
- gif pour les images avec un seul niveau de transparence.

Oui pour le Jpeg, oui pour PNG. En revanche, pour le GIF tout dépend. Pour les très petits fichiers (<500 octets) il est plus efficace, après il est possible d’optimiser les PNG pour qu’ils soient aussi sinon plus efficaces.
Et pour les GIF animés, il existe des PNG animés (aPNG) qui est beaucoup plus léger. Pour certaines images avec très peu de couleurs, le facteur de réduction est de 10. Voici un exemple d’aPNG (fonctionne sous Opera et Firefox actuellement).

Sinon en complément de la compression des images :
http://lehollandaisvolant.net/tuto/pagespd/
http://lehollandaisvolant.net/tuto/html.php

gravatar
Guenhwyvar a dit :

@tudok :

Pour les propriétés spécifiques à un navigateur, au contraire, ne les mettez pas dans le CSS principal, votre site ne sera pas valide CSS ! Et puis ce n'est pas propre de mélanger des propriétés valides et d'autres non validées. Je conseille plutôt l'utilisation d'un CSS par navigateur, seulement pour ceux qui ne gèrent pas certaines choses (ex : un CSS pour IE8, un pour Firefox...). En les mettant à part, vous les retrouverez plus facilement et pourrez les enlever une fois l'instruction validée.

Perso, si je dois modifier un élément particulier, je trouve ça bien plus pratique d'avoir toutes les propriétés au même endroit plutôt que de devoir fouiller dans plusieurs fichiers CSS si y'a éventuellement quelque chose qui concerne cet élément…

gravatar
tudok a dit :

@Guenhwyvar :
"Perso, si je dois modifier un élément particulier, je trouve ça bien plus pratique d'avoir toutes les propriétés au même endroit plutôt que de devoir fouiller dans plusieurs fichiers CSS si y'a éventuellement quelque chose qui concerne cet élément…"

Quand la balise css "border-radius" n'était comprise que par Opera (qui n'a pas créé de -o-border-radius), j'ai créé un fichier css commun à Firefox et Chrome (Firefox-Chrome-CSS3.css) dans lequel j'ai recensé tous les éléments qui utilisaient les propriétés CSS 3.
Une fois la balise validée, je n'ai plus eu qu'à virer tout le fichier. C'est quand même plus simple et ça permet d'avoir une validation CSS pendant le projet.
Et là, je ne parle que du border-radius, mais tout un tas d'autres propriétés CSS3 n'étaient pas encore validées.

Chaque fois que je crée un site, je m'assure d'avoir un validateur CSS/HTML toujours à l'écran. Si je dois laisser passer les balises propriétaires, je ne m'en sors plus (et encore, le W3C les passe en alerte, avant c'était une erreur).

gravatar
remontees a dit :

Excellent article ! Juste une question : aurais-tu une feuille de styles basique pour l'impression à nous fournir. Car c'est vraiment assez long et fastidieux d'en faire une à la main… !

D'autre part, c'est difficile de faire des <svg> qui s'adaptent à la largeur du site, d'où le fait également d'utiliser JS dans ce genre de cas. Tout n'est pas toujours simple !

gravatar
Le Hollandais Volant a dit :

@remontees : Tu peux jeter un œil à ce qu’il y a tout à la fin d’ici : http://lehollandaisvolant.net/themes/ut/style.css?3

Évidemment ça s’adapte à mon thème, mais voici ce que j’aurais mis pour un thème passe partout pour l’impression :




@media print {
body, .post {
font-family:"DejaVu Serif", "Times New Roman", Times, serif; /* serif fonts are more readable on paper */
}
* {
background: none!important;
text-shadow: none!important;
box-shadow: none!important;
color: black!important;
}

#sidebar, #menu, #form-commentaire, #footer {
display: none; /* hides things that are not usefull once printed : menus, forms… */
}
a[href]:after { /* shows the href="" content after the link */
content:" (" attr(href) ")";
font-style: italic;
color: #0000ff;
}
a[href]:before {
content:"*";
}

*[title]:after { /* shows the titles aswell */
content:" (" attr(title) ")";
font-style: italic;
color: #0000ff;
}

pre, blockquote {
border: 1px solid gray;
}

img, pre, blockquote {
page-break-inside:avoid;
}

p, h2, h3 {
widows: 3; /* avoids having pages with less than 3 lines of text */
orphans: 3; /* same but avoids that less than 3 lines from a same <p> are let alone on prev page */
}
h2, h3, h4 { /* avoids having pages-breaks right after a title */
page-break-after:avoid;
}
}


Y’a sûrement beaucoup de choses à ajouter, comme la taille de polices.

Ici :
– la police est mise en sérif et en noire, sans ombres
– les images/couleurs de fond sont supprimées
– tout ce qui est uniquement utile à la navigations (formulaires, menus, footers…) sont virés (à appliquer pour chaque template)
– les liens et éléments avec un "title" affichent le contenu du « href » et du « title » après l’élément, en rouge.
– les changements de pages sont évitées dans les images, <pre> et <blockquotes>.
– les césures des pages sont optimisées pour éviter d’avoir soit une page avec moins de 3 lignes (ou un paragraphe coupé pour 3 lignes de texte), soit un titre sur une page et le contenu sur l’autre.

gravatar
fil2fer a dit :

Bonsoir :)

Tiens ,à propos de Web,est-ce que quelqu'un aurait des infos sur le probable remplacement de Javascript par Dart (Google)?
J'avoue que le "tout Goût-Gueule" est vraiment flippant .

gravatar
Sylvhem a dit :

Merci beaucoup pour cette liste des préfixes vendeurs CCS (donnée dans tes liens), je cherchais justement quelque chose comme ça. Le problème, c'est que ce n'est pas tout le temps simple de savoir si l'utilisation d'un préfixe particulier et pertinent pour une propriété donnée. Pour les principaux moteurs de rendu ça va, il suffit d'utiliser Can I Use ou un site équivalent, mais pour les autres ? Par exemple, est-ce que je dois ajouter -icab-linear-gradient dans mon code ? Ou, encore plus compliqué, -xs-linear-gradient, vu qu'il s'agit d'un module de lecture auditive ?
Par contre, il vaut mieux placer un favicon.png que un favicon.ico à la racine du site, ce dernier étant un format fermé propre à Microsoft.

@tudok : Jamais de GIF ! Le GIF est non seulement un format fermé, mais il est en plus complètement obsolète, et ce depuis bien longtemps (comme l'a dit Timo, si le PNG est bien optimisé, on peut obtenir un résultat assez proche) et il n'est en aucun cas standard. Répandu oui, standard non.

@tudok : hgroup, était une balise de HTML5, donc expérimentale. Apparemment, elle ne fera jamais partie des spécifications finales...

@remontees : Il y a un article d'Alsacreations qui me semble correspondre à ce que tu cherches Une feuille de style de base pour le media print.

@fil2fer : Ça ne serait pas l'improbable remplacement plutôt ? Il ne me semble pas que Dart déchaîne les foules (mais je peux me tromper)...

gravatar
Hegurka a dit :

@Sylvhem :
Personnellement j'ai abandonné le .gif depuis 1998, mais il se trouve récemment que pour une production HTML très spéciale, j'ai dû me fournir en images légères, nombreuses, et toutes comparaisons faites, ce sont des images .gif que j'ai choisies car elles étaient les seules suffisamment légères pour me convenir.
Je veux dire par là qu'on s'en contrefout que .gif soit plus ou moins fermé, plus ou moins standard, si tu as ton image pour 10 ko par exemple au lieu de 90 ko et qu'elle est correcte, où est le problème ?
Des pixels répondant parfaitement à une cartographie deviendraient "obsolètes" par l'effet du Saint-Esprit !? Pourquoi obsolètes ? [Et je ne te dis pas à quel point je fuis les .gif depuis 15 ans !!! Mais... tout est relatif n'est-ce pas ?]

gravatar
Le Hollandais Volant a dit :

@Sylvhem : pour le favicon, un fichier .ico sera pris en compte par les navigateurs alors que le même en .png ne le sera pas (et en effet : merci Microsoft, et IE qui même dans sa #@%*$ de version 10 ne prend pas en compte le PNG pour les favicon).

Concernant le GIF, je ne le boycotte pas. Mais je préfère le PNG : les palettes de couleurs sont par défaut plus adaptées. Certaines pages utiliser des images animées : désormais je les fournit en aPNG avec un fallback manuel (un lien « si ça marche pas ») vers un Gif : le PNG est beaucoup plus léger.

gravatar
Sarah a dit :

Perso pour ceux qui débutent, je leur conseillerais directement d'installer un wordpress, à moins d'être vraiment motivé!

gravatar
Fox a dit :

@Le Hollandais Volant :
Le format SVG devient également très intéressant vis à vis du poids, bien entendu de la qualité, mais aussi de la compatibilité navigateurs. Un fallback est tout-à-fait possible (voir ci-dessous), alors autant ne pas s'en priver. Je me suis également rendu compte récemment que le format SVGZ (SVG compressé) divisait encore et encore le poids du graphique. C'est génial !

<object type="image/svg+xml" data="image.svgz">
<img src="image.png" width="150" height="150" alt="img">
</object>

gravatar
tudok a dit :

@Sylvhem :
" Jamais de GIF ! Le GIF est non seulement un format fermé, mais il est en plus complètement obsolète, et ce depuis bien longtemps (comme l'a dit Timo, si le PNG est bien optimisé, on peut obtenir un résultat assez proche) et il n'est en aucun cas standard. Répandu oui, standard non."

1) On s'en fout qu'il soit fermé. Tu vas voir le code des logiciels ouverts ? Moi, quasiment jamais.
2) On s'en fout qu'il soit obsolète. Tu changes de format à chaque nouvelle version ?
- Le JPEG est obsolète par rapport au JPEG2000 aussi.
- Le MP3 stéréo est obsolète par rapport au 5.1.
- Le DVD est obsolète par rapport au Blu-Ray.
Ca n'empêche pas les gens de préférer du MP3 stéréo, du DIVX au Blu-Ray alors que le Blu-Ray est bien meilleur en qualité d'image et de son.
3) Un PNG optimisé peut obtenir un résultat proche : oui, proche mais pas égal, donc ! En se faisant chier à optimiser un fichier PNG, tu n'arrives même pas à avoir mieux en terme de taille ?! Quel intérêt ?

gravatar
Modulo a dit :

@tudok :
1) On s'en fout qu'il soit fermé ->
http://casteyde.christian.free.fr/system/linux/guide/online/x255.html
http://philippe.scoffoni.net/licence-proprietaire-open-source-ou-libre-quelles-avantages-et-inconvenients-pour-lancer-un-nouveau-logiciel/

2)
...
Le MP3 stéréo est obsolète par rapport au 5.1. -> le MP3 n'a rien a voir avec le 5.1, on peut comparer le MP3 avec AAC ou l'OGG vorbis par exemple.

3) le PNG donne généralement de meilleurs résultats que le GIF si on limite le nombre de couleurs à 256 (le GIF est limité à 256 couleurs).

gravatar
Modulo a dit :

« Le format GIF est dorénavant dans le domaine public » source wikipedia

gravatar
mise à jour de site internet a dit :

La mise à jour du site internet est la question que devrait se poser n'importe quelle personne avant de se lancer dans la création de sa plateforme. Car de la réponse à cette question découle de nombreuses choses : dois-je baser mon site web sur un CMS ou est-ce que je me préfère l'élaborer "de A à Z" avec l'html, le css... et le cas échéant, le PHP ? Est-ce que je me forme pour maîtriser parfaitement ces langages de programmation pour créer un site comme on dirait à l'ancienne ? Ou est-ce que je me contente de suivre un tuto sur Wordpress et Joomla pour installer ma base, puisque la gestion de mon site web (par exemple la rédaction de mes articles) à l'avenir ne nécessitera pas d'approfondissement en html ?...

Les commentaires sont fermés pour cet article