Le mardi 4 juin 2013 de 8h30 à 11h, 105 rue La Fayette, à Paris, ce petit-déjeuner, ouvert à tous, abordera les différentes solutions d'optimisation orientées web au travers du cache, du navigateur mais aussi de Javascript. Cette rencontre concerne tous les acteurs qui travaillent sur Internet avec des interventions plutôt techniques.
8h30 - 9h15 : la mise en cache HTTP
par Benoit Merlet, consultant technique
Vision d'ensemble et exploitation des différentes méthodes de caching HTTP.
9h15 - 10h : optimisation navigateur
par Hugues Moreno, responsable de l'offre accessibilité
Solutions et quirks pour optimiser la mise en cache des assets dans le navigateur.
10h - 10h45 : optimisation Javascript
par Jonathan Rivalan, ingénieur d'études R&D
Techniques d'optimisation d'écriture et d'exécution Javascript
Aller plus loin
- Inscription Meetup (149 clics)
# Groupage css = bad
Posté par alpha_one_x86 (site web personnel) . Évalué à -1.
Pour la 1ere partie, prendre en compte:
http://ultracopier-wiki.first-world.info/wiki/Theoretical_css_grouping_on_site_web
Car beaucoup de monde font l'erreur de grouper les css. Donc si la template varie, tu re télécharge un partie déjà téléchargé, et la bande passante augmente, même si la taille téléchargé par page diminue.
Il vaut mieux télécharger plus et avoir en cache, que télécharger moins en permanence.
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: Groupage css = bad
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 3.
Ça dépend du projet. Si tu développe un jeu qui fait de l'AJAX intensif, il n'est pas forcément stupide d'embarquer tout le contenu dans un gros fichier HTML (image, CSS et scripts compris). Ce sera plus rapide que de télécharger 10.000 fichiers.
Bien sûr, il ne faut pas que le contenu de cette « archive » de jeu doive changer toutes les cinq minutes.
[^] # Re: Groupage css = bad
Posté par devnewton 🍺 (site web personnel) . Évalué à -3.
Si tu développes un jeu qui a des besoins intensifs avec des technos web, tu es mal faisant.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Groupage css = bad
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 3.
Je suis bien pire que ça, je travail dans l'édition de jeux pour une plate-forme sociale dont on ne dit pas le nom.
[^] # Re: Groupage css = bad
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Si tu deviens millionnaire, tu seras pardonné!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Groupage css = bad
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
Je me ferais pardonner en sponsorisant des projets libre, le jour où je ne serais plus salarié ;
[^] # Re: Groupage css = bad
Posté par claudex . Évalué à 7.
Grouper les CSS, ce n'est pas pour gagner de la bande passante, c'est pour diminuer le nombre de connexion au site lors du téléchargement de la page et donc gagner potentiellement du temps pour afficher la page (en fonction du protocole utilisé pour se connecter au site).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Groupage css = bad
Posté par maboiteaspam . Évalué à 0. Dernière modification le 30 avril 2013 à 13:30.
Oui. Mais dans un contexte mobile groupir ou non groupir, c'est vraiment la daube.
Si tu groupes, alors ton utilisateur subira probablement moins de difficultés sur la 1ere page,
mais cela retire tout une couche d'optimisation car cela casse la dépendance url <-> contenu.
Si tu ne groupes pas, alors le chargement de la première page peut donner une très mauvaise expérience à l'utilisateur,
mais par la suite la stratégie de cache est plus efficace.
Bref, ce n'est ni tout blanc, ni tout noir.
Mais ceci dit, si à la base les css sont bien ficelées et pas trop lourde, alors minification + gzip peuvent produire des résultats formidable.
La question peut alors se tourner en, vaut il mieux faire 2*10k ou 1 fois 4k ? (le serpent qui se mange la queue)
N'oublions pas les paramètres réseaux, au début du mobile le réseau était edge, maintenant il est 4g.
Beaucoup plus rapide.
Et, amha dans cette configuration, l'expérience utilisateur est beaucoup plus sensible au nombre de requêtes (à cause de l'itinérance) qu'au poids intrinsèque.
Bien sûr, tout ma réflexion se porte dans l’intérêt du client et pas le serveur.
Je ne travail pas dans des environnements à la facebook / twitter ou lorsque tu changes le format d'image de prédilection les répercussions sont phénoménale.
[^] # Re: Groupage css = bad
Posté par Kerro . Évalué à 4.
Il ne reste plus qu'à avoir ton code qui vérifie si le visiteur viens d'arriver sur le site.
S'il viens d'arriver, fichiers rikikis.
Sinon, redirection vers fichiers maousse.
Par contre ça complique : il faut une moulinette pour concaténer tout ça proprement. Pas gagné dans certains cas.
[^] # Re: Groupage css = bad
Posté par maboiteaspam . Évalué à 1.
tu n'as que l'embarras du choix pour ce faire.
Avec tous les outils à ta disposition c'est facile de concaténer des scripts, images, css.
Avec les projets comme photon qui ajoute des workers à ta base serveur, c'est a portée de main de bien des projets.
Maintenant il y à très surement de meilleurs solution. On y reviendra plus tard.
A ton sujet, je sais pas.
a+
[^] # Re: Groupage css = bad
Posté par ariasuni . Évalué à 1.
Je pense surtout qu'il faut arrêter de foutre du Javascript partout. Je préfère mille fois un menu qui prend de la place et qui m'oblige à faire défiler la page qu'un menu en Javascript qui met 1/2 seconde à s'ouvrir, et seulement ensuite on peut commencer à analyser le menu.
+1
P.-S.: la 4G la bonne blague. Je suis dans la négion parisienne et j'ai jamais eu de 4G avec Bouygues (la même chose pour SFR et Orange d'ailleurs).
Écrit en Bépo selon l’orthographe de 1990
# Vidéos des conférences
Posté par RyDroid . Évalué à 3.
Y aura les vidéos des conférences en libre accès ? en torrent ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.