Bonjour,

J'écris ce message pour vous informer d'un tutorial que j'ai écrit ce matin : http://www.web2master.fr/?p=optimisation

Il permet d'alléger considérablement les pages PHP qui contiennent un grand nombre de répétitions d'un même modèle HTML, par exemple une liste de commentaires sur un blog. Le principe est d'appliquer le modèle HTML du côté JavaScript et non du côté PHP. Une solution pour les visiteurs n'ayant pas JavaScript est également présentée

Bonne journée !

Bonjour,

Sympa ce tutorial

Le chargement des pages change-t'il réellement ?
Le temps que PHP récupère les données et les affiches prend-t'il moins de temps que de récupérer les données, les envoyer à Javascript et ensuite Javascript les affiches ?

Y'a-t'il eu des calculs de durée de chargement fait ?

Le risque avec ce type d'application est que si un visiteurs n'a pas Javascript activé, le site n'est pas consultable.

Cordialement,
Mikiman

Au niveau du temps de chargement des pages, le changement ne devrait être perceptible que dans les cas extrêmes : l'intérêt principal est de diminuer la taille des pages et donc d'économiser de la bande passante.

Vue la rudimentarité du code JavaScript, le temps de calcul côté client est très peu augmenté : le temps que l'on gagne en chargement compense largement cette petite dépense en calcul !

Par rapport aux utilisateurs n'ayant pas JavaScript, il y a tout un paragraphe destiné à leur permettre d'accéder tout de même à l'ancienne version de la page : il n'y a donc aucun problème !

Je suis tout de même très dubitatif quant à l'utilité du script : même avec une connexion 56k, télécharger une page bien optimisée, qu'il y ait 3 ou 30 répétitions d'un même bloc, ne change pas grand chose. La plupart du temps, le billet est lui-même plus lourd que les commentaires (et si ledit billet contient des images, l'argument d'optimisation du poids n'a plus lieu d'être).

Mais ce qui me dérange le plus, c'est qu'il faille utiliser deux pages pour un même contenu (avec et sans javascript).
D'une part, il faut créer (et maintenir) ces deux pages, ce qui est tout de même contraignant (et il te faut un système un peu plus complexe en JavaScript pour modifier les urls "à la volée").
D'autre part, si les moteurs de recherche, en crawlant un tel site, n'indexent que les pages non optimisées, tes utilisateurs, eux, feront des liens vers les pages optimisées. Pages qui seront crawlées à leur tour par les moteurs de recherche, aboutissant à un risque de duplicate content.

Pour finir et pour info : le lien que tu nous donnes redirige vers une seconde page, qui elle ne sera pas accessible sans javascript activé. Pourquoi avoir ces deux urls qui mènent au même contenu ? Quelle est l'utilité de la seconde (c'est elle qui sera copiée/collée par tes utilisateurs) ?

Faut accepter les leçons dans la vie, j'ai donc supprimé mon tutorial

Je n'avais pas pensé à tes arguments par rapport au référencement, et il est vrai que l'on peut presque toujours avoir les avantages de ces optimisations sans les inconvénients grâce aux CSS... Où avais-je la tête ?

Par rapport au lien que j'ai donné qui redirige vers un deuxième, en voici la raison : mon site est accessible avec ou sans AJAX (il me sert principalement de démonstration technologique même s'il n'y a pas grand chose à voir). La redirection vers "#p=optimisation" a pour but de renvoyer l'utilisateur sur la page d'accueil puis de charger la page via AJAX : s'il n'y avait pas cette redirection, on se retrouverait avec des liens du genre "?p=home#p=optimisation" qui perdraient tout leur sens... Bien sûr, cette solution est particulièrement maladroite, reste que c'est la seule que j'ai trouvé pour m'occuper proprement des utilisateurs ayant JavaScript sans gêner les autres

Bonjour,

Tout d'abord, merci pour ce tutorial
Je suis d'accord avec captain_flame, j'ajouterai encore un point, l'utilisation de la méthode document.write n'est plus possible lorsqu'un document est servi aux visiteurs en tant que fichier de type MIME application/xml (ou text/xml), ce qui est à terme le but, avec par exemple XHTML.
Donc dans ce cadre ton script ne fonctionnera pas, je précise qu'en servant les fichiers XHTML avec le type MIME application/xhtml+xml (ou pire, text/html) le script fonctionnera car le document héritera de la méthode qui est normalement destinée aux fichier HTML.
Au niveau de l'évolutivité du système cela pose tout de même un sérieux problème.

Au delà de ça, la bande passante est de moins en moins un problème (certains pays, dont le mien, prévoient même d'ajouter l'accès à Internet dit "haut débit" au service universel, c'est-à-dire faisant partie du raccordement de base assuré à chaque abonné) et je suis d'accord ce n'est pas une raison pour la "gaspiller", simplement l'économiser en exploitant temps du processeur pour ce faire ne me semble pas très respectueux des visiteurs (le choix se discuter, utiliser plus la bande passante ou le CPU, à mon avis il n'y a pas de préférence à l'un ou à l'autre de nos jours). Surtout quand l'économie reste minime somme toutes.

Pour ce qui est du chargement de l'article via AJAX, mis à part l'aspect technologique, je n'y vois que des inconvénients.
En effet, il me semble que le contenu de la page d'accueil est tout de même chargé lors de l'appel à une page, contenu qui sera remplacé par le contenu final.
Le rendu est agréable quand on passe d'une page à une autre, mais particulièrement contraignant (également en termes de bande passante, vu que deux contenus sont téléchargés) lors d'un accès direct à une page. De plus, le chargement (avec la barre de chargement) en est beaucoup plus long que la version sans Javascript !
Pour finir, on en revient toujours au même point, avec un énorme risque de duplicate content, toutes les pages étant considérées comme la home (le # indiquant juste une ancre nommée dans la même page) !

c'est vrai que j'ai trouvé le chargement des pages sur le site de zebrian particulièrement long.. il y a bien la barre d'avancement pour faire patienter mais au final, on n'observe pas cela sur un site "classique" en php...