Lors de la refonte d’un site, le prestataire à tendance à vouloir tout refaire sous prétexte que l’existant est inadapté, c’est peut être vrai, et d’ailleurs très souvent le cas, mais dans ce cas il faut réfléchir et travailler pour que cela ne se reproduise pas systématiquement à chaque version. Si le projet est bien pensé, une refonte graphique et quelques développements peuvent suffire la plupart du temps, à moins bien sûr que le fonctionnel change du tout au tout ou qu’un autre paramètre important ai changé de manière significative.

Comment prévoir et intégrer les évolutions du projet ? Quelles questions se poser ? Quelles sont les erreurs à ne pas faire ? Voilà tout l’enjeu de cette réflexion.

Photo de slinky2000 depuis Flickr

Modularité

Avec les moyens actuels, et le développement en couche, on peut facilement changer une partie d’un projet sans toucher au reste. Le principe MVC permet par exemple de changer complètement l’affichage de votre site sans toucher à la partie métier. On peut ainsi cloisonner le projet, les différentes parties travaillant chacune de leur coté, mais ensemble.

Il faut pour cela réfléchir à certains points en amont du projet. Voyons les questions à se poser le plus tôt possible.

Volumétrie

Le choix d’un site marchand est évident si vous vous lancez dans la vente, mais si vous commencez avec de faibles volumes, un site vitrine est peut être plus approprié, votre projet à 30 000 € peut attendre… Tout dépends de vos ambitions !

Et côté hébergement, suivants vos besoins actuels et à moyenne échéance, en terme de ressources processeur ou de bande passante, les extensions nécessaires, le prix… Il faudra faire le tri et trouver un hébergement au meilleur rapport qualité prix, mais facilement évolutif pour pouvoir migrer vers une offre supérieure simplement.

Je vous invite à voir l’article de Webaaz sur l’hébergement web.

Prévoyez donc de dimensionner votre projet en fonction de vos besoins à court terme et des évolutions à venir.

Fonctionnalités

On ne peut bien évidemment pas aborder ici toutes les problématiques fonctionnelles, voyons donc en deux points qui nous serviront d’exemple, comment envisager ces questions.

Public visé

En fonction de votre cible, vous ne ferez pas le même site web. Le collaboratif c’est plutôt orienté vers la génération X et la génération Xgénération Y, alors si vous vous adressez à un public plus âgé, faites plus simple, avec une ergonomie adaptée, des boutons plus gros par exemple…

Pensez tout de même à toujours garder votre site accessible à tous pour ne pas vous couper d’une partie de la population !

Multilinguisme

Sur le web votre site est accessible par tout le monde. Même les internautes auxquels vous n’avez pas pensé. Ils ont aussi le droit d’y venir, et même de consommer ! Vous n’allez tout de même pas vous priver de ces clients sous prétexte de ne pas parler la même langue ?

Bon, peut être que dans un premier temps vous ne pensez pas à cela et que votre marché est francophone, mais vous avez déjà pensé à vous étendre par la suite, alors dites le ! Intégrer plusieurs langues dans un site existant est très couteux, et oblige à revoir le site en profondeur, alors que développer un site multilingue n’est pas beaucoup plus compliqué qu’un site en une seule langue.

Alors à moins d’être sur un périmètre géographique très restreint, prévoyez ! Voyez grand !

Technologie

Je vais passer pour quelqu’un d’arriéré, mais non un site web statique n’est pas dépassé ! Même si aujourd’hui les besoins évoluent et que la mode est au web social, au web 2.0, à l’interactivité, posez vous la question : Ai-je besoin de tout cela ?

Si votre site ne nécessite que peu de pages et peu de mises à jour, un site vitrine fera parfaitement l’affaire. Pourquoi mettre une usine à gaz pour si peu de besoins ?

Et même si votre projet doit être dynamique, les fonctionnalités qui manquent à votre CMS ou à votre blog ne peuvent elles pas être juste des pages statiques en plus ?

Au final, des pages statiques, ce n’est pas forcément moins évolutif qu’un code dynamique.

Cahier des charges

Pour réunir toutes ces réflexions, et le résultat de toutes ces questions, un cahier des charges s’impose. Fonctionnel dans un premier temps pour définir clairement les besoins. Technique ensuite pour expliquer les moyens de répondre à la demande.

