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.
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.
"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.
"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 :)
ça à l'air bien sympa, j'ai testé sur leur site ça fonctionne bien et avec plusieurs providers.
LE truc intéressant c'est que comme c'est du "Lazy", ça peut apparaître au moment ou tu scroll la page et donc attirer l'oeil plus rapidement... ?
Par contre, le nombre d'afichages de publicités avec cette technique doit baisser énormément car une pub en bas du site ne serait pas affichée si non visible. Comment justifier cette baisse auprès des commerciaux etc?
Est-ce qu'un affichage en moins peut impliquer moins d'argent pour le site en question ?
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...