Really, the first concrete piece of advice is to strip whitespace and comments from HTML? That's like trying to save gas in your car by emptying out the glove compartment.
There are some good nuggets in here though - the image/table size is a good one, and it drives me crazy when pages thrash their layout as images load.
But if you want to make your site faster, start with http://stevesouders.com/hpws/rules.php. (Some of those techniques may become obsolete with HTTP/2, but that's a ways off yet from being widespread enough to matter too much).
Looks like most of the content for those has been condensed at https://developer.yahoo.com/performance/rules.html. Or if you Google the title you can find the original article (with a new URL on Yahoo).
I'm absolutely shocked that Yahoo reformatted their blog URLs, didn't set up redirects, and broke old links. Shocked.
These tips are well and good, but from my perspective this type of article doesn't address the whole problem.
It seems to me that an overwhelming problem is not developers building inefficient web pages, it is designers, producers, and marketers demanding we build inefficient web pages. No matter how hard we try to convince such that their requirements are generally not a good idea, they still keep pushing the same stuff.
We need a series of these type of articles intended for non-developers to explain why this efficiency train of thought is important. To stop this nonsense of "developers trying to impose upon the artistic expression of designers" crap.
Personally, I just would like designers to stop designing web pages as if they were magazine layouts and actually design web pages.
Also I think most of the rules might drop out with having in mind the scalability problem. If you do reduce CSS, HTML files to the very limit you might have a hard time later when you try to implement another feature.
Same applies for JS which is getting more and more complex. Sure you can easily write a single page with vanilla script and even inline it to the HTML, but if you try to support IE it looks like you need to at least include either a library or a more complex JS code.
So anyway all those tips are super overthought. The best ( hardest ) coding practice is taking a professional approach and decide where is the boundary between spaghetti code and performance benefit.
- image sprites are a terrible hack that adds a lot of complexity and maintenance effort to pages (though effective for loading/processing times)
- the best feature of HTML tables is still the automatic (optimal) sizing of columns when the content can vary, so fixed column widths are not possible where tables are most useful
Some advice they forgot:
- use a good caching reverse proxy (Varnish)
- don't litter your pages with ads and tracking pixels, they incur a huge slowdown usually
- don't use cookies if possible, at least not on the domains/paths all your static content is loaded from
- don't use loaded web fonts (except maybe icon fonts instead of inline images)
- don't use huge JS libraries if you don't need but a few features
- don't rely on JS libraries to lay out your page, having JS post-process your page after loading just so it looks as intended is a huge (visible) slowdown
Regarding image sprites, if you're using a CSS pre-processor, like Sass (with Compass), then auto-generating sprite images and associated classes is trivial and adds little to no complexity or maintenance.
Perhaps most of this is accurate, but the number one issue I see with webpages, almost universally, is the loading of innumerable javascripts, especially ones hosted offsite. As a no script user, I shouldn't have to allow random js from other domains I don't know or trust just to see your page like you intended. Most of the time if I see more than 2/3 loading I just close it out and consider it not worth the trouble.
By reducing the number of files that are referenced within a web page, you reduce the time required for these requests to be sent, and for their responses to be received.
Aren't these exact opposites of each other? I suppose which direction to take depends on the bottleneck - if request latency is high, it might be better to put everything inline, but if the bottleneck is parsing then separating things into external files could have the advantage.
Putting CSS and JS into external files increases number of files, but decreases page size. (win for page size) External files can be cached. (win for page load times) Therefore, navigating to different pages that reference the cached external files shortens load times.
The warning is don't go overboard. Separate them, but no more than necessary.
Only to a degree, and then it starts making things worse. If your browser has to parse 20MB of CSS and JS (99.9% of which is not needed) to load a simple web page, it will be much slower than including only the necessary includes.
Yup. Once you have harder problems, you need harder solutions and you'll want to create a layered build with one cacheable file for common things used everywhere and then one separate file for each page's specific things. RequireJS and other front-end build tools are good at this: http://requirejs.org/docs/1.0/docs/faq-optimization.html
I've found I get the biggest wins from tools such as InstantClick (http://instantclick.io/), although of course that doesn't improve the initial page-load speed at all (and should slow it down marginally.).
Most of the advice I've seen elsewhere like YSlow and Google Page Speed, so it's pretty common and available advice. I think most people just don't do anything with it on their own sites.
Isn't it strange that in nearly every other optimization topic the first advice is: measure it first
Yesterday my boss asked if our website feels especially sluggish to me too. And I realized that I don't have good hard data to go by. What are the best practices to profile and monitor perceived load times?
Chrome dev tools now have an emulation mode which makes it easy to watch and measure how your page loads on different connections. Watch that on a slow connection and you can usually see the content loaded and Dom ready events as well as the progressive loading of images, fonts, js etc. Depending on how your page is structured, you will want to pick the event that best matches when the page looks usable.
There are lots of tools for then getting what that event time is for your users. Google analytics and new relic's new browser features make this easy and writing your own code isn't hard. As usual, look at the numbers by percentile and not just mean.
Use real browsers - both with artificial testing environments like webpagetest.org and Real User Monitoring to see what your users actually experience. I won't recommend a specific RUM tool as there are a bunch of options but they all use JavaScript to get basic information and the new Navigation Timing API to get more detailed values:
One word of caution: ignore tools like Google Analytics which are designed by the statistically ignorant. If a tool uses the mean or an average rather than a median or n-th percentile, you cannot trust it to make decisions because real-world timing data has staggering outliers – 99.999% of your users may load a resource in less than a second but the two clients which reported 2 hour load times will skew the average so much that you'll think you're seeing a problem which doesn't actually exist.
I wrote about an example of this in 2012 and despite the assurances of people who work on Google Analytics and, I'm told, internal lobbying by people at Google who do understand this (e.g. Ilya Grigorik), nothing has changed in the last two years:
(Yes, they do allow you to see the distribution but it hardly counts because it's a clumsy histogram to use and since you can't report on it, your boss is going to look at the averages which are displayed prominently everywhere else)
I had a good experience using Pingdom.com - its free and I feel more confident having page load measured from the live server instead of simulated locally.
> Page weight is by far the most important factor in page-load performance.
This is terrible advice, often how much the page weighs (whether it's 10kB or 500kB) has little to no effect on load time, the number of requests is often way more impactful.
I generally agree but the number of requests is also too simple a rule. You really need to look at the number of blocking requests and what they block – e.g. loading a large image might seem low-impact since browsers have progressive decoding but you often see cases where the load order goes like this:
1. HTML starts trickling in
2. Browser scans for resources and starts opening connections for stylesheets (great, since they block rendering) and other inline resources
3. Since you followed everyone's advice and put your scripts at the bottom of the page, you now have 2MB of images saturating all of the available server connections so the JavaScript is waiting for a connection to complete and, of course, there's no way to progressively render a script
4. The relatively small JS loader / jQuery / etc. eventually loading triggers a whole new set of requests which are now at the end of the queue behind all of the CSS and content references for images, fonts, etc.
HTTP/2.0 will help significantly with all of this but in the meantime various bundling hacks used to lower requests counts and the lack of dependencies as a first class concept mean that you tend to see a lot of unintended load delays unless someone has carefully profiled their page loading behaviour.
I appreciate the benchmark, but "worthless" was your conclusion.
What your benchmark shows is that gzipped pages may be as much as 20% larger than minified + gzipped pages. Even larger pages typically were 3-5% larger.
I'd save murder for something more valuable. Changing your load time from 10s to 9.5s is hardly a noticeable improvement. I've optimized many a web page and extra whitespace in HTML has never once been the bottleneck. It's bandied about because it is a magic button that takes no analysis or hard decisions to implement, not that it is effective.
Sometimes you've gotten all the low-hanging fruit, and the bottleneck is something that you can't easily avoid. Then you're left finding a bunch of "worthless optimizations" that hopefully add up to an improvement.
I would agree that it's not the most important optimization early on, it's probably not even worth doing at all unless either it's trivial or your project is big, stable, and consuming tons of resources. But that's not the same as worthless.
It's also the case that mature tools (from your compiler, to SQLite, to your browser) chase "worthless optimizations" all the time. Front-end development is in such a state of flux that we don't expect our tools to do that. But eventually we will.
Would be nice to hear tips specific for mobile browsers. My site is going to be accessed mostly from mobile browsers (over edge/2G connection most of the times). No images only data. This is what I have decided to follow:
1. Make it ajax as much as possible to avoid sending requests for each operation. Try to keep everything in one page dashboard.
2. Keep the page/services sizes under 1500 bytes (Ethernet)
As a user who sometimes has terrible coverage and 2G I would suggest not using AJAX so much. If you do, make sure it is cached by the browser. It is incredibly frustrating to have zero indication if there is some AJAX loading going on in the background or not. The browsers don't show and animated indicators that websites show, well, like to animate for eternity. And if loading stopped or you decide to reload the page in the hope that this time it will load better, sites usually fetch the whole shebang again.
So my recommendations: Make sure your site is split into nice, cachable chunks (css, images, js, etc). If you can, avoid JS. Avoid loading content invisibly to the user in the background.
How does using ajax avoid requests? Partially updating a page usually results in many (but smaller) request. Unless you have good framework, updating multiple parts in one request can get complicated.
There are some good nuggets in here though - the image/table size is a good one, and it drives me crazy when pages thrash their layout as images load.
But if you want to make your site faster, start with http://stevesouders.com/hpws/rules.php. (Some of those techniques may become obsolete with HTTP/2, but that's a ways off yet from being widespread enough to matter too much).