Group items tagged

à voir quand même à quel point ça ne lance pas un timer qui occupe le cpu navigateur inutilement

A noter que si les js sont insérés en bas de page, le gain sera moindre puisque le dom sera chargé. Remarque, utiliser $(document).ready() en bas de page c'est peut-être un peu enfoncer des portes ouvertes.

Utiliser trop souvent $(document).ready sur VOTRE code c'est aussi laisser tous les autres scripts (pubilicités/widgets) s'exécuter avant vous. Ainsi ils peuvent créer autant d'éléments et occuper des requêtes navigateur pour rien. Trop souvent il est automatiquement conseillé d'utiliser $(document).ready (genre dans les guidelines pour débutant), sauf que la plupart des widgets (et surtout des publicités) se moquent de ces recommandations. Toujours maitriser l'ordre de téléchargement des éléments de votre page avant de décider d'utiliser ou non $(document).ready pour vos initialisations.

Chrome peut, dans certains cas, bloquer l'exécution de scripts qui utilisent document.write(), une très mauvaise pratique pour la performance Web.

Alternative à Ghostwriter ou ControlJS : permet de reporter le document.write de certains scripts à plus tard dans le flux de chargement de la page, afin de ne pas retarder le Load. L'intérêt de la solution est qu'elle ne perturbe quasiment pas le script original, ce qui en facilite grandement la maintenance.

"The @font-face rule is designed to allow lazy loading of fonts, fonts are only downloaded when needed for use within a document."

"Scour is an open-source Python script that aggressively cleans SVG files, removing a lot of 'cruft' that certain tools or authors embed into their documents. The goal of scour is to provide an identically rendered image"

"The impact of CSS selectors on performance derives from the amount of time it takes the browser to match the selectors against the elements in the document. Developers have some control over how long this matching takes by writing their selectors to be more efficient. The path to efficient selectors starts by understanding how selector matching works."

Je parlais il y a quelques jours de performance des sélecteurs CSS. Il y a eu quelques réactions et j'ai échoué dans mes explications : les différences de performance dont on parle ici sont probablement négligeables la plupart du temps. Hors commentaires, certains m'ont rappelé que la documentation de Mozilla concerne d'ailleurs au départ les interfaces XUL avec de gros documents XML complexes agrémentés de très grosses feuilles de style.

La directive Cache-Control est une vrai mine d'or pour la gestion du cache, au risque même de faire un peu fourre-tout. Aujourd'hui je m'intéresse surtout aux notions de document public et de document privé.

Je viens de commenter là bas pour dire que ça allait ralentir toutes les manipulations DOM après. Donc oui tu gagnes en "read", mais tu perds énormément en "write". J'avais fait un testcase pour Sizzle à l'époque de sa sortie et ils ont désactivé les DOMNodeInserted après ça. Du coup, je pense qu'on doit retirer ce lien de cette liste.

Ou garder le lien dans la liste, avec ton commentaire pour expliquer le problème, ça permet de savoir que c'est une fausse bonne idée.

"Sitespeed.io is an open source tool that helps you analyze and optimize your website speed and performance based on performance best practices. It will collect data from multiple pages on your website (crawling from a start point), analyze the pages using performance best practices rules, and output the result as HTML-files or JUnit XML. You can see real life examples of analyzed sites here." Possibilité d'intégrer cet outil dans une plate-forme d'intégration continue (jenkins) : http://sitespeed.io/documentation/#junit

Before we start, I'd like to mention that most (if not all) of these notes apply best to large, complex applications. Documents that have thousands of elements and that are highly interactive will benefit the most. In my case, I reduced page load time by ~650ms (~500ms (!)

Quelques bons conseils (les mêmes que d'hab) sur l'écriture universelle des CSS. Pas trop d'accord en revanche sur les raisons de ne pas utiliser les sélecteurs sur attribut - juste pour des raisons de compatibilité.

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.