Fonctionnel

Vous pourrez y expliquer vos besoins précis en fonctionnalités en expliquant les règles métier spécifiques à votre entreprise.

Technique

Il sert à définir les solutions techniques retenues et la manière de les mettre en œuvre. Le développeur s’appuie dessus pour développer votre site web. Tout y est expliqué et en théorie, il y trouve toutes les réponses à ses questions.

Evolutivité

Coté évolutivité, il y a du boulot ! Il va falloir penser à ce dont vous aller avoir besoin, sans pour autant penser à des fonctionnalités que vous n’êtes pas sûrs d’utiliser, ce qui serait totalement contre productif. Si vous êtes une PME, n’imaginez pas que votre site vitrine puisse se transformer en site marchand ou en réseau social, mais pensez que vous aurez besoin de nouvelles pages pour les nouvelles agences du groupe par exemple.

Vous avez besoin de donner accès à votre catalogue à d’autres application ? Développez un webservice qui pourra resservir et évoluer.

Mise en œuvre

Je le fais moi même ou je le fais faire ?

La question ne se pose bien évidemment que pour un site perso, ou un site pro très simple genre site vitrine. Pour de plus grosses structures, c’est une question de crédibilité (encore que ce ne soit pas le cas pour tout le monde).

Pour un site plus conséquent, le temps, les compétences nécessaires et le résultat attendu ne vous laisseront bien évidemment pas le choix.

Bien sûr faire soi même son site web demande des compétences, mais pour un petit projet et pour peu que cela vous intéresse c’est tout à fait possible. Différentes formations abordent le sujet de façon plus ou moins approfondie.

L’article de Webaaz sur les formations web vous en apprendra plus sur le sujet.

Conclusion

Le but est de penser à tout ce qui pourrait arriver, et supprimer finalement tout ce qui n’arrivera pas. Quand on a enlevé tout le superflu, il ne reste que l’essentiel, et c’est ce dont vous avez besoin !

Vos besoins évolueront probablement, et lors de la prochaine refonte vous vous reposerez les mêmes questions, et vous n’aurez sûrement pas les mêmes réponses. Votre prestataire Internet vous dira peut être qu’il faut tout refaire, et il aura peut être raison, mais l’existant pourra resservir en partie grâce à la modularité ! C’est déjà ca de gagné !

Mise à jour

Le sujet est un peu vaste pour être abordé de façon complète dans un seul article. Je complèterai donc cet article et j’aborderai des sujets connexes de manière plus précise par la suite, en fonction de vos retours.

A vos commentaires !

Sur le même thème

• Réinventer la roue, ou pas ?
• Les plugins Firefox : XRefresh
• Les plugins Firefox : Colorzilla
• MySQL GUI Tools
• Bien utiliser Zend Framework

Il faut bien avoir en tête que ce sont les petits gains par ci par là qui feront la différence. Cela vous demandera finalement assez peu de travail pour les premiers résultats et beaucoup plus pour arriver à un résultat parfait. Mais même sans pousser la démarche jusqu’au bout, l’effet sera bénéfique en termes d’audience, et votre taux de transformation devrait augmenter lui aussi.

Voici donc quelques conseils, et quelques références afin de maîtriser le sujet

Photo de GemMoth depuis Flickr

L’optimisation c’est quoi ?

On peut voir dans un premier temps l’optimisation comme la mise en œuvre des moyens disponibles pour améliorer l’existant. Un second temps permet d’accentuer encore les performances en ajoutant de nouveaux moyens. Nous traiterons uniquement du premier point ici. Changer d’hébergeur ou de serveur pour augmenter vos performances est un solution, mais avant cela tout un panel de techniques permet de faire mieux avec les mêmes ressources.

Quelques statistiques

La taille des pages a plus que triplé en 5 ans, passant de 90Ko à 310Ko. Dans le même temps on a aussi doublé le nombre de composants externes par page (de 25 à 50)Une page web c’est en moyenne 500 mots et 600 balises HTML ! Si l’on ajoute a cela que le nombre de connexion RTC est encore non négligeable aux États-Unis par exemple.

