Group items tagged

gros parti pris de Souders sur l'exécution de javascript : il ne devrait même pas être asynchrone, mais différé jusqu'à ce que la page soit rendue

Il n'a pas tout à fait tort, mais il oublie quand même pas mal de choses sur les interfaces modernes. Beaucoup n'ont pas de fallback, ou un fallback très mauvais. Genre un bouton commander qui ouvre une popin. Il est impossible d'envisager ne pas accrocher immédiatement le gestionnaire javascript

en même temps les "fortune 1000" ne sont surement pas tout purement Web, et pour les sites corporates, je ne pense pas que le manque de performance soit très grave

Proposition pour embarquer l'alpha dans un fichier JPEG

j'espère que ça restera vraiment une "expérience", utiliser canvas, javascript, css pour afficher une image transparente, avec ces inconvénients : # By default, the images load without their alpha, then get alpha'd causing a flash. This can be worked around by making them invisible until correctly loaded. # The image must reside on the same server as the web page or the cross site scripting prohibitions in AJAX will come into play. # My examples are double loading the image, for some reason the AJAX fetch is not using the cache. I don't know why, but it is probably just me. ça reste un affreux bricolage qui pourrait donner des envies à des gens qui n'y connaissent rien et pourrir des sites avec ça. Mais l'expérience est "amusante" de là à en faire une "proposition", j'ai des doutes

C'est clair qu'afficher l'alpha avec canvas+js reste du bricolage. En revanche, si les implémenteurs arrivent à se mettre d'accord pour le faire directement dans le navigateur, ça pourrait être intéressant.

Certes le discours est très commercial "intégration en 5 minutes etc.." Mais c'est la vérité ! Vous conservez toute votre architecture normale, vous changez les urls d'appel pour les pages de prod, et voilà ... Il s'occupe ensuite de récupérer les fichiers, à la demande. Amazing !

Ah et bien je veux bien que tu me passe une liste si tu as .. Moi je ne connais que celui ci

Je connais au moins PantherExpress (enfin, CDNetworks maintenant) parce-que c'est ce que libération utilise, mais il yen a d'autres, je préfère pas donner de nom par peur de me gourrer vu que les offres ont tendance à changer (si il ya un truc chiant avec les CDN, c'est bien l'impossibilité de comparer leurs tarifs vu le milliard d'offres différentes et services proposés autour), mais c'est un sujet récurrent sur stackoverflow et compagnie, donc une petite recherche sur "cdn origin pull" devrait t'en donner un paquet

il modifie à la volée le HTML pour gérer le cache des statiques, compresser HTML, concaténer JS/CSS, mettre CSS/JS inline ou le contraire,

rien d'exceptionnel pour ceux qui l'ont déjà codé à la main, mais ils disent avoir une solution pour les pubs avec document.write(), à tester donc ... pour reproduire leur technique :)

En général, je scrolle assez vite, et je ne supporte pas le lazyload des images. Donc pour les pubs, ça risque de m'énerver encore plus... ;-) Pour ce qui est du revenu à l'affichage, clair que ça le fait diminuer. Il faut privilégier le revenu au clic...

J'aime le lazyload des images s'il est immédiat, sans fade à la noix. Je pense que les lazyload lents ne sont dû qu'à de mauvais plugins/méthodes.

l'auteur suggère de gérer son cache en javascript pour la partie intelligente = ne recharger la page que lorsque quelque chose a changé. Ca fait un bout de temps que j'y pense, mais j'hésite à mettre ce genre de chose en prod

leur système de centralisation des "widgets" avec chargement non bloquant à la demande et récupération + routage des events sur la page est intéressant. Ca illustre pas mal la tendance de tous les sites Web à se transformer en vraie appli Web

Tests defer attribute of the script element for browsers with JavaScript.

J'ai beaucoup parlé de CSS, de réseau, de javascript, et j'entend parfois dire que le HTML lui n'a aucune importance. Ce n'est malheureusement pas vrai. Il y a au moins trois points à regarder dans le HTML : la qualité syntaxique du code, le mode de rendu des tableaux, et le nombre de noeuds DOM. Je vous détaille le premier ici, les deux autres bénéficieront d'un billet dédié afin de mieux organiser les commentaires.

Qui aime attendre pour charger une vidéo ? probablement personne. Du coup quand vous arrivez sur une page avec une vidéo, le lecteur précharge le début au cas où vous voudriez la jouer. Même une fois en lecture, votre logiciel tente d'avoir toujours une avance confortable sur le chargement de la vidéo afin de vous éviter d'avoir à attendre. Sur le principe c'est bien.

À partir de quand une page est-elle lente ? Combien de temps est prêt à attendre un utilisateur ?

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.

Ceux qui ont utilisé les jeux vidéo il y a 10 ou 15 ans connaissent forcément les sprites. Pour économiser les ressources on regroupe toutes les icônes et les images dans un ou plusieurs fichiers. Le résultat c'est une sorte de tableau d'images, le jeu utilise alors simplement une partie de cette image à chaque fois qu'il a besoin d'une icône.  Tout est une question de ressources disponibles, à l'époque on parlait de mémoire occupée et d'accès disque. Plusieurs années après, le Web a les mêmes problématiques : la poids et le nombre d'éléments à charger impactent directement et fortement les performances des pages. Il est donc logique qu'on utilise les mêmes solutions.