Si vous devez maintenir un site Web ou si vous maintenez au moins une page web, vous devez penser à ce que vous offrez au réseau et à l'approche du lecteur/utilisateur de vos pages.
Eh bien, je ne vais pas vous dire comment le HTML est encodé et comment vous devez concevoir vos pages. Je vais juste vous donner quelques pointeurs où vous pourrez trouver des informations supplémentaires.
Vous devriez aller voir http://www.w3.org pour la dernière spécification du langage HTML.
Jetez un oeil à la liste à la fin de cet article, vous trouverez plus de trucs, de documents à lire.
Beaucoup d'utilisateurs se connectent à l'Internet au travers de liaisons modem lentes. Une vitesse de 14,400 bps à 28,800 bps est l'état de l'art pour les "sites privés". En Europe, les systèmes ISDN croissent, mais une vitesse de 64,000 bps n'est pas plus rapide, en comparaison - faisons simple - avec une liaison Ethernet a 10,000,000 bps. Et une liaison Ethernet 10 Mbps n'est pas réellement une connexion LAN très rapide de nos jours.
Ayant réalisé que beaucoup d'utilisateurs n'ont pas cet accès rapide au réseau, vous devez garder en mémoire de conserver la relation information/octets. Optimisez la à 1:1 si vous le pouvez. Vous pouvez utiliser des images dans vos pages web pour suivre la tendance multimedia, mais souvenez vous toujours des buts de votre page et des images que vous allez inclure. Si la plupart de vos utilisateurs utilisent une connexion modem à faible débit, et que les images servent uniquement un but esthétique, ou tout autre effet prévu pour accrocher l'oeil, vous feriez mieux de les bannir de vos pages, ou - au moins - de leur faire utiliser les meilleures techniques de compression et la taille de fichiers la plus minime. Vos utilisateurs apprécieront.
Rappelez vous toujours, personne n'apprécie réellement quelque chose d'accrocheur si cela arrive 3 à 5 minutes après le texte.
Sur un serveur web, il y a au moins une tâche tournant sur le serveur. Si cette tâche lit une requête d'un client http, il se duplique (sous Linux cela s'appelle du "forking") et la nouvelle copie sert la requête, tandis que l'original attend de nouvelles requêtes. Après avoir servi la requête, la copie s'arrête. (En fait, quelques serveurs - comme Apache - conservent toujours par défaut 5 copies du serveur en attente pour répondre à des requêtes parallèles, pour une réponse accélérée.)
Quelques browsers web comme la série des Netscape Navigator effectuent plusieurs requêtes parallèles sur le même serveur, ce qui accroît l'encombrement du serveur causé par un seul utilisateur. Ces browsers récupèrent la page HTML et l'interprètent au fur et à mesure de son chargement, et envoient de nouvelles requêtes pour d'autres informations comme les images, les applets, les sons et toutes autres données encodées en MIME. Par opposition, les browsers "simples" demandent et récupèrent chaque fichier l'un après l'autre, ce qui laisse l'encombrement du serveur par utilisateur le plus petit possible.
La plupart des utilisateurs préfèrent les browsers qui utilisent la technique des requêtes simultanées, comme Netscape Navigator, car ils obtiennent un aperçu plus complet des pages demandées que ne le fait un browser effectuant des requêtes simples.
C'est mon opinion car la plupart des créateurs de pages préfèrent placer leurs informations dans les images, dénigrant les browsers en mode texte.
Ainsi, nous - en tant qu'administrateurs du système - avons le problème, que la plupart des utilisateurs placent plusieurs requêtes simultanées sur le serveur en récupérant la même page. Nous pouvons limiter cela en indiquant au serveur de ne pas répondre à plus de "x" requètes provenant du même serveur en même temps. Mais comment avoir ce "x" ? Il n'est pas facile à calculer et beaucoup d'expérience personnelle sur votre site est nécessaire pour le déterminer. Mais je vais vous donner quelques trucs. Nous avons notre bande passante, la mémoire du serveur, quelques idées sur les performances cpu/disk de nos serveurs et... Bon, ça suffira pour une première évaluation. Vous devrez jeter un coup d'oeil à la place que prend une simple tâche du serveur en mémoire. Voyez ensuite combien peuvent tenir en même temps en mémoire, puis quel pourcentage de vos pages peuvent rester dans votre cache disque. Optimisez le comptage des tâches du serveur contre la taille du cache-disque et vous serez très près de votre "x" personnel. De plus, vous pouvez regarder combien d'autres tâches le serveur effectue: si votre serveur sert aussi de site ftp, vous devrez limiter le nombre de connexions possibles pour laisser un minimum de place au serveur ftp. Si votre serveur web supporte aussi des services de banques de données, vous feriez mieux de conserver quelques cycles cpu et diminuer votre "x". Jouez autour de ces valeurs et testez les. Et (!) lisez le prochain chapitre sur les scripts CGI, qui utilisent également les ressources systèmes et - dépendant des travaux CGI - autant de mémoire.
- A écrire - désolé. Aperçu des avantages/désavantages et astuces: quand utiliser lequel,...
Uh, un thème réellement difficile pour rester sur des phrases courtes. Je n'essaierai pas de mélanger vos géniales idées de design. Pas plus que je ne vais vous indiquer ma stratégie personnelle de design. J'aimerais juste ajouter un ou deux faits sur les idées précédentes concernant l'encombrement du serveur et la bande passante.
De nombreuses recherches sur l'interaction entre l'esprit humain et les interfaces utilisateurs ou les présentations à l'écran ont donné d'intéressants résultats. Il y a quelques faits simples que vous devez garder à l'esprit en concevant des pages WWW.
Saviez vous cela ? Si vous voulez obtenir plus d'informations, cherchez des guides sur les interfaces GUI et les recherches sur l'ergonomie effectuées par les universités et les grandes compagnies (incluant M$).
Hmm, il y en a quelques uns. En fait, il semblerait qu'il y en ait beaucoup. Mais comme j'ai déjà fait mon choix, je ne les ai pas tous testés. Mais je suis vraiment curieux de lire les rapports que vous pourriez m'envoyer.
vi et vim sont parfaitement utilisables comme éditeurs HTML... (pas de flame !) car le HTML utilise seulement des caractères ASCII. Je ne désire pas donner matière pour une autre guerre entre éditeurs. Ceux qui connaissent vi/vim et l'utilisent tous les jours peuvent également l'utiliser pour écrire du code HTML. Vous pouvez rendre vi/vim adaptés au développement HTML en écrivant quelques macros. Mais ceci n'est pas le VI-HOWTO, je laisse ceci de côté. Prenez le comme il vient, qu'il est possible d'utiliser vi/vim comme éditeur HTML (au moins pour quelques changements peu importants). Si vous savez déjà programmer vi/vim, vous saurez certainement comment écrire du HTML. Si vous ne le savez pas, ne vous inquiétez pas.
- A écrire - Désolé.
- A écrire - Désolé.
Ah, il y a quelques références pour un package nommé phoenix, basé sur tkWWW, mais je n'ai pas réussi à le faire tourner sur ma machine. Je pense que c'était un problème dû à ma version de tcl/tk mais on ne sait jamais. Je n'ai pas passé beaucoup de temps sur eux, ils tourneront donc peut être tous deux sur votre système. Utilisez juste archie. Vous pouvez m'envoyer un mail si votre tentative est couronnée de succès.
Si vous ne voyez pas votre éditeur HTML favori ici, envoyez moi juste un mail. Peut être ajouterai-je quelques pointeurs sur des pages web sur des éditeurs HTML pour Linux. Envoyez moi juste quelques sympathiques URL.
Pensées, Idées, Astuces ? Eh bien, vous pouvez visiter le newsgroup comp.graphics . Vous pouvez également aller voir http://www.w3.org/pub/WWW/Graphics/ .
GIF (Graphics Interchange Format) a été introduit en 1987 par Compuserve, Inc, et a subi une révision en 1989. Il utilise l'algorithme LZ, qui sous-entend une patente, ou un copyright US. Il existe donc quelques problèmes légaux sur l'utilisation de ce format graphique sur l'Internet - en dépit du fait que quasiment personne ne le sait.
GIF est un bon format pour les petites images avec des images structurées d'une maniere simple, comme les images générées par ordinateurs ou les bannières.
GIF a quelques avantages comme étant l'un des (sinon le) format graphique le plus largement répandu dans les systèmes en ligne:
Les désavantages sont:
Le Joint Graphic Experts Group (JPEG) a réalisé le format graphique jpeg/jpg/jiff. Ce format est basé sur une transformation cosinusoïdale discrète (DCT) et une compression encodée Huffmann. JPEG travaille avec une perte significative d'informations, ce qui peut rendre vos images quelque peu moins colorées ou moins nettes. Le facteur de compression typique va de 1:5 a 1:50. (En dessous de 1:10, nul n'est capable de voir la différence entre l'original et la copie, en dehors des temps de compression/decompression).
Le JPEG est un bon format pour les photographies, les grosses images et les images très complexes.
Les avantages du JPEG sont:
Les désavantages du JPEG sont:
le format graphique pour les réseaux ( Portable Network Graphics (PNG) ) est le nouveau format sur le réseau. PNG est favorisé par le consortium W3. Pour des informations plus spécifiques, voyez http://www.w3.org/pub/WWW/TR/WD-png.html et http://www.w3.org/pub/WWW/Graphics/PNG/Overview.html . Vous y trouverez les spécifications techniques, des informations sur la programmation, ... PNG est le format de remplacement idéal pour GIF. La page de référence PNG est à http://quest.jpl.nasa.gov/PNG/ . Pour les utilisateurs, PNG aura des avantages et des désavantages, que voici:
Pour les avantages:
Pour les désavantages:
PNG est pour l'instant supporté sous Linux par les programmes suivants: ImageMagick (Version >=3.7), GhostScript 4.0, Gimp, PovRay 3.0, le package netpbm. Pour xv 3.10a il existe un patch non officiel.
- A écrire - désolé. netpbm, xv, ghostscript, gimp, ImageMagick, CorelDraw auf Wine :-)))
Il y a maintenant de nombreux ajouts au-delà du couple HTML-Images. Il y a les applets écrites en Java et les pages JavaScript, ainsi que de nombreuses autres choses.
Il n'y a rien à ajouter à propos de Java en général, lisez simplement la section java dans le chapitre Netscape Navigator de ce HOWTO et le survol sur l'interrogation Applett Java contre scripts CGI. Ensuite, vous pouvez également lire le très bon et compact JAVA HOWTO. Pour la programmation en Java, référez vous aux livres sur le sujet.
Au moment où j'écris ces lignes, ActiveX est encore un enfant de Micro$oft. Micro$oft affirme qu'ils le mettront dans le domaine public ou au moins le donneront a un consortium ActiveX.
ActiveX n'a rien en commun avec le système X Window ni avec XFree.
Il descend du système Micro$oft et IBM OLE. Après avoir sorti les spécifications, il devrait y avoir un portage sous Unix. Mais nous avons le temps d'ici là. Rien pour Linux, encore.
Chapitre suivant, Chapitre Précédent
Table des matières de ce chapitre, Table des matières générale
Début du document, Début de ce chapitre