More bandwidth doesn’t matter (much)
▻https://docs.google.com/a/chromium.org/viewer?a=v&pid=sites&srcid=Y2hyb21pdW0ub3JnfGRldnxneDoxMzcyOWI1N2I4YzI3
Tags : #bande_passante #webperf
More bandwidth doesn’t matter (much)
▻https://docs.google.com/a/chromium.org/viewer?a=v&pid=sites&srcid=Y2hyb21pdW0ub3JnfGRldnxneDoxMzcyOWI1N2I4YzI3
Tags : #bande_passante #webperf
à bas les RTT ;-)
▻http://en.wikipedia.org/wiki/Round-trip_delay_time
12 websites that prove RWD and performance CAN play well together
▻http://www.webperformancetoday.com/2014/03/25/12-websites-prove-rwd-performance-can-play-well-together
Tags: #webperf Responsive Web Design (RWD)
Rendering on the Server and #client in #Node.js
▻http://artsy.github.io/blog/2013/11/30/rendering-on-the-server-and-client-in-node-dot-js
“At Artsy we’ve been building Node.js applications that share code and rendering between the server and browser. We’ve seen many benefits from this – pages load faster, we can optimize #SEO, developers are more productive, and #JavaScript coding is just an overall better experience.” Tags: Node.js #serveur client #template #Ezel SEO #webperf #Backbone.js JavaScript
Web Performance: One or thousands of #Media_Queries?
▻http://helloanselm.com/2014/web-performance-one-or-thousand-media-queries
“engines do serialize and strip out duplicated media-queries so they only need to evaluate each media query once. Also they cache the queries so that they can re-use it later on” Tags: Media Queries Responsive Web Design (RWD) #webperf
Using #WebP with #Modernizr
▻http://www.stucox.com/blog/using-webp-with-modernizr
Tags: WebP #image #JPG #PNG Modernizr #webperf #format #optimisation #JavaScript #CSS
Smart Defaults: On Libraries & Frameworks - TimKadlec.com
▻http://timkadlec.com/2014/01/smart-defaults-on-libraries-and-frameworks
“I’ve worked on projects where some of the devices we needed to test on couldn’t load the page at all if #jQuery was present—it was just too much #JavaScript for the device to handle.” Tags: jQuery #librairie JavaScript #performance #webperf
Faut-il limiter le nombre de #Media_Queries ? (Sass and Media Queries)
▻http://sasscast.tumblr.com/post/38673939456/sass-and-media-queries
"Does combining the media queries have any actual performance improvements? Are people simply raising issue because they don’t like the way the output CSS looks? That’s a damn good question and one that Aaron also raised. As he put it, “Let’s ask science!”" Tags: Media Queries Responsive Web Design (RWD) #Sass #webperf
motherjones/grunt-html-smoosher
▻https://github.com/motherjones/grunt-html-smoosher
“A #grunt task which takes a html file, finds all the #CSS and js links, and outputs a version with all the css and js written #inline for ease of pasting into a cms” Tags: grunt inline #webperf CSS #JavaScript
Ça ne doit pas être bien compliqué pour quelqu’un qui fait du #Node.js … ou alors au moins une conf Grunt qui ne fait que ça.
Toujours motivé @fil ? J’ai bidouillé hier soir qq chose qui marche presque, il me reste à rendre synchrones les appels ’get’ vers les CSS / JS.
De quoi aurais-tu besoin comme options pour la ligne de commande ?
en option je dirais « minifier », « minifier-js », « minifier-css », éventuellement en passant en argument le minifier souhaité ; éventuellement, « mogrify » (pour envoyer un email avec le résultat), « strip-js » et « strip-css » pour virer js et css ; sinon, je sais pas :)
pour mogrify on peut le faire à part via #emogrifier ▻http://seenthis.net/messages/127820
Ok. Et plusieurs URL en arguments ?
ça peut accélérer les choses (pas besoin de charger les librairies nodeJS à chaque url à traiter).
Par contre, rediriger la sortie vers un seul fichier ne sera plus possible, sauf si on veut plein de pages html concaténées (on peut toujours écrire un genre de séparateur, sinon).
Bon, j’ai pas eu beaucoup de temps, mais j’ai quelque chose qui tourne. Le code est encore assez moche, car j’ai essayé plein de trucs.
Les retours m’intéressent car je n’ai pas très confiance dans la bibliothèque utilisée pour manipuler le html ("cheerio") : par exemple, sur ►http://seenthis.net, un fichier js n’est pas traité.
@robin m’a conseillé d’utiliser « whacko », mais celle ci ne renvoie pas de promises...
À tout hasard, @fil (ou quelqu’un d’autre) a pu tester ? ^^
Plop,
J’ai fait une mise à jour avec les options ’—strip’, ’—strip_css’ et ’—strip_js.
Pour mettre à jour une installation existante, faites un « git pull » dans le répertoire où vous aviez cloné le dépot.
A proposal for preloading resources bound by media queries | FT Labs
▻http://labs.ft.com/2012/08/a-proposal-for-preloading-resources-bound-by-media-queries
“In current implementations as of August 2012, no popular user agent pre-fetches resources that are subject to media queries until those media queries are satisfied. However, it seems like a more intelligent approach could be taken based on the liklihood that the media query may be satisfied at some point after a page has loaded.” Tags: Responsive Web Design (RWD) #chargement #ressource #webperf #anticipation
Des vrais tags, hein, ça f’ra pas d’mal ;-)
@james mon tag à l’origine est « Responsive Web Design (RWD) »…
L’origine ne m’intéresse pas trop :)
@rastapopoulos utilise aussi RWD, et d’autres sans doute.
Ce qui serait pas mal, c’est d’avoir ça en commun. Comme Seenthis signale les tags qui commence par les thèmes que l’on suit tout un chacun, te serait-il possible d’inverser : « RWD (Responsive Web Design) » ? la transformation dans seenthis devrait contenter tout le monde ?
Moi je suis le tag #responsive, alors je m’en fiche. :D
Du coup mon tag peut rester tel quel, c’est bien ça ?
@james il n’y a pas de mal ! ;-)
#SVG Editor & Optimiser
▻http://petercollingridge.appspot.com/svg-editor
Tags : SVG #webperf #image #optimisation #performance #javascript #CSS
Le poids des pages web a explosé de 150% en trois ans
▻http://www.journaldunet.com/developpeur/client-web/poids-des-pages-web.shtml
La principale cause de cette croissance ? A y regarder de plus près, la progression du poids des images et des scripts sont à l’origine du problème. Le volume d’images atteint désormais 804 Ko par page en moyenne, contre 372 Ko il y a trois ans. Quant aux scripts, ils passent dans le même temps de 100 Ko à plus de 230 Ko. Une tendance qui s’explique par la montée en puissance des pages web riches dotées notamment de modules AJAX.
Grosse modif de mon #plugin #SPIP image_responsive : il permet désormais de choisir de charger les images en lazyload
►http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive
L’idée, c’est de transformer un des inconvénients de ce système (lancer le chargement des images après un premier rendu de la page) en avantage, et d’intégrer directement un système de lazyload : c’est-à-dire ne charger que les images qui sont réellement affichées dans les limites visibles de l’écran.
Le plugin change de syntaxe : la deuxième variable permettait de désactiver le chargement des images haute définition, je décide de l’éliminer parce que ça ne sert à rien avec les modifs récentes (calculs et compression plus efficaces), et à la place, la seconde variable permet d’activer (si elle est mise à la valeur « 1 ») le lazyload sur cette image.
Par exemple :
[(#LOGO_ARTICLE_NORMAL
|image_proportions{16,9}
|image_responsive{0,1})
]
Ici, |image_proportions va recadrer l’image selon les proportions 16/9e, sans réduire cependant la taille de l’image.
Et |image_responsive va fabriquer les éléments permettant le chargement d’une image responsive. Ici, la première variable (« 0 ») est la taille de la vignette chargée par défaut (avec la valeur 0, je décide de ne pas intégrer de vignette : je charge « rien.gif » à la place). La seconde variable (« 1 ») indique donc qu’il ne faut charger cette image que si elle se situe dans la fenêtre visible.
Au passage, le javascript de lazyload est assez marrant, j’ai privilégié l’efficacité des calculs, du coup la « position » verticale de l’image dans la page est calculé une seule fois (au chargement et au redimensionnement) et stocké dans un « data-top », puis effacé. Ça évite de faire des calculs à chaque fois qu’on scrolle. En revanche, on perd potentiellement en précision (images qui se déplaceraient dans la page, ou blocs affichés/masqués).
À noter qu’il y a évidemment une tolérance : ça charge un peu plus que l’écran visible, c’est pas la peine que les gens voient trop que les images n’ont pas été chargées.
Enfin, il y a désormais un calcul en javascript de la hauteur des images tant qu’elles sont en "rien.gif", ça permet de calculer plus précisément le lazyload.
Comme d’habitude, je l’utilise sur Orient XXI :
►http://orientxxi.info
Je me posais la question au sujet du Lazyload, si y’avait pas une autre approche envisageable (c’est peut-être la tienne et j’ai pas compris) :
– afficher en priorité les images visibles
– puis aller chercher et « afficher » les autres images (sans attendre que la personne scroll, donc « en-dessous » de la ligne de flottaison)
J’ai l’impression qu’en terme de rapidité d’affichage c’est équivalent quand on arrive sur le site, mais que cette solution est plus agréable quand on scroll parce qu’on donne une chance pour que les images aient le temps de s’afficher avant (en tous cas forcément plus qu’avec le lazyload).
C’est peut-être au niveau de la consommation de la bande passante que la solution lazyload est plus avantageuse, mais je ne sais pas quand elle situation elle est vraiment utile.
Après je dis tout ça un peu comme ça, je sais pas précisément comment ça marche en javascript, peut-être que ce que je propose n’est tout simplement pas possible.
Une dernière remarque : y’a déjà un plugin LazyLoad dans SPIP.
▻http://contrib.spip.net/jQuery-Lazy-Load-pour-SPIP
Il ne fonctionne pas sur les mêmes principes, mais peut-être pourrait-il être amélioré, en lui donnant des options et tout ? Ou peut-être autonomiser cette fonction si des gens veulent l’utiliser sans le reste du plugin (là encore, tout ça est peut-être trop imbriqué...) ?
En tous cas merci pour toutes ces contributions autour des images et du #RWD.
En gros, ce que fait LazyLoad, c’est de lancer le script jquery Lazy Load, très connu. Mon script est très différent, et son principe de fonctionnement est également très différent, j’ai essayé d’optimiser (limiter les recalculs de positionnement) et ça doit fonctionner en responsive (donc je ne fixe pas les dimensions des images a priori).
Ensuite, le principe du lazy load n’est pas idéal non plus dans l’absolu (notamment parce qu’il bloque le pré-chargement des images). En tout cas, le fait de charger des images progressivement avant de les afficher, c’est l’assurance de ne pas afficher toutes les images en même temps. Si on a de grosses images, ce n’est pas grave (il y a une image par « écran », plus ou moins), mais si c’est une multitude de petites vignettes (c’est le cas de Flip-Zone), la page est redessinée plusieurs fois (à chaque vignette) et c’est pénible ; en changeant d’un coup toute une série complète de « img src », j’ai bien l’impression que les navigateurs sont optimisés et assez souvent, toute une série de vignettes s’affichent d’un seul coup. Avec un preloading individuel, ça n’a pas l’air de faire pareil (une de mes versions faisait ça : préloading puis affichage). Le preloading avant d’afficher, c’est pas mal sur tout petit écran, mais ça m’a semblé au contraire très pénible sur écran normal.
Sinon, un preloader de toutes les images, c’est une idée, mais c’est encore un autre principe à mon avis. Je n’y suis pas favorable pour l’instant : charger des trucs « en trop », c’est justement ce qu’il s’agit d’éviter avec les image_responsive (parce qu’on est sans la 3G, parce que le smartphone n’est pas très vaillant…), alors pour le coup, ne charger que si les gens scrollent réellement. Et si tu veux faire ça, à mon avis, le mieux est encore de ne pas utiliser l’option « lazyload » de mon plugin : tu laisses le comportement normal, et je suspecte que c’est plus ou moins le principe de base d’un navigateur a qui on indique tous les « img src » d’une page – il commence par les premiers et/ou les éléments visibles.
une revue numérique indépendante
traitant de design, de diy et de combinaisons spatiales
Strabic.fr est une revue oblique qui parle de conception et d’arts de faire.
Strabic.fr est née d’une volonté profonde : parler de design sans paillettes ni projecteurs, de forme et de fond, de ce qui se fait et ce qui peut se faire, de pourquoi et comment cela se fait, d’extravagance et d’excursions, avec exigence et exotisme.
Strabic.fr est une revue à géométrie variable mais à mémoire de forme. Elle se fabrique dans nos cuisines, à l’heure de l’apéritif ou du café, entre amis et avec ceux qui le deviennent.
via @julienb , à l’occasion d’un rafraichissement du site.
Je n’ai plus de tablette (je viens de finir le cote d’or aux noisettes).
Pour la lecture, le corps de texte est sympa je trouve (mais je n’irais pas plus gros... on se perd vite dans le texte). Par contre, les titres, intertitres, chapeaux, etc... sont assez durs avec les yeux. Sinon, j’aime assez ce que j’ai pu lire du contenu :)
@ari Les boss de la typo sont sur ce genre de tailles : ▻http://ia.net/blog (en em, mais ça revient au même avec 16px comme police de navigateur). ►http://medium.com est sur du 22px. Après, ce sont des textes en anglais, ma lecture n’est peut-être pas la même. @orientXXI y va fort aussi sur les chapô : 1.6em. Sur le texte de paragraphe c’est plus léger, et il tente de la césure.
A vrai dire, je trouve encore que c’est chez strabic que c’est le mieux réussit. Le rapport longueur de ligne / hauteur de ligne / taille de caractères. Par contre leurs citations sont pas top, je les mettrais un peu de retrait, avec un poil plus d’espace, voir dans une autre couleur.
@habbon quand t’arrives d’un Indymedia, ça fait mal aux yeux ^^ Non mais sinon c’est pas mal, même si je préfère ia.net pour le corps de texte de l’article.
Sinon quelqu’un-e aurait une idée de la technique utilisée pour faire apparaître les images au chargement, c’est un plugin spip ça ?
#beau et pis #spip_blog aussi pour les jolis sites innovants sous Spip non ? (en plus y’a plein d’articles intéressants effectivement).
Google « #lazyloading images ».
Moi j’ai tendance à trouver ça pénible.
Faudrait qu’ils chargent peut-être un peu avant qu’on arrive dessus (c’est peut-être déjà la cas ceci dit).
Je suis pas sûr qu’on gagne beaucoup l’un dans l’autre entre le côté pénible de l’image qui « flash » et le fait que la page se charge plus rapidement.
Une attitude où on charge au plus vite ce qui est visible puis ce qui n’est pas visible sans attendre qu’on l’atteigne me parait une meilleur pratique.
Si des gens ici ont des idée pour bien faire ce genre de choses...
Ça me fait penser à ce post de Cerdic ce que je dis juste au-dessus : ▻http://blog.nursit.net/slider-d-images-attention-au-temps-de-chargement.html
@ari pour les jolis sites innovants sous #spip ça serait plus ►http://herbier.spip.net ;)
@b_b, herbier.spip.net me paraît parcellaire et n’annonce pas les reliftings, non ? J’ai pas le temps de regarder tous les sites de la galaxie, si le spip_blog peut proposer un digest ou juste signaler un ou deux nouveaux sites remarquables tous les mois, ce serait vraiment bien :)
@Ari : l’Herbier propose effectivement une sélection, de sites tels qu’ils apparaissaient à un moment T sur la toile. C’est surtout un album souvenir.
Sinon, hors la lisibilité réussie des pages de texte, c’est quand même très laid, Strabic :(
PageSpeed Insights
▻http://developers.google.com/speed/pagespeed/insights
Tags : #performance #webdev #webperf
Lightening Your Responsive Website Design With RESS | Smashing Mobile
▻http://mobile.smashingmagazine.com/2013/10/08/responsive-website-design-with-ress
Tags: Responsive Web Design (RWD) #webperf
#Google #mobile search is getting faster
▻https://plus.google.com/+IlyaGrigorik/posts/fPJNzUf76Nx
“Google mobile search is getting faster - to be exact, 200-400 milliseconds faster! We are gradually rolling out this improvement to all browsers that support the attribute (currently, mobile Chrome and Safari).” Tags: #webperf Google mobile #redirection #ping (...)
▻http://www.clubic.com/internet/actualite-570456-webp-image-cree-desaccords-google.html
SeenThis ne limitant pas le nombre de caractères par message, on peut s’autoriser à éviter les urls courtes ;-)
Les bonnes pratiques #webperf toujours sous la main
▻http://gasteroprod.com/blog/les-bonnes-pratiques-webperf-toujours-sous-la-main
La collection « mémento » de chez Eyrolles vient de s’agrandir, avec l’ajout d’un petit nouveau dédié aux performances web, en termes de vitesse. Incontournable ! Et je ne dis pas ça juste parce que j’ai eu l’honneur d’être invité à participer à sa relecture par ses auteurs Armel Fauveau et Lionel Pointet, c’est vraiment un condensé — très complet et didactique tout de même — des principales bonnes pratiques à respecter pour développer des sites performants, et donc plus agréables pour les visiteurs. (...) (...)
#Blog #livre
▻http://www.eyrolles.com/Informatique/Collection/4143/memento.php
▻http://www.eyrolles.com/Informatique/Livre/memento-performances-web-9782212136586
▻https://twitter.com/fauveauarmel
▻https://twitter.com/lpointet
▻http://www.clever-age.com/veille/reactions/pagespeed-et-yslow-ne-sont-pas-des-indices-de-performance.html
▻http://twitter.com/kjoly
#WebPage #Test Details - Paris : www.mond...13/04/HALIMI/48965 - 03/29/13 12:41:33
▻http://www.webpagetest.org/result/130329_J4_F4Z/1/details
Caching and the #Google_AJAX_Libraries — statichtml.com
►http://statichtml.com/2011/google-ajax-libraries-caching.html
using #Google ’s #CDN to load #jQuery isn’t likely to benefit the majority of your first-time visitors. You’re almost certainly better off bundling jQuery up with the rest of your site’s JavaScript and making sure you’re serving long-lived #cache controlling headers with it.
February 08, 2012 - Akamai Acquires Blaze
►http://www.akamai.com/html/about/press/releases/2012/press_020812.html
#Akamai Technologies, Inc. (NASDAQ: AKAM) announced today that it has acquired #Blaze Software Inc., a provider of frontend optimization (#FEO) technology, in a cash transaction. The acquisition is expected to complement Akamai’s market-leading site acceleration solutions with technology designed to optimize the #speed at which a web page is rendered, regardless of end user device.
Layout paint flashing in Firefox « JAWS
►http://msujaws.wordpress.com/2012/02/01/layout-paint-flashing-in-firefox
Starting in #Firefox 11 (currently in the beta channel), there is a hidden #preference (nglayout.debug.paint_flashing) to enable what we call “paint flashing”.
Whenever the layout engine determines that a region of the browser requires repainting, the region is tinted with a random color value. Regions experiencing heavy paint flashing can turn your browser in to a fun rave, but also show web developers (and browser developers too!) areas of the code that aren’t being as optimal as possible.
JPEGmini | About
►http://www.jpegmini.com/main/about
#JPEGmini is a patent-pending #photo re #compression technology, which significantly reduces the size of photographs without affecting their perceptual quality. The technology works in the domain of baseline #JPEG, resulting in files that are fully compatible with any browser, photo software or device that support the standard JPEG format.