Perdre 500ms c’est perdre 20% de trafic pour Google et réduire de 25% le poids de la page c’est gagner 25% d’utilisateurs à moyen terme pour Google. Augmenter la latence de 100ms c’est perdre 1% de ventes pour Amazon. Pour Yahoo! perdre 400ms c’est avoir 5 à 9% d’abandon en plus.

A partir de 4 secondes d’attente on perd massivement les visiteurs…

Que doit on améliorer ?

Les améliorations à prévoir sont au niveau du paramétrage du serveur, de la qualité du code, de choix techniques, de la gestion des composants web…

Des outils sont là pour vous aider à identifier les points importants parmi lesquels on trouve des plugins Firefox :

• Yslow
• Google Page Speed

Et des sites de mesure de performance :

• site-perf
• IBM Page Detailer
• Web Pagetest

Notez que ces derniers pourrons vous permettre de tester votre site depuis l’autre bout du monde et voir les impacts que cela a sur votre site.

Deux règles principales pour la performance des sites web sont de réduire le nombre de requêtes HTTP et de limiter la taille des données qu’on télécharge. Voyons cela plus en détail.

Optimisation de la configuration du serveur

La mise en cache

La mise en place d’un cache côté serveur est une bonne chose et permettra de fournir un contenu plus rapidement à l’internaute, mais le protocole HTTP permet lui aussi quelques prouesses. Il est efficace pour la moitié des utilisateurs qui affichent une première page de votre site. Soit parce qu’ils sont déjà venus auparavant ou parce que vous partagez des ressources avec d’autres sites via des CDN.
Dès la deuxième page de votre site il est bénéfique pour 80% des utilisateurs, les 20% restants ayant par exemple désactivé leur cache.

Configurez donc votre serveur pour qu’il envoie des indications de mise en cache au navigateur.

La compression des données

On peut gagner entre 50 et 90% du poids d’une page pour une occupation serveur de 5%. Si votre serveur le permet en terme de ressources, le bénéfice sera immédiat, et encore plus pour les connexions lentes.

• Tests de compression de pages web
• Visualiseur de ressources réseau

ETags

Désactivez les ETags si le site est en cluster. Leur performance est alors très aléatoire. Si vous n’avez pas de cluster, vous pouvez les laisser, même si YSlow vous fait la remarque.

Impacts de la latence réseau

Avec un temps de latence avec le serveur de 20ms, pour 25 requêtes externes on perd donc une demi seconde ! Et encore le temps de latence est plus souvent entre 30 et 60 ms. On peut cependant relativiser un peu car la parallélisation des téléchargements permet de limiter cet effet.

Il est donc important de limiter le nombre de composants à charger par page.

L’utilisation de connexions persistantes sur des serveurs statiques (CDN) paraît être un bon moyen de limiter les effets de la latence, mais son paramétrage peut être délicat et dépends de votre cas particulier. L’abus de cette techniques pourrait avoir l’effet inverse en engorgeant le serveur de connexions persistantes inutiles.

Pour la concaténation de vos fichiers, un module d’Apache permet de faire le travail côté serveur, je ne l’ai pas testé, mais j’attends vos retours sur le sujet dans les commentaires :

• Mod_concat

Optimisation du code source

HTML

Un code standard limite le travail de l’interpréteur HTML, par rapport à un code illisible que le navigateur devra corriger à la volée.
Limiter la profondeur du DOM pour limiter le reflow, c’est à dire la réorganisation de la page par le navigateur en cas de changements au niveau de la structure de la page. Pour les tableaux vous pouvez utiliser le mode de rendu fixe des tableaux HTML pour limiter le reflow.

Vous devez limiter les iframes qui sont coûteuses en termes de performances, même vides.

CSS

Pour les frameworks CSS, utiliser un cache central (google, yahoo…) permet de partager un cache avec tous les autres utilisateurs du CDN. Ainsi il y a de fortes chances pour que vos librairies soient déjà en cache dans le navigateur de votre visiteur.

Mettre les scripts en début de page pour que le navigateur puisse faire la mise en page le plus tôt possible.
L’utilisation conjointe de scripts externes minimisés, permet de gagner jusqu’à 25% du poids des feuilles de style.

