[17:04:11] --- LOGGING STARTED [17:05:15] salut [17:06:16] ca marche plus :s [17:06:39] si c'est juste que personne ne parle [17:06:50] voilà pour le sujet [17:07:40] Eh bien, on va peut-être tenter de définir le sujet pour ceux qui ne connaissent pas la problématique sur le bout des doigts. [17:08:09] Sondage rapide, qui pense savoir ce que recouvrent les termes «performances client»? [17:08:34] utilisation de javascript entre autres [17:09:06] le nombre de requêtes est important également [17:09:09] définition -> si ça fait ramer le navigateur ? [17:09:34] vitesse et affichage [17:10:06] Ha ha, si ça fait ramer le navigateur (genre consommation CPU qui monte en flèche), il y a effectivement un problème de performances. Cf. Flash sous OS X ou Linux pour une illustration flagrante du problème. XD [17:10:51] exacte, Flash c'est horrible [17:10:52] Mais même sans utiliser excessivement les ressources du poste client (RAM, CPU), on peut avoir des problèmes de performances liés au temps de chargement des pages. [17:10:53] ou simplement Flash sur une vieille machine … [17:11:29] L'aspect principal des performances client pour le Web, c’est «combien de temps mets ma page pour s’afficher?» [17:11:29] oui si les images ne sont pas correctement compressées par exemple [17:11:29] de toute façon troll à part, flash c'est le mal [17:12:04] --- sphax3d vient d'arriver [17:12:07] je suppose que javascript a aussi une grande influence là-dessus ? [17:12:34] enfin de toute façon quoi que tu fasses le web sera toujours plus lent que du compilé, mais le troll bureau vs web c'est pas pour aujourd'hui [17:13:11] L’autre aspect essentiel, c’est la perception de l’utilisateur. Si une page mets plusieurs secondes à se charger complètement (images de contenu qui se chargent progressivement), mais que l’essentiel de la page était en place en 500ms, c'est un résultat qui reste correct. [17:14:24] Donc il ne faut pas se limiter à «en combien de temps (millisecondes, secondes...) ça charge (ou ça réagit)», mais s’occuper avant tout de ce que perçoit (même inconsciemment) l'utilisateur. [17:14:31] J'utilise souvent flash même si c'était à des kilomètres de mes priorités mais bon c'est le client qui veut [17:15:09] ça reste plutôt léger tant qu'on reste dans l'animation [17:15:12] Le but est de fournir un site ou service réactif, car un site perçu comme lent eh bien c'est du chiffre d'affaires en moins. [17:15:18] la vidéo c'est lourd de toute manière [17:15:33] premier facteur que je rencontre souvent, c'est les proxy des entreprises qui blocs les pages, ou garde en cache des images ... mais je suis peut être hors sujet [17:16:05] Florent V., la rapidité du service se joue aussi côté serveur [17:16:07] pablo: quelle genre d'images ? [17:16:16] En clair, pour deux sites comparables, si l'un d'eux n'est pas réactif les utilisateurs risquent de le bouder (avec toutes les réserves possibles vu les autres paramètres qui entrent en jeu, bien sûr… cf. Twitter). [17:16:23] les gros sites qui utilisent des centaines de Ko de javascript c'est aussi n'importe quoi et ça ralentit, jen suis sûr [17:17:11] Changaco: bien sûr, ça se joue aussi côté serveur. Il y a des exemples fameux où, côté serveur, ça coince périodiquement. Je pense notamment à Twitter, ou pour un exemple français à Voyages-SNCF.com. [17:17:41] même de nombreux sites qui utilisent du javascript ou je me demande souvent pourquoi [17:17:42] twitter a parfois du mal à suivre ? [17:17:45] la génération dynamique des pages côté serveur sans système de cache déjà t'es sûr qu'avec 10 connexions simultanées tu es lent [17:17:47] ou orange.fr [17:17:54] pourtant ils ont les serveurs... çA devrait pas [17:18:01] pour répondree à Sphax3d gif png jpg [17:18:04] des tests ont été fait sur ce genre de choses par wordpress je crois [17:18:21] Orange.fr c'est une frame de merde qui fait chier, le header ^^ [17:18:38] c'est une cata ce site ^ [17:18:49] pablo: il y a des techniques côté serveur pour informer le proxy d'un mise à jour de tes images si nécessaire. [17:18:55] c'est le plus gros site en france [17:19:03] Mais on peut réussir son optimisation côté serveur et rater l'optimisation côté client, et là on a perdu une grande partie des bénéfices de l'optimisation côté serveur. De plus, dans de nombreux cas l’optimisation côté serveur n'est pas problématique (soit parce qu'elle est déjà bien gérée, ou parce qu'on est dans un cas de figure où on n'a pas de fortes contraintes de ce côté là), tandis que l'optimisation côté client est tout simplement ignorée. [17:19:48] Pourquoi on l'ingore ? parce qu'on estime que tout ce qui ne se passe pas sur le serveur on s'en fout ? [17:19:57] mouais … personnellement je pense que l'optimisation côté serveur est bien souvent oubliée également … [17:20:11] +1 [17:20:36] pablo: certaines techniques pour l'optimisation client permettent d'éviter les mises en cache abusives de certains proxys. De plus une bonne gestion des en-têtes HTTP permet d'éviter de donner de mauvaises instructions aux clients (proxys et navigateurs) pour la mise en cache. [17:20:42] y a combien de CMS qui font de la génération dynamique sans système de cache ? [17:20:44] suffit de voir la puissance de wordpress face à d'autres cms pour s'en rendre compte [17:20:45] QuentinC: parce que toi tu as une bonne machine et une bonne connexion Internet, et que tu penses pas obligatoirement à ceux qui n'ont pas ça :-) [17:21:23] les plus connus on généralement un système de cache [17:21:30] c'est vague je sais ^^ [17:21:50] non j'ai pas une bonne machine pour le moment... le PC où je suis a 7 ans [17:22:00] QuentinC: on l'ignore souvent parce que ceux qui s'occupent de performances sont des ingénieurs et développeurs qui ne maitrisent pas les langages clients et leurs problématiques. Tandis que les intégrateurs web (quand ils existent, ce qui n'est pas le cas dans tous les projets...) ne sont pas toujours des scientifiques sensibilisés à ces questions. [17:22:00] après faut voir comment est fait ce système de cache aussi … [17:22:06] (il y a peu d'utilisateurs pour un débat Alsacréations :/) [17:22:20] --- pixelslip vient d'arriver [17:22:40] mais le cache reste une optimisation supplèmentaire [17:22:40] Comment est-ce que vous testez l'efficacité d'un site ? YSlow (ext. FF de Yahoo), Page speed, l'« inspecteur » de webkit ? [17:22:45] (sphax3d, on a déjà vu pire …) [17:22:55] le moteur php ou autre doit tourner correctement sans [17:23:20] bzh, le cache c'est pas une optimisation, c'est la base de tout système efficace, c'est ça que certains développeurs ne saisissent pas [17:23:50] en même temps c'est pas toujours simple à implémenter, un système de cache côté serveur [17:23:56] --- pixelslip est parti [17:24:15] au contraire ça peut être très simple mais il faut y penser dès le début [17:24:40] pour un CMS c'est pas trop trop compliqué, mais pour un truc hyper dynamique, genre un gros forum, c'est un vrai casse-tête, d'ailleurs je me demande comment certains font [17:24:58] perso j'ai jamais eu se problème durant la conception de mes sites [17:25:10] QuentinC, le truc c'est que j'estime que les forums n'ont pas leur place sur HTTP … [17:25:29] je n'ai jamais programmé de système de cache parce que je n'en jamais eu besoin, mais le jour où ça serait sûrement un gros problème [17:26:15] pr un CMD c'est pas dur : ob_start, et à la fin ob_get_contents + file_put_contents et hop c'est dans la boîte [17:26:44] mais pour un forum ou ce genre d'appli... [17:26:45] PHP, toujours aussi sale comme langage … [17:26:52] Bon alors pour continuer sur le topo qui va bien: pour les publications et outils sur les performances client, il y a beaucoup de publications du côté de chez Yahoo (Yahoo Developer Network), avec des articles, une série de recommendations et un outil (extension pour Firefox+Firebug) nommée YSlow, qui peut se lire «Why Slow?» pour la petite histoire. En français, le blog d'Eric Daspet sur performance.survol.fr est plus que recommandable. En anglais, il y a les publications de Steve Souders notamment. Enfin, Google a récemment sorti un outil nommé Google Speed, qui est une alternative à YSlow. Les critères de YSlow et de Google Speed ne sont pas les mêmes sur tous les points, et les deux peuvent être utilisés en parallèle. [17:27:51] changacco > pour la saleté de php je t'approuve en partie [17:28:05] tu as pu tester google speed (ou quelqu'un d'autre)? [17:28:10] Il y a aussi un certain nombre d'outils en ligne, et d'outils externes qui analysent le comportement du navigateur. [17:30:23] Personnellement, ce que j'aime bien dans YSlow, c'est qu'il renvoie vers des ressources intéressantes pour expliquer les erreurs / problèmes. [17:30:58] mais vous avez déjà rencontré des problèmes "performances client" [17:31:33] ou c'es moi qui suis à l'ouest [17:31:45] (je ne fais que très peu de web, je n'aime pas particulièrement ça mais j'essaie de m'y intéresser un peu. Quelqu'un aurait une - bonne - doc qui explique comment implémenter un bon système de cache ?) [17:32:17] il y a des tutos qui expliquent la base en la matière sur le site du zéro [17:32:35] Pour ma part je connais assez bien YSlow (mais pas la V2 si elle est déjà sortie), et j'ai essayé Google Page Speed mais très brièvement. J'utilise à l'occasion l'onglet réseau de Firebug pour voir les requêtes HTTP et les temps de réponse, mais il ne m'a pas toujours semblé très fiable (surtout dans les versons beta). LiveHTTPHeaders est intéressant. [17:32:55] j'ai tendance à éviter le sdz :p [17:33:09] ah, pourquoi ? [17:33:24] c'est vrai que côté php il pas si super que ça [17:33:50] enfin surtout les forums [17:34:04] Tutoriel sur la gestion du cache: http://www.mnot.net/cache_docs/ (en anglais, une trad française est disponible mais ne tient pas compte des mises à jour de l'original). [17:34:06] Florent, as-tu essayer « l'inspecteur web » de webkit pour analyser les temps de réponse ? [17:34:19] parce que de ce que j'en ai lu, c'est bien pour commencer mais dès que tu veux faire un truc intéressant ça pousse pas assez loin [17:34:32] merci Florent V. [17:34:33] --- juiced vient d'arriver [17:34:51] Yannick: oui, à l'occasion. Je ne l'ai pas exploré en détail. [17:35:14] --- dede vient d'arriver [17:35:16] merci pour le lien [17:36:39] pablo: ça dépend de ce que tu appelles un problème de performances client. [17:36:44] L'avantage de l'inspecteur web c'est que, outre la présentation agréable, tu vois les différentes requêtes sur une ligne de temps. [17:37:35] En général, on est dans de l'optimisation, et pas dans de la résolution de problème (au sens ou un problème serait quelque chose bloquant le fonctionnement du site, ou provoquant des plaintes d'utilisateurs). [17:37:43] Il te montre à la fois la latence (parle-t-on de latence pour un serveur web) et le temps de téléchargement. [17:38:03] et donc pardon, si je suis hors-sujet arrêtez moi, mais dans le cas d'un forum par exemple, doit-on implémenter un système de cache ou pas ? [17:38:08] Yannick: la dernière version de Firebug fait ça aussi. [17:38:22] perso, enfin je crois, sauf erreur de ma part ne pas avoir fait un site avec un temps de réponse trop long, mise a part avec flash mais je crois qu'il y a des astuces [17:38:32] niluje, pourquoi tu voudrais coder un forum ? [17:38:46] y a déjà tout ce qu'il faut, pas la peine de réinventer la roue [17:38:53] niluje: c'est hors-sujet car tu parles d'un cache pour la génération du code HTML des pages, et c'est une question (importante) d'optimisation serveur. [17:39:10] disons que dans certains cas, un form doit être mis en cache oui, mais je sais pas comment ils font par contre [17:39:33] Ce qu'il faut voir aussi, c'est qu'il y a plusieurs paliers pour «un temps de réponse trop long». [17:39:47] d'accord je m'arrête alors [17:39:50] Le premier palier, c'est 100ms. Pour l'utilisateur, c’est de l'instantanné. [17:39:56] chagacco > je serais intéressé à ce que tu en dises plus quan tu dis qu'il ne faut pas réiventer la roue, peut-être plus tard après 19h [17:40:05] Changaco: je ne veux pas coder un forum, j'essaie juste de me renseigner des bonnes pratiques à faire si je voulais le faire :) [17:40:24] QuentinC, ça marche on parle de ça tout à l'heure [17:40:32] Au temps pour moi, l'onglet Réseau de Firebug donne plus d'infos que l'inspecteur de webkit. [17:40:37] Le deuxième palier, c'est une seconde. C'est une page peu réactive, l'utilisateur perçoit une latence et il sait plus ou moins consciemment qu'à chaque action (clic) il devra attendre un certain temps une réponse. [17:41:07] lol quand je pense que certains sites mettent 5 secondes voire plus à être utilisables avec jaws, 1 seconde ça me fait rire [17:41:49] Le troisième palier, c'est 10 secondes. Là l'utilisateur sait parfaitement qu'il attend, il peut s'agacer et partir (notamment s'il arrive d'une page de résultats sur un moteur de recherche et teste plusieurs liens pour voir si ça correspond à sa requête), voire il peut penser que le site ne marche pas. [17:42:10] Florent, tu parles de latence "page demandée > page chargée" ou "page demandé > page qui commence à apparaître" ? [17:42:13] après faut distinguer si ça vient du site ou du client, parce que la latence des DNS ça influe énormément [17:42:57] les DNS c'est assez rapide normalement quand même [17:43:03] mheuuu latence DNS [17:43:11] euh non [17:43:22] ont est pas sorti d'affaire [17:43:27] ceux des livebox c'est la misère [17:43:33] mais ce qui m'énoerve c'et les sites qui mettent 5, 10 secondes mais à cause de trop de js [17:44:12] en ce qui concerne les DNS j'ai jamais eu de problème, 100-150ms de ping [17:44:20] maximum [17:44:40] exemple: apple.com c'est bourré de js et pourtant [17:44:41] le ping ne te donne pas le temps de réponse d'une requête [17:44:47] Yannick: plutôt «page demandée → page qui commence à apparaitre». Sauf que tout dépend de l'attente de l'utilisateur. S'il charge une page pour voir la cinquième image d'une galerie de photos (en venant de la quatrième par exemple), le critère important pour l'utilisateur ce n'est pas tellement le chargement de l'interface globale, mais plutôt le chargement de l'image qu'il veut visionner. Nuance dans la nuance: si l'interface globale se charge rapidement et le contenu apparait progressivement, l'utilisateur attend mais il sait que sa requête avance; tandis que s'il est devant une page blanche pendant quatre-cinq secondes, il est dans le doute et c'est pas une bonne chose. [17:44:51] je ne voix pas de soucis non plus côté dns [17:44:58] je m'excuse mais je vais m'absenter un moment. A plus tard, je regarderai les log si jamais il est plus de 19h quand je reviens [17:46:07] Changaco: la latence DNS, ça ne joue qu'une fois. Ensuite le navigateur garde en mémoire l'IP correspondante à un domaine/sous-domaine donné. [17:46:31] ça ça dépend du système de cache de l'OS … [17:46:52] Mais si une page référence des contenus sur dix domaines différents, là ça devient problématique (quoique pas autant que le chargement de ces divers contenus). [17:47:05] enfin bref c'est hors-sujet [17:47:12] vous avez un exemple à nous donner maintenant un exemple de site avec une forte latence ^^ [17:47:43] Petite liste (disclaimer: non exhaustive et potentiellement fausse ;)) des obstacles majeurs à un chargement de page réactif: [17:48:09] pablo: Adobe.com. [17:48:41] facebook est lent … [17:49:18] orange.fr [17:49:50] (quoi que ça a l'air moins pire qu'auparavant) [17:50:08] deezer [17:50:20] --- Hatem vient d'arriver [17:50:44] orange est un site très visité ce qui n'arrange pas l'affaire [17:50:52] pareil pour ceux de la sncf [17:52:32] Comment prendre en compte les visiteurs qui utilisent une connexion RTC ? [17:52:38] Donc pour reprendre la liste: [17:53:32] il faut optimiser d'emblé pour les petites connexion [17:53:51] et ne pas charger de truc lourds comme le son et les vidéo [17:55:02] Pour la vidéo il y a une astuce simple mettre une image et si la personne souhaite visionner la vidéo il clique sur image [17:55:03] 1. Les pages qui référencent plein de contenus et widgets (utilisant allègrement des iframes et du JavaScript) de services annexes, hébergés sur domaines tiers. Très courant sur les blogs, ça peut donner des chargements interminables, surtout si l'un ou l'autre de ces services est en rade ou mets du temps à répondre, bloquant (dans certains cas) tout ou partie de l'affichage de la page. [17:55:47] cette page décrit un bonne partie de ce qu'il faut faire ou ne pas faire : http://developer.yahoo.com/performance/rules.html . Même si certains conseil sont à prendre avec des pincettes. [17:56:15] 2. La gestion du cache absente ou ratée. [17:57:26] bzh > C'est vers ces ressources que te renvoie YSlow dans ses "rapport d'analyses". [17:57:59] oui, c'est lié à yahoo slow [17:58:27] 3. Les images mal optimisées (peuvent être dix fois trop lourdes suites à certaines erreurs de débutants… et dans les 15-30% trop lourdes lorsqu'on n'a pas commis d'erreur grossière mais qu'on n'a pas optimisé autant que possible). On notera aussi que certains choix graphiques peuvent peser très lourd, et qu'il convient parfois de faire des compromis entre volonté d'un graphiste et objectifs de performance. [17:59:11] Pour ce troisième point, on notera l'existence d'outils comme pngcrush, parfois intégrés à des applications comme smush.it. [17:59:36] Et bien sûr une bonne connaissance des formats d'images pour le Web est indispensable. [18:00:36] ah point n°3 ^^ [18:01:08] Pour les images en jpeg, notamment, pensez à supprimer les données EXIF/IPTC si vous n'en avez pas besoins (surtout si ces métadonnées contiennent la vignette de l'image). [18:03:05] --- Hatem est parti [18:03:18] perso, je fais enregistrer pour le web avec photoshop et zouuu. Je me prend pas beaucoup la tête sur les images. [18:03:47] 4. Les requêtes HTTP trop nombreuses. Jusqu'à récemment, tous les navigateurs ne pouvaient faire que deux requêtes en parallèles pour un domaine donné. Ce qui signifie que pendant que les 8 scripts JS et 5 fichiers CSS se chargent, il peut se passer bien plus d'une seconde. Les versions les plus récentes des navigateurs (pas majoritaires chez les utilisateurs) montent la limite à 4, 6 ou 8 requêtes simultanées. Ça reste intéressant de diminuer les requêtes en concaténant les fichiers JS et CSS. Au passage on en profitera pour minifier le JS (voire le CSS aussi), et pour utiliser une compression gzip pour limiter drastiquement le poids des fichiers JS et CSS. Pour les images, la technique des sprites CSS permet de limiter le nombre d'images à charger, mais elle a ses limites (notamment face aux contraintes d'accessibilité). [18:03:50] idem [18:04:49] bzh, pablo: vous êtes typiquement dans le cas où vous pouvez gagner 15-30% en moyenne sur le poids des images, en passant par un outil comme smush.it. [18:04:52] Florent V., elle vient d'où cette limite ? [18:05:22] Quel est le problème des sprites css avec l'accessibilité ? [18:05:32] Changaco: euh… je sais pas. Peut-être du fait que les serveurs avaient du mal à répondre à beaucoup de requêtes simultanées pour un même client? [18:05:38] j'ai testé smush bidule à 2 ou 3 reprise, je gagnais entre 4 à 7 % [18:06:00] pablo: tu fais essentiellement du JPEG? [18:06:12] (ou du JPEG + du PNG-8?) [18:06:15] png [18:06:49] jpeg très rarement [18:08:25] je précise que j'intègre mes propres design et qu'ils sont pensés pour être légers [18:08:28] En général sur du PNG-32 (à utiliser rarement) on peut gagner beaucoup avec un fichier sorti de Photoshop ou Gimp. Sur du JPEG ça dépend, c'est surtout si on a oublié de supprimer les EXIF et la vignette, mais il arrive qu'on y gagne quand même. Sur du PNG-8 je gagne en général très peu, avec quelques surprises (fichier réduit à 20-40% de son poids d'origine) lorsque le logiciel d'édition s'est emmêlé les pinceaux et a sorti un fichier étrangement lourd. [18:08:46] smushit me fais gagner qu'un très faible pourcentage, genre 1% [18:09:38] mais pour info j'ai travailler quelque années pour un gros site ou j'ai optimiser les images jpeg et gif sur 1200 images nous avions reduit le poids de 45% et j'ai reçu des reproches (pourquoi perdre son temps sur des détails ...) [18:10:10] :/ [18:10:34] faut quand même compresser un minimum [18:11:53] Yannick: pour être accessibles, toutes les images qui correspondent à des pictogrammes (pas directement accompagnés d'un intitulé texte) ou à un texte ou bouton-texte, doivent être des éléments IMG dans le code HTML, avec un attribut alt correctement renseigné. À l'inverse, les sprites CSS ce sont uniquement des images de fond, donc pas utilisable pour ce genre d'image. Sauf que, la tentation est forte de mettre plein de choses dans une image de sprite, de faire des SPAN avec texte caché remplacé par un background CSS… et ça c'est une technique non accessible. [18:12:25] mais je vais tester smushit [18:13:00] de faire des SPAN avec texte caché remplacé par un background CSS, c'est pas accessible Oo [18:13:04] --- Kadus vient d'arriver [18:13:23] sfir c'est pas accessible ? [18:13:35] salut à tous [18:13:38] les textes caché ne sont jamais accessibles [18:13:41] Le problème des sprites CSS est triple: 1) on est tenté de les utiliser là où il ne faudrait pas, 2) en utilisation correcte pour des background CSS ça a des limites fortes pour des éléments extensibles en hauteur et largeur (risque d'apparition d'autres images du fichier de sprite) et pour les images à répéter en hauteur ou largeur, 3) la maintenance d'une image de sprite est plus compliquée que la maintenance de nombreuses images séparées. [18:13:41] salut [18:14:15] caché alors qu'il ne devraient pas l'être, je précise [18:14:44] pablo: je ne sais pas trop ce que donne SIFR côté accessibilité. Ils ont visé une certaine accessibilité mais leur technique est peut-être inaccessible dans certains cas de figure, ça serait à vérifier. [18:15:24] tu parle de jaws et compagnie ? navigateur [18:15:46] s* [18:16:02] pablo: un texte caché remplacé par un background CSS, ça laisse un espace vide (donc un lien non identifiable ou un contenu invisible) si les CSS sont activés (ça sera le cas la plupart du temps avec un navigateur graphique) mais que l'image ne se charge pas (ça arrive, pour de multiples raisons). [18:18:34] Je reviens sur le problème des gens en RTC. Y a-t-il une technique qui permette de « tester » la vitesse d'une connexion pour servir à une connexion rapide des images de meilleure qualité (en remplaçant les URL avec du javascript par exemple) ? [18:19:04] --- Kadus est parti [18:19:07] Yannick, le meilleur moyen d'être efficace c'est de faire simple [18:20:03] oui mais les clients compliquent tout ^^ [18:20:14] tu ne peux pas tester le débit dont dispose l'utilisateur sans perdre du temps [18:20:32] et remplacer des choses en JavaScript c'est une perte de temps également [18:20:47] Yannick: pas à ma connaissance. [18:22:06] Yannick: par contre il existe des logiciels qui brident ta connexion ADSL (ou autre) à un débit équivalent à du RTC, ce qui te permet de tester ce que ça donne. [18:23:17] Florent, ça ça m'intéresse parce qu'à part utiliser Tor, je ne voyais pas comment. [18:23:23] je n'ai jamais verifié mais une connexion internet reste de toute façon très aléatoire [18:23:37] Une démo de temps de latence: http://galbraiths.org/feedback.html [18:24:03] Où l'on se rend compte qu'une réponse en 200ms, ben ça n'apparait pas comme instantané. ;) [18:24:17] bzh, l'ADSL est aléatoire, pas la fibre [18:24:27] question, si j'applique les bonne methode http://en.opquast.com/ je n'ai plus trop de problème ... ou je suis hors sujet (désolé pour la pub) [18:24:48] --- Kadus vient d'arriver [18:25:18] --- Kadus est parti [18:25:32] Changaco > Pour le fait de remplacer des trucs avec javascripts, je ne suis pas d'accord. Par exemple, si tu utilises des effets du type lightbox, tu peux coder sans lightbox en affichant l'image dans une page qui lui est propre et avec javascript remplacer les liens pour utilise lightbox. [18:25:49] Bien sûr un chargement de page complexe en 350ms ça peut être un résultat très correct (voire bon). Un effet de rollover qui prend 350ms, par contre, c'est très mauvais. [18:26:11] --- Kadus vient d'arriver [18:26:18] alors pour la fibre c'est vrai si tu as une ligne pro [18:26:21] Yannick: Changaco ne parlait pas de ça, je crois. [18:26:29] --- Kadus est parti [18:27:10] [HS] J'adore la page d'accueil de http://galbraiths.org/ [18:27:31] Yannick, devoir gérer soi-même les galeries photos est quelque chose de tout à fait critiquable ceci dit [18:28:53] pablo: pour Opquast (très recommandable), il y a quelques critères qui concernent les performances client, mais seulement quelques uns. C'est un référentiel généraliste qui n'est pas pointu sur les différents sujets abordés. On ne fait pas un site accessible en appliquant les critères Opquast, mieux vaut appliquer le RGAA par exemple. On n'optimise pas les performances client d'un site à fort trafic en suivant les recommendations d'Opquast non plus (mais ça ne fait pas de mal). [18:29:24] devoir gérer côté serveur les miniatures d'images est parfois un problème également [18:31:06] [HS] Changaco > Tu peux aussi gérer tout ça depuis ton poste de développement. Ça dépend des sites ! ;-) [18:31:41] est ce qu'il y a des solutions futures pour les galeries photo? [18:32:11] Yannick, pas compris ce que tu voulais dire [18:32:27] bzh, qqch qui serait géré par le navigateur tu veux dire ? [18:33:21] Changaco > Bien, que gérer sois même la création d'une collection d'image et tout à fait envisageable, ça dépend du site en question. [18:33:36] un truc qui ne soit pas une bidouille de code avec des listes (
  • ) ou je ne sais quoi mais un vrai composant html par exemple [18:33:40] Bon eh bien, il faut que je plie bientôt. Si quelqu'un a une dernière question, je suis dispo quelques minutes. [18:33:42] bon après 1h30 de clavardage je crois que nous avons fait le tours, je vous souhaite une bonne soirée et à une prochaine [18:34:01] bzh, pas à ma connaissance [18:34:12] ++ pablo [18:34:18] --- pablo est parti [18:34:39] Florent, tu m'as pas dit comment "simuler" une connexion lente. [18:34:45] dommage :) [18:35:23] Yannick: je n'ai plus le nom des logiciels en question en tête, mais ça doit se trouver. [18:35:51] Pour finir, un peu de lecture (les commentaires sont intéressants aussi ;)): http://performance.survol.fr/2008/06/a-quoi-ca-sert/ [18:37:31] bzh > Pour le photos, personnellement j'utilise
    (liste de définition) avec l'image dans le
    et la description dans le
    . Mais avec HTML et (ou quelque chose comme ça) arrive. C'était ta question ? [18:38:15] Bonne soirée, et à une prochaine. [18:38:21] @+ Florent V. [18:38:29] Bonsoir. [18:38:35] --- Florent V. est parti [18:38:40] bonne soirée. Yannick oui en gros. [18:40:00] s'il y a des gens qui veulent prolonger le débat → http://forum.alsacreations.com/topic-9-43183-1-Discussion-du-mois--integration-web-et-performances-client.html [18:40:33] Sémentiquement, l'utilisation d'une liste de définition permet d'« accrocher » la légende à l'image, mais je ne sais pas si les moteurs de recherche en tiennent compte. [18:42:51] bon s'il y a pas d'autres interventions je coupe les logs [18:43:20] Bonne soirée tout le monde. [18:43:52] --- LOGGING STOPPED