/* * By: Jacob Taylor * License: ISC * Twitter: @aranjedeath * Website: explodie.org * About: site optimization standards. * Version: 0.1.4, Apr 23rd 2014 */ lazyload all css what this really means is nothing at all, because nobody supports lazyload yet. Except: critical render path css. Any css that applies to what I can see above the fold on your site should be the second thing loaded (after the html, of course) if you have enough of a connection/rtt budget (somewhat explained later), you can break this into its own file, but do be careful about that. lazyload all js, unless defer is more appropriate (jquery + plugins, for eg) what this really means is async all js, because nobody supports lazyload yet. if in the future somebody supports lazyload, it interacts with async, they're not synonyms. be careful, here be really subtle dragons. When used together, scripts that only have async will be given prio over scripts with async and lazyload. lazyload hinges on "non-contested network resources" being available. minify all js,css,img externalize all images (no data: uri shit) if you've got too many small images, make a sprite. combine all css if not, use something with multiplexing (spdy, http2) if any individual external resource is over 50kb, consider why that's the case and if it can be made smaller. For images, use srcset. Chrome 34+ supports srcset. scale all elements in css using relative sizes, including the base size this is accomplished by setting html to 100% size and setting all sizes using either %'s of that, em's, or rem's as appropriate. re: "as appropriate":: rem is always appropriate simplify all css. If you set h2 to a rem size, never again should you set or override that style in any code coming from origins you control. If you do, the design isn't clean enough and the visual hierarchy not sufficiently refined. resources such as javascript and css that you host should be protocol relative if referenced in the , and should specify protocol (http: or https:, prefer latter) if in the . balance security with performance (which equates to usability). Know that any and all externally hosted resources are both security and privacy risks to your users. optimize for the fewest number of requests possible, even if those requests must be slightly larger to achieve. Don't forget about losses due to clients who slow start and don't do rfc 6928. Presently (afaik) only linux/3.2+ does 6928. After that, start looking at what you can do about minimizing the packet count of these requests. Mobile users will thank you. For mobile, opening a connection is hell. Remember to amortize those openings. A connection can be held open by the gateway, but it still takes a long time (aka many rtt's, most of which are inside the cell network) to launch a new one. If your default keepalive is under 30 seconds, I will cut you. Connection setup/teardown is the most expensive part of that operation. It also fucks mobile users. Don't push, only pull, and only on network device state change. Anything else wastes battery. (Don't be THAT ASSHOLE rule). push notifications can be cool, as long as they are batched from your end and have a minimum-time-between-pushes. also if you're talking about spdy server push, this can also be wonderful but it should only be done with the utmost care for mobile (aka don't do it). Unless a mobile client is in SF/NY on 4g lte-advanced or something, their client will spend half its rtt inside the cell network alone. If you absolutely must have everything in its own file, shard domains with a maximum of 3 total (including primary origin), or use spdy/3.1 + same cert for all addresses. I'm not kidding. 3. Total. Ever. If google cdn is one of those addresses, you have two more to use including your site's main address. Analytics provider? Your address budget is up and you get no additional domains included in your page. End of story. Also, never use a public cdn. For every third party service (like a cdn) that you use, you increase the points of failure by 1. Also, you're fucking your users by giving free analytics to whomever you've contracted with. If you /haven't/ contracted with them, how is it that the service is free? Analytics. As for more pragmatic reasons, it doesn't actually help your load time by much, and if a large % of your clients are on mobile it can actually be detrimental. best to follow css/js concatenation/combination rules elsewhere in this doc. I'd just like to indicate here that Ilya Grigorik who is probably much smarter than me and works on this stuff all day says the exact opposite, that CDN'ing common resources (such as jquery) is still an improvement for mobile users. See his argument: http://www.igvita.com/2014/03/26/why-is-my-cdn-slow-for-mobile-clients/ in the put meta information about the connection absolutely first (http-equiv, charset, viewport) followed by critical rendering path css (if all css is in one file, it goes here) then link rel=dns-prefetch/prerender/etc then rel=subresource and then js (in order of functionality importance) then less critical css the title finally, meta info such as name/property, and link rel=author/publisher/profile/etc, twitter card markup, facebook opengraph shit, etc dicks. don't write images into the page with javascript. unless you're writing what constitutes a desktop application in html/css/js, don't cause a style recalc. If you do, you're an asshole. future: any images you know will probably be written into the page with js, mark with link rel=subresource in or push via spdy/3. this is awesome but nobody supports rel=subresource yet. always serve multiple versions of the same