Reprise du message précédent :
Performance / cache client / premature optimization proof
 
A la construction de ma page, je récupère une liste côté serveur, et je m'en sert pour construire une carte à coup de Raphael.JS.
C'est long, d'autant que la même carte est répétée sur de nombreuses pages. Y'a pas moyen de mettre en cache côté client le SVG/VML généré ? Je peux accélérer un minimum en mettant en cache côté serveur la liste de données, mais c'est vraiment pas là le bottleneck
 
J'ai bien trouvé ça //github.com/jspies/raphael.serialize
Mais ça ne permet que de sauter l'étape de construction (certainement la plus coûteuse, on est d'accord), mais c'est encore loin d'être optimal, et je ne vois de toute façon pas comment je peux utiliser les données serialisées d'une requête à l'autre.
 
Et avant qu'on me propose de remplacer le tout par une image, j'ai des données qui changent (rarement, mais quand même), la carte est construite à base de path et circle qui peuvent être des liens.
 
 

Déjà coté serveur tu peux commencer par mettre/vérifier le header ETag sur ta réponse HTTP, ça évitera la partie téléchargement de la liste quand elle n'a pas changé.
Ensuite tu devrais pouvoir stocker une version sérialisée du SVG/VML dans LocalStorage, le problème c'est que c'est précisément dans les navigateurs les plus lents que ce cache ne sera pas supporté (à moins d'utiliser un polyfill), et c'est pas certain que la deserialisation+parsing par raphaël soit plus rapide que l'interprétation de la liste d'origine.

Voilà, ça c'est fait.

 

Donc aucun moyen de faire une mise en cache plus classique que LocalStorage ?
 

 
Il n'y a pas de positionnement, donc c'est juste quand tu choisis le type de moustache qu'il va y avoir un appel au script.
Je cherche pas à le protéger à 100%, mais juste de rendre la tache la moins accessible possible pour celui qui voudrait nous piquer le système et les éléments graphiques, vu que la conception va demander du temps et de l'argent

 
 
[mode gros bourrin]
hum... fournir directement un svg?
[/mode gros bourrin]

IE8 va adorer

et si je rajoute 'ou vml' a la fin? c'est mieux? hahaha
 
sinon tu peux serialiser et renvoyer le json au serveur pour storage. au prochain load si ca a pas changé ben tu le recup direct.

 
Compatibilité IE6+.
 

 
J'ai pas de JS en serverside et j'en rajouterais pas uniquement pour ça, avec l'équivalent (génération SVG + VML) en Java j'ai rien contre. Mon internet mondial merdoie, pour le moment j'ai pu zieuter que raphaelgwt, mais pas GWT chez nous.
 

 
Voir la réponse de 0x90 là dessus, sur les postes peu puissants et les vieux navigateurs (ça va souvent de paire), le process de deserialisation pourrait être aussi long que celui de construction.
 

ARRÊTEZ MOI OU JE FAIS IMAGE + MAP §§§

oui je pensais a une generation server side, mais si tu est passé par raphael c'est certainement pour de bonnes raisons et tu peux probablement lancer une generation raphael lors de l'edit de cette liste  
 
ce que dit 0x90 c'est que sur les postes peu puissant/nav merdiques, que le svg/vml *serialisé* soit en cache ou pas la différence est peut etre minime (mais a confirmer avec des metriques).  
 
ce que je proposais c'etait plutot de renvoyer le json au serveur qui s'en sert pour generer le svg/vml  et/ou une image + map correspondant.
 
c'est discutable mais au moins tu identifies la taille de l'objet serialisé et tu vois celle du svg resultant
 
le navigateur ne chargeant qu'un svg/vml ou une image tu limite la charge (pas de process ou alors process natif svg ou vml)
 
apres si tu dit qu'un bon truc full server side ca te pose pas de probleme et que tu utilise que des circle et paths relativement simples, tu peux directement ecrire les svg/vml en java ou php ou ce que tu veux

ah mince, je viens de te proposer une image + map....

Ça va que je fais du web deux fois dans l'année, sinon la contrainte IE6  

le svg, c'est supporté à partir d'IE 9 , donc windows 7

 
Heu IE6 n'est plus à prendre en compte dans des développements pour le marché occidental (moins de 1% de part de marché selon Microsoft en France, et 0,3% constaté chez nous)
IE7 rejoint peu à peu cette catégorie. (1.3% de PDM selon StatCounter Juillet 2012)
 
Faut développer en prenant en compte à partir de IE8

 
Et qu'est-ce qui te dit que je développe pour l'intarweb ?

En intranet hospitalier on est à 7% de IE6 et 55% de IE7 avec 80% sous Win XP.

 
Je sais pas quoi te répondre    
Sur la COGIP, c'est 90% du parc en IE6. La migration à commencé, mais si je veux faire un truc compatible maintenant, je peux pas négliger IE6.
 

Ca n'attendait pas de réponse

Je me suis inspiré de ça (la solution full HTML + CSS, pas le plugi jQuery) : http://stackoverflow.com/a/1965076
 
Back in 00', j'ai du style inline, des background images pour le fond et dans les liens, des positionnements absolus... Mais je gagne la mise en cache gratos et un facteur trouzemille sur IE6 et machines préhistoriques à l'affichage.
 
/html_real_escape_map

Vous doublez les factures au moins pour le support ie6 ?

 
Doubler par rapport à quoi ? D'une, tous nos projets ont cette même contrainte (intranet de notre COGIP) et de deux, même si c'était pas le cas, ça serait clairement arbitraire et sur-évalué : le gros du taff est sur le backoffice dans notre métier, ce qu'on sort sur le navigateur n'est que la partie visible de l'iceberg.
 
Pour ce projet par exemple, le support IE6 ne m'a emmerdé que pour cette carte SVG, et encore. Si y'avait pas eu ce problème de perfs, je serais resté avec Raphael.JS qui gère très bien la compatibilité préhistorique.
 
Pour le reste, j'ai pas eu un bazillion de bug IE6+, contexte de formatage (anticipé pendant le dev) et double margin (voir quelques posts plus haut) qui est le seul bug spécifique IE6 qui a fait l'objet d'un ticket indépendant. Alors certes, c'est pondéré par la complexité plutôt basse du front, mais y'a pas de quoi crier aux cadences infernales non plus.
 
Ceux que je plains sincèrement, c'est ceux qui doivent pondre un site internet compatible IE6, ça doit encore se trouver. Là effectivement, à leur place, j'enverrais la sauce sur la note

Scuse, c'est de ma faute en effet !
J'oublie toujours qu'il y a des intranets et que le matériel n'est pas toujours au rdv

 
C'est un euphémisme
Encore 1 an, et le seul souci sera IE8    
 

Ce qui est déjà largement moins pire !

Au fait à partir de IE9 y a plus trop de différence avec les autres navigateurs non ?

Y'aura toujours des bugs très ciblés, mais le principal gap sera au niveau des supports HTML5/CSS3 à des degrés différents, API JS, WebGL et autres joyeusetés. Et puis bon, navigateurs mobiles.
Quand tu vois le bordel que ça a été pour les codecs vidéos déjà...
 
Also http://caniuse.com/

Nan ca comment ça devenir propre, mais c'est seulement à partir du 10 qu'on est vraiment très propre, ils ont attendus 10 ans avant de sortir une version potable de leur navigateur.

IE10 ne gère meme pas text-shadow... quelle honte..
 
sinon j'essaie de faire un empilement d'image très simple (en html une liste) comme ceci:

 
 
je pensais que ça allait marcher en inline block, mais il le fait bien jusqu'au 4, qu'il place sous le 3... je vois pas pkoi

Si ça gère Pour les anciens, on peut passer par un filter

 
Si ça ne marche pas, c'est qu'il doit être dans un de ses (nombreux) modes de compatibilité. En mode "respect des standards", ça fonctionne.

Effectivement, je viens d'aller voir sir can i use a l'époque dans les Preview, ça n'était pas géré. Bon finalement, il sera pas trop mal cet IE10

http://webplatform.org/

Vous connaissez Maxthon ?  
 
C'est un browser made in china, compatible avec Mac / Windows / iPad / etc. Très bon rendu de HTML5.  
 
http://en.wikipedia.org/wiki/Maxthon
http://www.maxthon.com/
 
Il faudra surement compter avec lui dans les prochaines années.
Il serait (apparemment), 200% plus rapide que Chrome et serait sur la voie des 1% de PDM.
 
A surveiller de près

Nan mais maxthon c'est une surcouche IE ou qui utilise le moteur de FF (gecko), ya rien à craindre du tout sur ce navigateur.
Ca fait des années et des années qu'il existe et je l'utilisais beaucoup à l'époque ou IE6 était quasiment seul sur le marché.

Bon maintenant il embarque webkit, ben qu'il embarque webkit, ça ne sera pas un problème, faudra juste qu'il reste à jour.

Ça a des années (la v1 est sortie en 2003, et c'est un renommage de MyIE2, qui lui même est une évolution de MyIE, donc le projet date de 2000... pour référence c'est avant Chrome, avant Safari et avant même Firefox), c'était initialement une interface par dessus Trident (MSIE), ils ont ajouté Gecko et Webkit par la suite, ya rien de spécial ou d'impressionnant (sans même parler de choses à surveiller) et la déclaration de "200% plus rapide que Chrome", ça me semble être du pur bullshit, je ne vois rien qui pourrait de près ou de loin supporter une déclaration pareille dans le cas général.
 
Quand au rendu HTML5, bah c'est celui de webkit quoi Il a le 2e score html5test parce qu'il utilise la 2e plus récente révision de webkit dans un navigateur en prod

Oui c'est du Webkit par défaut maintenant. Et à ma connaissance c'est le webkit stock, donc le "200% plus rapide que Chrome" me semble relativement douteux

Oh le coup de vieux

Quand fallait convaincre toute la bande de lamerz qui utilisaient maxthon, parce que "y'a des sites qui marchent pas avec modzila"

Vous êtes au courant d'un bug IE8 qui ne prend pas en compte une surcharge de sélecteurs ?
 
Sous tous les navs sauf sous IE8 j'ai ça :

 
Sous IE8 .autodiagnostic .block-content n'apparait même pas dans leur barre de dev

T'aurais pas tappé dans le nombre maximum de règles css par fichier par hasard (4096) ?
 
http://big-webowsky.meetpollux.com [...] xplorer-8/

 
C'est marrant je suis totalement passé à travers.
A la fin des années 90/début 2000, moi j'étais à fond dans Opera et ses onglets (qui sont maintenant banals...).
Donc du coup j'ai du passer à coté du super MaxThon (faut dire le nom fait pas rêver )
 
Ou alors vous êtes tous des chinois !  
Pourtant c'est moi qui vit en Asie sur ce topic, y a un truc louche

Je connais Maxthon uniquement parce qu'à l'époque où ça a changé de nom de MyIE2 vers Maxthon, je fréquentais un forum où la majorité ne jurait que par ce browser