Tips for authoring fast-loading HTML pages
developer.mozilla.org
developer.mozilla.org
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.
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.
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
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.
This is how we did it: http://retromocha.com/learn/how-we-made-our-website-fast/
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.
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?
https://developer.mozilla.org/en-US/docs/Navigation_timing
… and the even newer Resource Timing API:
http://www.stevesouders.com/blog/2014/08/21/resource-timing-...
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:
http://chris.improbable.org/2012/5/18/google-analytics-decep...
(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)
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.
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.
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.
Is leading white space really a big slowdown? I wont know if its worth it ubt I invest the time into implementing it.
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.
Sometimes you'd kill for a 3-5% 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.
"Worthless" is just too blunt of a verdict.
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)
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.