Ne pas utiliser @import pour les CSS, moins performant et ne pas utiliser les filtres CSS, non standard et très coûteux en ressources. Si vous avez des modifications CSS à faire, faites les d’un seul coup pour éviter le reflow et non pas dans une boucle !

Javascript

Pour les bibliothèques génériques (jQuery, Dojo…) l’utilisation d’un cache central (google, yahoo…) permet comme pour les CSS de partager un cache avec tous les autres utilisateurs du CDN.

Pour optimiser encore mettez les scripts en fin de page. Le navigateur pourra afficher la page correctement avant de les charger, et l’utilisateur pourra naviguer avant la fin du chargement. Le temps qu’il interagisse avec la page, le Javascript sera chargé.

Comme pour les CCS, des scripts externes minimisés, permettent de gagner jusqu’à un tiers du poids des fichiers.

• CSSOptimiser
• CleanCSS

Et dans vos scripts utilisez des sélecteurs précis basés sur l’id et pas sur les classes css, l’identifiant étant unique la navigateur retrouve plus facilement la balise demandée; que si il doit analyser toutes celles de la page.

Ajax

Ajax permet d’améliorer le ressenti utilisateur en limitant le rechargement de la page au strict minimum. C’est donc une bonne piste d’optimisation, mais attention à le faire le mieux possible. Pour cela, envoyer les requêtes AJAX avec la méthode get et utiliser le cache de requête HTTP.
Pour le format de données vous pouvez utiliser JSON ou XML, les deux solutions ont leurs avantages et inconvénients, mais sont bien plus performantes que d’envoyer du code HTML pur !

Optimisation des images

Les formats d’image

En JPEG on peut gagner jusqu’à 90% du poids d’une image avec une perte acceptable (compression autour de 55, à tester car chaque logiciel implémente sa propre échelle de compression). Idéal pour les photos.

En PNG on peut gagner entre 75 et 90% du poids de l’image sans perte. Idéal pour des images avec du texte. Attention à prendre du PNG8 et non pas 24 !

Le GIF ne devrait jamais être utilisé, sauf éventuellement pour du GIF animé.

Sprites et métadatas

L’utilisation des sprites, permet de diminuer l’impact du temps de latence et le poids des images. Le poids du sprite généré est inférieur à la somme des images qui le composent !

• Sprites CSS : Meurs, découpe d’images, meurs !
• CSSSprites
• SpriteGen

La suppression des metadata des images avec Smushit, Optipng, Pngcrush ou PunyPng apporte un gain de 15% environ du poids des images en supprimant les données inutiles dans un contexte web des photos.

• PNGCrush
• OptiPNG
• PunyPNG

Favicon

Même si il n’est pas spécifié, les navigateurs le cherchent et chargent une page 404 si il n’est pas présent. Cela peut donc être très coûteux, surtout si votre page d’erreur personnalisée est lourde.

Ma référence pour avoir des information et des tests sur le traitement des images :

• CSS-IG : Optimisation Web, format PNG

D’autres pistes d’optimisation

Il faut à tout prix limiter les redirections sur la page d’accueil, cela augmente la latence et n’est souvent qu’un mauvais palliatif à une solution plus pérenne. Ce n’est d’ailleurs pas bon non plus pour votre référencement.

Les cookies

Un cookie est envoyé avec chaque requête http, il faut limiter strictement leur taille, un cookie de 1ko retarde la réponse de 16ms en moyenne, avec 50 composants dans la page, on gagne donc 0,8s ! Il faut donc si vous le pouvez limiter les cookies aux sous domaines afin qu’il s n’impactent pas le téléchargement des autres ressources. En utilisant un CDN ou un sous domaines pour les données statiques, vous règlerez le problème.

DNS

Le temps de résolution d’un domaine tourne autour de 30ms. Multiplier le nombre de domaine permet de paralléliser les téléchargements. Certains « vieux » navigateurs ne téléchargent que deux ressources simultanément, mais les plus récents en prennent 4 fois plus en moyenne. Limiter le nombre de domaines à 4 est un bon compromis.

Buffer

Il est important également d’envoyer votre buffer le plus rapidement possible. L’utilisateur verra sa page commencer à se charger plus rapidement. Son ressenti sera bien meilleur, surtout si les temps de génération de votre page sont longs.

Références utiles

