[SRC]/[FAQ] Les templates JS pour accelerer le chargement des pages

**FremyCompany** · 16/12/2006, 18h20

Les templates JS pour accelerer le chargement des pages
Equivalent des header/footer PHP qui a l'avantage de ne devoir être télécharché qu'une fois par le client : pages plus légères !

Attention, si vous mettez du contenu non static (PHP, ...) dans vous templates, vous ne gagnez rien !

HEADER.html :

Code html :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
    <title>Titre par defaut</title>
</head>
<body>
Ceci est le debut commun a toutes les pages<br />

Default.aspx :

Code asp :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
<%@ Page Language="VB" AutoEventWireup="false" CodeFile="Default.aspx.vb" Inherits="_Default" %>
<script src="System.js" type="text/javascript"></script>
<script>document.write(getFileContent("HEADER.htm"))</script>
Contenu dynamique : <%  Response.Write(New Random().NextDouble())%>
<script>document.write(getFileContent("FOOTER.htm"))</script>

FOOTER.htm :

Code html :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
<br />Ceci est la fin commune a toutes les pages
</body>
</html>

HTML recomposé (IE) :

Code html :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
<HTML><HEAD><TITLE>Titre par defaut</TITLE>
<SCRIPT src="System.js" type=text/javascript></SCRIPT>
 
<SCRIPT>document.write(getFileContent("HEADER.htm"))</SCRIPT>
</HEAD>
<BODY>Ceci est le debut commun a toutes les pages<BR>Contenu dynamique : 0,47513719996211
<SCRIPT>document.write(getFileContent("FOOTER.htm"))</SCRIPT>
 <BR>Ceci est la fin commune a toutes les pages </BODY></HTML>

HTML recomposé (FF) :

Code html :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
<html xmlns="http://www.w3.org/1999/xhtml"><head>
<script src="System.js" type="text/javascript"></script>
<script>document.write(getFileContent("HEADER.htm"))</script><title>Titre par defaut</title></head><body>
Ceci est le debut commun a toutes les pages<br>
Contenu dynamique : 0,631264306433156
<script>document.write(getFileContent("FOOTER.htm"))</script><br>Ceci est la fin commune a toutes les pages
 
</body></html>

Ce code fonctionne avec opéra, mais je ne sais pas jusqu'à quelle mesure, vu que je ne sais pas comment voir le code source généré sour Opéra.

Je sais que ce genre de code est très controversé (non respect des normes W3C), et j'en conviens. C'est pour cela que j'ouvre un sondage

**FMaz** · 17/12/2006, 19h28

#1:
getFileContent, ca viend de ou ? system.js ?
Et il y a quoi dans system.js ?

#2:
Cette entête:
<%@ Page Language="VB" AutoEventWireup="false" CodeFile="Default.aspx.vb" Inherits="_Default" %>
Si, par exemple, je travail en PHP (donc pas en ASP), et que je ne la met pas, ton système fonctionne encore ?

**FremyCompany** · 17/12/2006, 19h35

getFileContent vient bien de System.js (voir mon post sur "La gestion de la POO en javascript")

