Rechargement partiel d'une page.

a écrit :
Est-ce que SIFR ou un autre des scripts que tu utilises ne serait pas responsable de ces lenteurs ?

Tu veux dire l'exécution du script chez le client ?

a écrit :
À toi de déterminer tes priorités (personnellement, je verrais bien du texte HTML simple en Georgia ou à la rigueur en Times pour les textes que tu styles avec SIFR en utilisant une police cursive ouvragée mais difficilement lisible)

Malheureusement on m'a imposé cette police... J'avais le choix entre sifr et des images. Je me suis dit : les script, on les charge une fois, tandis que les images c'est pour chaque page différent. De plus je trouve la technique sifr plus accessible car elle conserve les textes dans des balises h2. Mais peut être que mon choix est à reconsidérer ?

a écrit :
En passant (et on s'éloigne du sujet) : tu as un problème avec ton image d'en-tête. Le fond en arc de cercle devrait être une image de fond (attribuée à body, et centrée), tandis que tu peux ne conserver que la partie logo+texte comme image de contenu.

Et que penses-tu de mettre une image de fond ainsi qu'un titre h1 caché reprenant le texte de l'image. C'est plus simple à réaliser et même plus accessible, non ?
Modifié par mathmax (05 Mar 2007 - 18:56)

mathmax a écrit :
Tu veux dire l'exécution du script chez le client ?

Le script ne s'exécute pas ailleurs.
Tu utilises plusieurs scripts. Fais des tests en les désactivant un par un, pour voir si l'un d'entre eux en particulier est responsable du léger manque de réactivité de l'affichage de tes pages avec certains navigateurs.

mathmax a écrit :
Malheureusement on m'a imposé cette police... J'avais le choix entre sifr et des images. Je me suis dit : les script, on les charge une fois, tandis que les images c'est pour chaque page différent. De plus je trouve la technique sifr plus accessible car elle conserve les textes dans des balises h2. Mais peut être que mon choix est à reconsidérer ?

Si le texte à afficher est fixe et ne sera pas changé ultérieurement par un simple rédacteur (via une interface d'administration), une image ira très bien. Il suffira de bien renseigner l'attribut alt de l'image.

<h2><img src="montitre.png" alt="Mon titre" /></h2>

mathmax a écrit :
Et que penses-tu de mettre une image de fond ainsi qu'un titre h1 caché reprenant le texte de l'image ?

J'en pense que c'est une fausse bonne idée. Si les images sont désactivées ou ont du mal à se charger, le texte reste caché, mais l'image n'est plus là pour transmettre l'information. Pour un contenu « enrichi graphiquement » (typographie, logo), il n'y a pas plus accessible qu'une image de contenu avec alternative textuelle pertinente.

mathmax a écrit :
C'est plus simple à réaliser

Hum... pas tant que ça, je trouve.
C'est équivalent niveau CSS (ni plus simple ni plus compliqué), et peut-être un peu plus simple à gérer car on n'a qu'une image au lieu de deux. Par contre, avoir deux images, l'une détaillée (image de contenu qui porte l'information) et l'autre très géométrique (fond en arc de cercle), ça permet d'optimiser le poids des images en utilisant le format ou le type de compression qui va bien pour chaque élément.
Modifié par Florent V. (05 Mar 2007 - 22:08)

a écrit :

Le script ne s'exécute pas ailleurs. cligne

Ah bon ?? Non c'est que je suis étonné que l'exécution d'un script puisse ralentir le chargement de la page. Et si c'est le cas, alors je comprends pas la logique... Les scripts interagissent avec le DOM donc si tout n'est pas chargé quand le script s'exécute ça risque de créer des petits problèmes... Je pensais alors plutôt au chargement des scripts (C'est vrai qu'ils sont lourds avec sifr). Mais ce qui est étonnant c'est que les javascripts ne sont pas chargé à chaque changement de page. Il reste en cache du navigateur... donc je comprends pas .

mathmax a écrit :
Mais ce qui est étonnant c'est que les javascripts ne sont pas chargé à chaque changement de page.

Tes scripts sont exécutés à chaque changement de page. Et l'exécution d'un script, ça peut demander des ressources système (surtout si le script est mal écrit ou bien si ça utilise une fonction très mal optimisée dans tel ou tel navigateur), et ralentir l'affichage d'une page.

Je pense qu'aujourd'hui le chargement de ton code javascript n'est vraiment pas un probléme avec les connections ADSL, à moins que ton fichier possède 10 000 lignes... Ce qui m'etonnerait fortement pour un changement de page.
Le faite que tu vois vraiment la différence, lorsque tu changes de page au niveau de ton header est du a son poids... Une image plus légére serait afficher beaucoup plus rapidement, et l'on ne verrait pratiquement pas de différence.

Mais si ton problème est au niveau de l'accéssibilité web (entre autres, pas de javascript dans la page), il vaudrait mieux que tu utilises une structure basée sur des include, en php ou asp peut importe, comme on te la deja conseillé avant moi
Et puis tu peux éxécuter les traitements de ta page après l'affichage du header, ce qui permettrait au header d'etre le premier traitement effectué et donc affiché encore plus rapidement.

Il vaut mieux oublier les frame, parce qu'en matière de référencement, la page contenu dans la frame n'ai absolument pas référencé...
Ce qui est une grave erreur pour un developpeur, car avant que le client navigue sur ton site, il faut tout d'abord qu'il le trouve

Résultat : Pas de javascript, une interface intégralement xhtml/css, donc accessible avec un header plus léger traité en premier dans le chargement de la page et vous voila combler !
Modifié par mikl194 (11 Mar 2007 - 01:37)

Bonjour,

mikl194 a écrit :
J
Mais si ton problème est au niveau de l'accéssibilité web (entre autres, pas de javascript dans la page)

Peut-on éviter les légendes urbaines ?

Merci.

Il est peut-être temps d'arrêter le massacre ?

Hors page en frameset ou AJAX, le "temps mort" entre affichages de pages Web successives, dans un navogateur graphique, est parfaitement normal, et surtout imprévisible.

Le poids du traitement javascript y aura évidement son rôle, mais aussi le poids, le contenu et la structure du document HTML lui-même, la qualité de la connexion, la gestion des éléments en cache par le navigateur, différents choix d'implémentations au sein du navigateur, la capacité de traitement du client au moment de l'affichage de chaque page, la capacité de réponse du serveur, etc.

Vouloir éviter ce comportement est inutile et illusoire.

Laurent Denis a écrit :
le "temps mort" entre affichages de pages Web successives, dans un navogateur graphique, est parfaitement normal, et surtout imprévisible.

Et en plus pas du tout gênant pour le visiteur. Dans le cas du site de mathmax c'est évident, lui il se prend la tête mais moi visiteur lambda pas du tout