Une des meilleures références sur le sujet est en français. Vous y trouverez beaucoup d’explications

• Le blog d’Éric Daspet sur les performances web

Les autres en anglais sont aussi de très bonne facture :

• Les bonnes pratiques par Yahoo
• Les bonnes pratiques par Google
• Le blog de Steve Souders

Conclusion

Une fois tous ces éléments mis en place, votre site doit avoir retrouvé de sa vigueur et si tout n’est pas encore parfait, il est peut être temps de passer à l’étape deux. Votre site à probablement besoins de moyens spécifiques, mais ces conseils lui sont déjà profitables et sont suffisants pour la plupart des projets web.

un livre sur le sujet devrait paraitre bientôt, je ne manquerai pas de vous tenir informé !

Merci à Eric Daspet de m’avoir ouvert les yeux sur ce sujet aussi utile que passionnant.

Sur le même thème

• Les générateurs de sprites CSS
• Bien utiliser les feuilles de style (CSS)
• Les plugins Firefox : Colorzilla
• Navigateur Web standard : Firefox
• Trouver un bon hebergeur web, quels critères ?

Partageons donc ces expériences, voici quelques conseils pour trouver l’hébergeur web qui correspond à vos besoins, en termes de capacité de stockage, de bande passante, de technologies utilisée, de support ou de qualités de service.

Photo de edgar asencios depuis Flickr

Identifier le besoin

Nous n’aborderons pas ici les points techniques, vous savez bien si vous avez besoin de PHP5 ou de Java, d’une base de données MySQL ou PostGreSQL, nous verrons plutôt tout ce qui tourne autour et auquel on ne fait pas forcément attention au premier abord mais qui est pourtant essentiel.

Basique

Le premier point important est d’identifier le besoin. Si vous hébergez un blog, vos besoins seront sans doutes minimes en termes de performances, pensez éventuellement à prévoir un peu de place si vous comptez offrir à vos visiteurs de la vidéo, ou un contenu riche en photos haute définition. Les offres d’hébergement premier prix sur des serveurs mutualisés sont légions il faudra juste faire attention aux détails (version des base de données, paramétrage de PHP…). Comptez entre 0€ et 4€ par mois en moyenne.

Modéré

Si vous pensez avoir un certain nombre de visiteurs, mais que votre budget est limité, il vous faudra alors une offre mutualisée, mais avec de plus fortes capacités, certaines permettent d’obtenir de très bons rapports performance/prix. Il faudra prévoir un budget entre 3€ et 10€ par mois.

Important

Si votre capacité financière le permet et si l’importance de votre projet le nécessite, vous pouvez passer sur un serveur dédié, vous serez le seul à héberger vos sites sur cette machine, le résultat sera forcément de bonne qualité, faites tout de même attention, car dans ce domaine également, tous les serveurs ne se valent pas, et il faudra qu’il soit dimensionné en fonction de vos besoins spécifiques. Les prix démarrent à 10€ par mois pour les offres les plus basiques et montent à plusieurs centaines d’euros par mois. Mais plusieurs offres autour de 30€ par mois permettent un bon compromis pour débuter avec un dédié sans trop de frais.

Un autre type d’offre se développe maintenant, la virtualisation. Cela consiste héberger les sites web sur des serveurs virtuels situés sur des serveurs physiques. Pour simplifier on mutualise des grappes de serveurs tout en gardant la souplesse du serveur dédié. On peut même paramétrer l’ensemble pour ajouter de la puissance de calcul si les besoins augmentent ou baisser automatiquement quand la charge redescend.

A terme j’imagine que tous les hébergement seront sur la base de serveurs virtuels, tant cela apporte en termes de souplesse autant à l’hébergeur qu’a l’hébergé.

Gratuit contre payant

Alors si vous êtes dans le premier cas cité ci-dessus, à savoir un blog ou un site web simple, la question peut se poser de choisir entre une offre gratuite, souvent proposée par votre FAI et une offre payante bon marché. Si vous débutez n’hésitez pas à tester vos première pages sur un hébergement gratuit, et si le besoin s’en fait sentir passez au payant, certaines offres sont très abordables et vous apporteront plus de qualité et de possibilités techniques. Un hébergeur payant sera forcément mieux qu’un gratuit, les offres évoluent plus souvent pour suivre les avancées techniques, les temps d’indisponibilités seront plus faibles, et vous ne serez pas limité sur certaines options comme l’envoi de mail par exemple.