Mais le code utilisé dans System.js provient à la base d'un code plus ancien
(http://www.developpez.net/forums/sho...9&postcount=18)

--- --- --- --- ---
L'HEADER ASP .Net n'a aucun effet.
Il peut être supprimé sans danger.

**FMaz** · 17/12/2006, 19h37

De plus en plus intéressant,

mais pourquoi alors est-ce que ca pose un problème de respect des normes ?

**FremyCompany** · 17/12/2006, 19h47

Envoyé par FMaz

De plus en plus intéressant,

mais pourquoi alors est-ce que ca pose un problème de respect des normes ?

Pas de balise HTML, pas de balise HEAD, le document HTML commence par un <script> ce qui est illégal...

Si on veut respecter le W3C, il faudrait faire un code comme :

Code HTML :

Sélectionner tout - Visualiser dans une fenêtre à part

<HTML><HEAD><SCRIPT>...</SCRIPT><HEAD><BODY><SCRIPT>...</SCRIPT>Contenu du milieu de page<SCRIPT>...</SCRIPT></BODY></HTML>

Ce qui fait perdre une partie de l'intérêt au script...

**FMaz** · 17/12/2006, 19h50

Si ce n'est que ca, je vois pas ou est le problème... !

Je vois pas ou est l'intérêt d'implanter un tel système si la seule entête que nous ayons fait 12 octets... On intègre un tel système lorsque le gain est significatif il me semble. (Donc du contenu, et pas que : <HMTL><HEAD><TITLE>Ma page</TITLE></HEAD> ... )

**FremyCompany** · 17/12/2006, 19h54

Envoyé par FMaz

Si ce n'est que ca, je vois pas ou est le problème... !

Je vois pas ou est l'intérêt d'implanter un tel système si la seule entête que nous ayons fait 12 octets... On intègre un tel système lorsque le gain est significatif il me semble. (Donc du contenu, et pas que : <HMTL><HEAD><TITLE>Ma page</TITLE></HEAD> ... )

C'est aussi ce que je pense.
Mais il y a des "fans" du W3C qui trouvent ca mal...

**FMaz** · 17/12/2006, 20h00

Généralement ces fans ont justement un site pour expliquer le W3C, ils sont tellement anti-table-layout que leur site est laid, sans estétisme, fait en 3 zones maximum (header, menu, content) et est strictement informatif.

Mais pour les vrai site (comprendre par là n'importe quoi de plus complexe), les normes sont parfois trop limitative pour être suivit 100% à la lettre. Donc si c'est pas "deprecated" pas le W3C, si c'est compatible avec tout les navigateurs, si ca n'est pas une aberation majeure ou un illogisme total, c'est bon après tout.

Faut arrêter de vivre dans les livres théorique et analyser un peu plus les besoins pratique réel.

**dingoth** · 20/12/2006, 20h58

Personnellement, je suis contre et complètement contre.

Le principal inconvénient que j'y vois est que ce n'est pas un standard. Et cet inconvénient en regroupe d'autres.

Un site quel qu'il soit est là pour faire partager des choses avec la communauté (le fameux concept web2.0). Or, avec ce système, les utilisateurs risquent de passer à côté de ce que vous avez à partager. Vous partagez non seulement vos informations, vos vidéos, vos ... mais également les petits textes qui font que ce site est intéressant.

Que mettez-vous dans les parties communes de votre site ? Votre navigation générale, vos moyens de contact, le nom de votre site, ... Or avec ce système (néanmoins intéressant), plusieurs types de navigateurs passent à côté de ce contenu qui peut l'aider. Je pense notamment aux navigateurs pour personnes handicapées (aveugles, sourds dans une autre mesure, ...), aux navigateurs de type texte (peu utilisés, mais bon) et bien entendu aux robots. En effet, ces petites bébêtes qui fourmillent vos pages, qui depuis deux ou trois ans n'en ont que faire du Javascript trop présent, et qui prennent le contenu pour vous attribuer un meilleur page-rank (ou thrust-rank ou autre)... eh bien ces petites bébêtes ne verront pas la structure de votre site et seront bien en peine de faire des liaisons entre vos pages. Si bien que certaines de ces pages seront inaccessibles car non référencées dans vos sites. Quel titre mettront-elles à vos pages ? Aucun. Ces navigateurs font-ils partie de ce que vous appelez "tout les navigateurs" ?

Depuis quelques années pulullent des scripts utilisant le fameux système AJAX. Il remplit déjà bien son rôle en allégeant la transmission de données. Votre idée en tant qu'application n'est pas mauvaise, mais apporte-t-elle tellement pour le risque de ne pas être compris ? Je ne pense pas.

FMaz, je vous conseille d'aller faire un tour du côté d'un certain jardin Zen pour que vous puissiez comprendre que la technologie existe pour faire de splendides mises en pages, mais qu'elle est trop peu mise en pratique. Plus par manque de connaissances et de pratique de la part du développeur qu'autre chose.

**FremyCompany** · 20/12/2006, 22h07

Envoyé par dingoth

Personnellement, je suis contre et complètement contre.

Le principal inconvénient que j'y vois est que ce n'est pas un standard. Et cet inconvénient en regroupe d'autres.

Un site quel qu'il soit est là pour faire partager des choses avec la communauté (le fameux concept web2.0). Or, avec ce système, les utilisateurs risquent de passer à côté de ce que vous avez à partager. Vous partagez non seulement vos informations, vos vidéos, vos ... mais également les petits textes qui font que ce site est intéressant.

Que mettez-vous dans les parties communes de votre site ? Votre navigation générale, vos moyens de contact, le nom de votre site, ... Or avec ce système (néanmoins intéressant), plusieurs types de navigateurs passent à côté de ce contenu qui peut l'aider. Je pense notamment aux navigateurs pour personnes handicapées (aveugles, sourds dans une autre mesure, ...), aux navigateurs de type texte (peu utilisés, mais bon) et bien entendu aux robots. En effet, ces petites bébêtes qui fourmillent vos pages, qui depuis deux ou trois ans n'en ont que faire du Javascript trop présent, et qui prennent le contenu pour vous attribuer un meilleur page-rank (ou thrust-rank ou autre)... eh bien ces petites bébêtes ne verront pas la structure de votre site et seront bien en peine de faire des liaisons entre vos pages. Si bien que certaines de ces pages seront inaccessibles car non référencées dans vos sites. Quel titre mettront-elles à vos pages ? Aucun. Ces navigateurs font-ils partie de ce que vous appelez "tout les navigateurs" ?

Depuis quelques années pulullent des scripts utilisant le fameux système AJAX. Il remplit déjà bien son rôle en allégeant la transmission de données. Votre idée en tant qu'application n'est pas mauvaise, mais apporte-t-elle tellement pour le risque de ne pas être compris ? Je ne pense pas.

FMaz, je vous conseille d'aller faire un tour du côté d'un certain jardin Zen pour que vous puissiez comprendre que la technologie existe pour faire de splendides mises en pages, mais qu'elle est trop peu mise en pratique. Plus par manque de connaissances et de pratique de la part du développeur qu'autre chose.

Navigateurs texte : pas utilisé du tout
Mon code est compatible IE, FF, Opéra et KHTML... Tu connais d'autres navigateurs ?

Ces pages restent accessible au robots ! Tous le contenu est présenté !

AJAX : c'est exactement le principe que j'utilise dans ce code

Juste que le code que tu vois ne te permet pas de le voir

**dingoth** · 20/12/2006, 22h53

En ce qui me concerne, j'utilise énormément lynx, un navigateur texte. Pour la simple raison que je suis administrateur système à mi-temps et que je travaille énormément via une console SSH. Le moyen le plus rapide pour accéder à une information revient alors à utiliser le navigateur disponible, Lynx. Mais bon, il n'est pas du tout utilisé, apparemment. Je dois me tromper et utiliser une version trafiquée de Firefox

Le code est effectivement compatible IE, Opéra, etc. Mais avec d'autres également ? Prenons par exemple ... Netscape 4. Quelle hérésie, ce navigateur est complètement dépassé, a bientôt dix ans ... Et pourtant, dans les entreprises qui utilisent encore Windows NT (qui ne sont donc pas passées à Windows 2000), ce navigateur est très présent et est la seule alternative à IE4 (ou 5 pour les entreprises les plus avancées qui ont toujours du NT). Et ces entreprises sont relativement nombreuses. Lorsqu'un UserAgent renseigne Mozilla, cela ne signifie pas qu'il a la dernière version du navigateur Firefox. Il faut faire attention aux chiffres que l'on donne.
Toutefois, j'accorde que selon des estimations, Netscape se situe très bas dans les rapports de force. Mais tous les navigateurs bien commencé avec des pourcentages très faibles, même Internet Explorer

En outre, des frameworks java commencent à se développer pour offrir une alternative aux navigateurs et pouvoir afficher de belles pages dans leur application. JavaScript, même si cela peut paraître paradoxal, n'est que très rarement implanté. Je vous invite tous deux à lire la liste des navigateurs qui sont recensés sur l'encyclopédie Wikipédia francophone.

Quant au contenu, il est effectivement butiné par les robots. Mais les information sur la page, sur le site le sont-elles aussi ? Non, puisqu'elles ne sont pas fournies dans le code de la page, mais dans une page annexe chargeable uniquement avec du JavaScript. La notion de contexte qu'utilisent parfois les robots disparaît alors. Et un robot particulier, et non des moindres, utilise énormément ces tags méta : Google.

Quant à AJAX, l'utilisation qui en est faite ici, en enlevant toute l'accessibilité de la page est (même si le code est bien fichu et pensé) déplorable. C'est l'AJAX poussé à l'extrême : plus rien sur la page, tout dans l'AJAX. L'utilisateur a beaucoup à y perdre et si peu à gagner. Quand j'ai dit qu'AJAX représentait une bonne alternative, je le pensais dans une utilisation normale. Là, je crois que la limite raisonnable en terme d'accessibilité est dépassée. Le mieux est l'ennemi du bien.

Non, ce code, aussi bien pensé et construit, peut être montré comme exemple sur un site de développement ou de recherche JavaScript, mais dans un forum d'entraide où les attentes des utilisateurs sont si variées et peu souvent communes, je déconseille franchement de mettre ce code dans une FAQ. Les standards sont déjà assez malmenés pour qu'on les coupe de cette manière.

En gros, je ne suis pas contre ce script, mais contre la mise en avant de celui-ci.

**FMaz** · 22/12/2006, 04h41

Et tu pense représenter quel % des utilisateurs dans le monde ?

Quel genre de site va tu visiter ? Tu va jouer à des jeux flash ? Tu va sur Gmail ? je crois que tu ne va que lire de la documentation technique et d/l des MAJS en tout genre.

Donc n'étend pas trop TON utilisation à tous. Un site est fait en fonction de sa clientelle, tout simplement.

**Taum** · 22/12/2006, 10h40

Généralement ces fans ont justement un site pour expliquer le W3C, ils sont tellement anti-table-layout que leur site est laid, sans estétisme, fait en 3 zones maximum (header, menu, content) et est strictement informatif.

Nous avons un vainqueur

Pour essayer d'être constructif, je suis assez d'accord avec dingoth :
Le principe en lui même d'aller chercher du HTML en Javascript pour l'integrer à une page : ok. Mais bon c'est le principe même d'AJAX (pas strictement parlant vu qu'on utilise pas le XML, blablabla ...)

En revanche l'utilisation que tu en fais ici ne me parait pas très interessante : Quel avantage par rapport à un template côté serveur, qui lui ne sera de toute façon pas dépendant du client, et n'aura par définition aucun problème d'indexation par des robots, etc...
Pour moi le rapport Utilité/Compatibilité n'est pas suffisant pour en faire un script utile en pratique

**dingoth** · 22/12/2006, 11h20

Sincèrement, à quoi sert ce script ?

À deux choses :
- gagner de la bande passante et
- écrire paresseusement du code.

Alors, puisque tout le monde utilise Internet Explorer (dixit FMaz, extrapolé par moi), Windows et a une bande passante 20 giga sans quota (j'extrapole bien, hein

), pourquoi vous, FMaz, auriez-vous besoin de raccourcir la taille de vos pages HTML ? La plupart du temps, tout cela passe déjà de manière compressée par gzip. Davantage si vous utilisez un hébergement mutualisé. Dans ce cas, qui plus est, vous n'avez pas à vous soucier de votre bande passante, ni de la taille de vos pages car à moins d'être très mal conçues, le transfert d'images lourdes non-optimisées et de fichiers divers (vidéo, fichiers compressés, sons) est ce qui mangera le plus dans l'utilisation de votre bande passante. L'utilité de ce script devient donc évidemment nulle.

Pensons maintenant aux personnes qui ont justement peu de bande passante. Vous n'êtes pas sans savoir que depuis les plus vieux navigateurs Netscape 2 et IE2, il me semble, un système d'affichage peut exister malgré que la page soit toujours en train d'être chargée. Imaginons que maintenant, ô idée saugrenue, votre page soit immense (100k) malgré que vous ayiez utilisé ce script, qui au passage vous aura fait économisé maximum 5k. Un utilisateur n'ayant qu'une connexion 56k devra, pour naviguer entre les pages via le menu, attendre le chargement des 100k, puis de l'exécution du script AJAX pour pouvoir enfin accéder au menu tant attendu, au lieu d'interrompre le chargement et de pouvoir naviguer comme il le souhaite. L'utilité de ce script est ici également nulle.

Pour la paresse : tout développeur est paresseux, c'est bien connu, moi le premier. Mais pour une fois, pensons à l'utilisateur car ici, l'utilisation d'AJAX limite clairement l'utilisateur. L'utilisateur pouvant être un robot qui vous fournit un service gratuitement et qui vous permet d'être mieux placé en ce qui concerne les recherches (par exemple Google). Mais si vous ne voulez pas vous trouver dans les moteurs de recherches, il y a de meilleures solutions pour obfusquer votre code et n'être lisible que de la minorité qui est clairement à la pointe de la technologie en matière de navigateurs web. Vous professez pour la liberté de tous, mais n'en faites en réalité que pour la (grande) majorité.

Je vais continuer en vous répondant à vos questions :
- Je vous laisse la liberté de répondre à ma place en ce qui concerne le pourcentage que je représente avec mon utilisation de l'Internet.
- Oui, je vais de temps à autres jouer à des jeux développés en ActionScript.
- à un niveau AJAX, j'utilise même plus que GMail, le webmail de Yahoo! est un outil professionnel ou GMail est un vulgaire applet.
- J'utilise Lynx essentiellement lorsque je travaille sur les machines des autres via la mienne. Pourquoi ? Parce que c'est plus simple à ce moment-là.
J'espère que maintenant, vous pourrez encore mieux me catégoriser. -_-'

Je vous réponds donc : N'étendez pas VOTRE utilisation (de l'internet) à tous. Il existe encore des personnes dans le monde qui n'ont pas accès à des logiciels facilitateurs et ce script n'est pas des plus efficaces en ce sens.

Enfin, et totalement anecdotique, pour rappel des politesses, j'ai commencé par vous vouvoyer, je ne vois pas pourquoi vous me parlez à la seconde personne du singulier.

**FremyCompany** · 22/12/2006, 12h16

Au fait, pour les robots ou ceux qui n'ont pas Javascript activé, j'ai la solution...

Vous savez tous comme moi que PHP gère la fonction include (qui, en fait, fonctionne comme ma fonction JS, mais pour PHP), et bien il faut, en PHP (ou autre langage serveur) faire un test pour voir si JS est activé sur le navigateur client (donc exit robot, ...) :

- si oui, faire le include en JS via ma méthode
- si non, faire le include via PHP/ASP/JSP/ASPX/...

+ Proposer manuellement à l'utlisateur : "Les pages de ce site ne s'affichent pas correctement ? Cliquez ICI" pour aller mettre dans la SESSION (PHP, ...) que l'utilisateur ne veut pas utliiser la méthode JS...

Ainsi, plus de problème

**dingoth** · 22/12/2006, 12h44

Cela ne devient plus un outil purement JS, mais un ensemble avec PHP et donc cela n'aurait que faire dans la section des sources JS.

Qui plus est, le problème du gars avec son modem 56k n'est pas résolu avec cette solution. L'idéal serait de faire l'inverse : proposer la solution lourde par défaut et switcher vers une alternative si le client le souhaite.

**FremyCompany** · 22/12/2006, 14h03

Envoyé par dingoth

Qui plus est, le problème du gars avec son modem 56k n'est pas résolu avec cette solution. L'idéal serait de faire l'inverse : proposer la solution lourde par défaut et switcher vers une alternative si le client le souhaite.

Ca ca n'a aucun sens... Tu crois vraiment que le client va s'amuser à cliquer sur un bouton "faire aller votre connection plus vite" ? Jamais... Tandis que si il a des problèmes d'affichage, alors il aura plus tendance à passer vers un mode "comptabible", si proposé...

**FMaz** · 22/12/2006, 16h01

Un template coté serveur ne permet pas de sauver en bande passante alors qu'un template coté client:oui.

Meme chose pour la rapidité de chargement.

En d'autre mot, c'est d'appliquer le concept de cache des image et des script externes... a du contenu/code HTML

**FremyCompany** · 22/12/2006, 16h48

Envoyé par FMaz

Un template coté serveur ne permet pas de sauver en bande passante alors qu'un template coté client:oui.

Meme chose pour la rapidité de chargement.

En d'autre mot, c'est d'appliquer le concept de cache des image et des script externes... a du contenu/code HTML

Oui, c'est exactement l'idée...

Et avec ma soluce "coté serveur", on peut ne pas fausser le contenur pour les robots et permettre aux gens qui n'ont pas JavaScript activé de tout de même utiliser la page web ! ==> Ce code permet de faire gagner à tous !
1) Le client : moins de données à recevoir : transfert plus rapide : affichage plus rapide
2) Le serveur : moins de contenu à faire passer : moins de bande passante utilisée, vitesse de transfert plus grande, moins vite au bout du quota de transfert (selon hébergeur)
3) Ceux qui ne sont en rien concernés par ce site : si ce code est appliqué à plus ou moins grand échelle : moins de données transitants par internet : internet plus rapide !

