
Tips for authoring fast-loading HTML pages - mparramon
https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Tips_for_authoring_fast-loading_HTML_pages
======
strommen
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](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).

~~~
e40
All the blog post links "about this rule" point to developer.yahoo.com are are
all bad and get redirected to www.yahoo.com. :(

~~~
strommen
Nice.

Looks like most of the content for those has been condensed at
[https://developer.yahoo.com/performance/rules.html](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.

------
talmand
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.

~~~
protonfish
Honestly you can develop the fastest page ever but all it takes is adding
tracking and advertising code and it will bog down to uselessness.

------
lazyjones
Some good advice, some bad:

\- 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

~~~
mradmin
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.

------
arca_vorago
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.

------
userbinator
_moving inline script and CSS into external files_

 _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.

~~~
asolove
Having js and ces in single, cacheable external files will speed up later page
loads on the site.

~~~
protonfish
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.

~~~
asolove
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](http://requirejs.org/docs/1.0/docs/faq-optimization.html)

------
lamby
I've found I get the biggest wins from tools such as InstantClick
([http://instantclick.io/](http://instantclick.io/)), although of course that
doesn't improve the initial page-load speed at all (and should slow it down
marginally.).

~~~
1123581321
That's an approach I've considered before. Do you use InstantClick or another
tool?

~~~
lamby
I use InstantClick on all new sites now. There's a bit of a cost integrating
third-party javascripts but the wins are fantastic.

------
programminggeek
All of these are good tips. After implementing most or all of these our site
was a lot faster.

This is how we did it: [http://retromocha.com/learn/how-we-made-our-website-
fast/](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.

------
krisoft
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?

~~~
acdha
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:

[https://developer.mozilla.org/en-
US/docs/Navigation_timing](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-...](http://www.stevesouders.com/blog/2014/08/21/resource-timing-
practical-tips/)

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...](http://chris.improbable.org/2012/5/18/google-analytics-deceptive-
site-speed-report/)

(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)

------
nightcracker
> 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.

~~~
acdha
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.

------
hayksaakian
Would be nice if there were some rough stats attached to these tips.

Is leading white space really a big slowdown? I wont know if its worth it ubt
I invest the time into implementing it.

~~~
austinpray
Actually just got done benchmarking this. The conclusion was that it is a
worthless optimization compared to just sending the client a gzipped webpage
without minifying first. [https://github.com/yeoman/generator-gulp-
webapp/issues/215#i...](https://github.com/yeoman/generator-gulp-
webapp/issues/215#issuecomment-61394148)

~~~
hyperpape
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.

Sometimes you'd kill for a 3-5% improvement.

~~~
protonfish
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.

~~~
hyperpape
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.

"Worthless" is just too blunt of a verdict.

------
zerop
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)

~~~
Sprint
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.

------
logicallee
Just keep the page under 1500 bytes, which is the size of an ethernet packet

