Group items tagged

"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."

content adaption without increased client latency

There was a time when doing a Website Load Test for a client using a Content Distribution Network (CDN) was an infrequent activity, but these days it's a common occurrence. There are more CDN suppliers of course, the newer ones such as MaxCDN, the traditional big names like Akamai and LimeLight, and some Datacentres such as UKFast offer CDN services directly to clients themselves.

Les slides de la conf que j'ai donné au PHPTour 2011 à Lille

Comment réduire la charge CPU et le temps d'affichage des pages en SSL, avec un patch et pas mal de bonnes idées.

côté serveur, ça a l'air par mal, surtout qu'ils l'ont testé sur Gmail. Par contre côté client, il me semble que tous les objets (images, css, js) ont aussi besoin d'être décodés, ce qui prend du temps CPU au client. Pour Gmail qui a très peu d'images, ça n'est pas un problème, mais pour un site lambda, ça peut commencer à compter

On annonce des gains au final de 30% à 60%, cela semble assez important. Est-ce vraiment intéressant dans tous les cas ?. C'est un besoin pour les sites à gros traffic/ non optimisé / avec du contenu 'peu dynamique". Comment Fasterize actualise t'il sa propre version , uniquement lorsque le client demande une url ? Il serait intéressant d'avoir un peu de détail sur l'échange entre fasterize et le serveur.

SPDY is awesome. It's the first real upgrade to HTTP in 10+ years, it tackles high latency mobile networks performance issues and it makes the web more secure. SPDY is different than HTTP in many ways, but its primary value comes from being able to multiplex many requests/responses from client to server over a single (or few) TCP connections.

et le blog qui va avec : http://00f.net/2010/09/22/transparent-client-side-fragment-cache/

Le saviez-vous ? Certaines universités ont des cours très pointus et pertinents sur les technologies web client, y compris sur les performances

Je viens de croiser une liste de recommandations Microsoft pour la performance des sites web. On y retrouve plusieurs choses connues et une recommandation sur la cohérence des liens. La page MSDN donne l'exemple d'un même lien avec deux casses différentes. Certains serveurs ignoreront la casse ou corrigeront le lien mais cela restera deux ressources différentes sur le client, avec des entrées séparées sur le cache, donc au moins une requête HTTP inutile.

En avril je vous parlais du packer de Dean Edwards qui permet de miniser le code javascript avant envoi. J'émettais un doute sur l'option base62. Avec cette option le code javascript est codé avant envoi. Une fois ce javascript reçu, le navigateur va le décoder, puis utiliser eval() pour l'exécuter. C'est tout sauf transparent pour le client, surtout que pendant ce temps de traitement supplémentaire, c'est tout le rendu et les téléchargements de la page qui sont bloqués.

JSON ! c'est le cri de tous les développeurs web à la mode dès qu'ils entendent parler d'échanges de données. Ce format est sensé être plus performant, plus simple, plus standard, plus performant, plus web 2.0 quoi. Plusieurs points mériteraient un billet à part entière, et je suis en désaccord sur chacun d'eux, mais je me focaliserai ici sur un seul : la performance. Les performances peuvent se voir au niveau du téléchargement et au niveau de l'interprétation par le client.