**dingoth** · 23/12/2006, 01h17

Autant rester dans l'optique du AJAX pur et dur alors :

Une page HTML chargée la première fois, puis tout le reste est du contenu récupéré par AJAX. Quand on clique un lien, la couche JS l'intercepte, annule le comportement du lien et va chercher les données compressées depuis AJAX. Cela sera bien plus efficace et compatible que votre code. Et de plus, pas besoin d'utiliser de script serveur. Il suffit de faire deux sites : l'un en HTML pour ceux qui ne supportent pas JS et l'autre dont tout est chargé par AJAX. Mais bien entendu, cela demande plus de réflexion de la part du codeur de site.

Le principe de la page déjà préchargée avait déjà fait quelques émules à l'époque, je viens de m'en souvenir. Je vous invite à aller voir. La solution était plus élégante que celle proposée ici, mais était moins portable. Le lien est en anglais, même si les développeurs sont Français, désolé. Vous pouvez cependant lire les commentaires relatifs qui sont en français sur le standblog (oui, un blog de fan du W3C avec 2 menus et du contenu informatif).

Affichage des résultats du sondage: Faut-il autoriser dans la FAQ des codes, comme celui-ci, qui ne respecte pas W3C ?

[SRC]/[FAQ] Les templates JS pour accelerer le chargement des pages

Contribuez

Discussions similaires

Partager

Partager