Mutualisé contre dédié

Là encore à moins d’avoir un gros projet qui nécessitera rapidement de gros moyens, pour des projets non professionnels la suite logique est de commencer sur un serveur mutualisé et de monter en gamme progressivement jusqu’à ce que le serveur dédié s’impose.

Une autre bonne raison de passer au serveur dédié est d’avoir besoin de spécificités techniques qu’un hébergeur mutualisé ne pourra pas vous fournir. Si vous avez besoin de capacité de calcul très importantes ou de paramétrages particuliers, d’un OS spécifique, ou tout simplement d’avoir la main pour redémarrer suivant vos besoins, vous pourrez également changer de versions logicielles quand bon vous semble, et pas quand l’hébergeur l’aura décidé. Si votre application est critique, c’est le bon choix.

Si vos besoins explosent, alors vous pouvez même louer des baies chez un hébergeur pour y mettre vos propres serveurs, mais là c’est une autre histoire…

Et si vous n’y connaissez rien mais que vos besoin vous obligent à prendre un serveur dédié, des solutions d’inforgérance vous permettent de laisser la partie technique à un prestataire compétent.

Et le cloud computing alors ? Et les CDN ?

Une autre possibilité s’offre à vous si vous avez de gros besoins c’est la nouvelle tendance du moment : Le cloud computing. On est dans la virtualisation mais avec des moyens infinis grâce à des datacenters inter-connectés entre eux qui fournissent une puissance de calcul énorme. Vous payez en fonction des ressources serveur et réseaux réellement consommées.
Vous pouvez donc imaginer utiliser ce « système en nuages » pour héberger votre application ou juste pour effectuer des calculs coûteux en ressources via un webservice.

Si vos besoins sont importants en termes de ressources statiques notamment si vous souhaitez disposer d’une bande passante importante et partager vos données entre des datacenters répartis dans le monde entier pour fournir des pages à vos visiteurs dans un temps record, alors intérresez vous aux CDN. Certains services offrent même une offre de base gratuite, idéale pour se faire une idée.

Trouver des avis

Alors avant de franchir le pas et de vous jeter sur le premier hébergeur venu, essayez d’avoir des informations, des retours de clients bons et mauvais afin de vous faire une idée précise de ce qui vous attends. En tapant le nom de l’hébergeur dans Google, vous devriez déjà en savoir un peu plus. D’autres solutions existent, des comparateurs d’hébergement existent, ils recensent les offres et les avis des consommateurs. Demandez également autour de vous, aujourd’hui on connait tous quelqu’un qui à son site web, et il à sûrement de bons conseils, car une fois lié à un hébergeur pour un an ou plus, changer vous coûtera financièrement et la migration en elle même peut être compliquée.
Regardez aussi les forums de l’hébergeur, pour voir si les clients se plaignent et si les réponses apportées sont de qualité ou si l’hébergeur ne s’en préoccupe même pas !

Tester

Certains hébergeur proposent une période de test gratuit, ou un accès au panneau d’administration, profitez-en pour pour vérifier que l’hébergement tient toutes ses promesses et que l’ergonomie de l’interface de gestion est simple à appréhender. Vérifier que vos scripts sont traités rapidement et que vous ne risquez pas de regretter votre choix.
Pensez également à tester le support en posant des questions technique au service client pour évaluer leur rapidité et leur compétence technique. Je suis pour ma part déjà tombé sur des hébergeurs totalement incompétents !

Mes choix

Voici les hébergeurs dont je suis satisfait :

• OVH
• Nuxit

Je suis resté plusieurs années chez Nuxit, et je viens de migrer chez OVH car j’avais des besoins particuliers, notamment un serveur SVN et un accès SSH. Nuxit ne proposant pas ces options, j’ai donc décidé de changer, mais je conseille vraiment Nuxit, pour sa qualité de service et la rapidité de son service technique. Je n’ai jamais eu à m’en plaindre et je vous le recommande fortement.

Pour ce qui est d’OVH, je n’ai pas encore le recul nécessaire, mais sa réputation est bonne et pour le moment je n’ai pas à m’en plaindre, tout fonctionne très bien.

Prévoir les montées en charge

Pensez à vérifier que votre hébergeur proposent d’autres offres vous permettant d’upgrader votre solution facilement si le besoin s’en fait sentir, cela vous évitera des désagréments.
Pensez aussi à bien optimiser vos sites web, bien souvent une optimisation permet d’éviter de prendre une offre plus coûteuse pour le même résultat.

Ne pas mettre tous ses œufs dans le même panier

Si vous avez plusieurs sites, n’hésitez pas à prendre des hébergements séparés pour gérer séparément chaque site. Vous aurez ainsi la possibilité d’avoir des statistiques plus précises, pouvoir évoluer suivant les besoins de chaque site, avoir une arborescence simplifiée, si un site prends beaucoup de ressources, il n’impactera pas directement les autres… C’est cette solution que j’ai prise dernièrement, et au final cela ne me coûte pas plus cher pour une plus grande souplesse.

L’hébergement maison

Je n’ai pas abordé ce sujet, mais la possibilité existe d’héberger votre site web directement chez vous, sur un ordinateur dédié ou sur votre pc, mais ces solutions nécessitent de connaître parfaitement le sujet et ne sont pas sans inconvénients. Votre bande passante ne suffira probablement pas à offrir un service de qualités à vos visiteurs, et les coûts en électricité ne sont pas anodins, comptez autour de 70€ par an… Cette solution n’est donc pas viable dans la très grande majorité des cas.

Vérifier que tout est fonctionne bien

Une fois que votre site est en place, surveillez le activement pour voir si il n’est pas indisponible, vérifiez les statistiques, le temps de chargement des pages, et n’hésitez pas à faire des retours et des suggestions au service technique afin d’améliorer la qualité du service.

Rassurez vous, en général tout se passe bien, et vous pouvez vous concentrer sur votre site, mais il y aura toujours des points à surveiller, à commencer pas ne pas oublier de renouveler votre hébergement dans les délais…

Avez vous vous aussi des conseils ou des expériences à partager sur le sujet ?

Sur le même thème

• Trouver un bon hebergeur web, quels critères ?
• La gestion des versions
• Les bons outils pour PHP (partie 2)
• Bien définir son projet de site web
• Les plugins Firefox : FoxyProxy

Photo de Bensonkua depuis Flickr

Définition

Vous en avez peut être déjà vues sur certains sites officiels, souvent présentées au format PDF, sur une ou plusieurs pages, les cheat sheets, ou antisèches en français, sont un condensé des informations pas forcément facile à retenir, ou des informations que l’on se doit de connaître.

Ou les trouver ?

Plutôt que de les trouver par hasard ou de les rechercher pendant des heures, plutôt que de faire un aide-mémoire pour noter les urls de ces cheat sheets, je vous conseille de chercher à la source, puisque quelques sites en recensent plusieurs centaines triées par thèmes :

• Cheat Sheets
• Tech cheat sheets

Bien sûr ces différents sites présentent pour la plupart les mêmes contenus, à vous de voir celui qui vous convient le mieux. Pour ma part j’utilise Pushing Buttons.

Les mémentos

Très utiles aussi, la collection de mémentos chez Eyrolles, c’est l’équivalent des cheat sheets sur support physique, dans un format réduit et plastifié, ces fiches de très bonne qualité sont rédigées par des experts en la matière. En voici quelques uns :

• Mémento PHP5 & SQL de Cyril Pierre de Geyer et Guillaume Ponçon
• Mémento XHTML de Raphaël Goetter
• Mémento CSS de Raphaël Gotter

Il en existe d’autres sur les sujets suivants :

• Unix/Linux de Isabelle Hurbain
• Ergonomie web d’Amélie Boucher
• Sites web, les bonnes pratiques, d’Elie Sloïm
• MySQL de Rodolphe Rimelé

Conclusion

Avec toutes ces fiches vous voilà paré pour vos prochains développements. Avez vous vous aussi quelques sites de références pour les antisèches ?

Sur le même thème

• Bien écrire HTML & XHTML
• Bien utiliser les feuilles de style (CSS)
• Bien développer en PHP (partie 1)
• Veille techno Web de A à F (partie 1)
• Développer en équipe