
Things I learnt making a fast website - inian
https://hackernoon.com/10-things-i-learned-making-the-fastest-site-in-the-world-18a0e1cdf4a7#.1y8odu3s7
======
throwaway2016a
Why?

I was recently talking at a conference and got in an argument with another
speaker (not publicly) because he had a technique to improve API response
time. Thing is, said technique would delay the time to market on the product
and make the code needlessly complicated to maintain. And I pointed out, that
it is probably better for the bottom line of most companies to do the way that
is slightly slower but easier to maintain and faster to get to market.

At which point he accused me of being another product shill (not a real
software engineer) and shut down the debate.

Thing is, I have a computer science degree and take software engineering very
seriously. I just also understand that companies have a bottom like and
sometimes good is good enough.

So I ask, this "world's fastest web site"... how much did it cost to develop
in time/money? How long is the return on investment? And is it going to be
more successful because it is faster? Is it maintainable.

I'm guessing the answers are: too much, never, no and no.

With that said, I fully appreciate making thing fast as a challenge. If his
goal was to challenge himself like some sort of game where beating the
benchmarks is the only way to win. Then kudos. I love doing stuff just to show
I can just as much as the next person.

~~~
Veratyr
In this case you're probably right but in general, latency can make a __big
__impact on profit and revenue.

For example Marissa Mayer claimed (though this was in 2006) that a 500ms delay
directly caused a 20% drop in traffic and revenue:
[https://glinden.blogspot.com/2006/11/marissa-mayer-at-
web-20...](https://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20.html)

Optimizely found that for The Telegraph, adding a 4s delay led to a 10% drop
in pageviews: [https://blog.optimizely.com/2016/07/13/how-does-page-load-
ti...](https://blog.optimizely.com/2016/07/13/how-does-page-load-time-impact-
engagement/)

100ms cost Amazon 1% of sales: [http://blog.gigaspaces.com/amazon-found-
every-100ms-of-laten...](http://blog.gigaspaces.com/amazon-found-every-100ms-
of-latency-cost-them-1-in-sales/)

Akamai has a number of claims:
[https://www.akamai.com/us/en/about/news/press/2009-press/aka...](https://www.akamai.com/us/en/about/news/press/2009-press/akamai-
reveals-2-seconds-as-the-new-threshold-of-acceptability-for-ecommerce-web-
page-response-times.jsp)

Of course the impact of latency is going to depend on your particular
circumstances but there are certainly circumstances where it __can __make a
big impact.

~~~
chrismorgan
Google: 2006.

Amazon: 2006.

Akamai: 2009.

At least the Optimizely result is from this year.

I _really_ want more evidence of the importance of performance in web systems
(to justify my hobby, if for no other reason), but things from ten years ago
just don’t cut it.

Can we please stop citing articles from ten years ago and cite some studies
that aren’t more than two years old?

Do people have more such studies?

(Also I’d be interested in more geographically diverse results. Figures like
“three seconds to abandonment” are _absurd_ when you’re in Australia or India
as I am. Most e-commerce sites—especially US/international ones—haven’t even
started _drawing_ at that point, even with the best Internet connectivity and
computer performance available, simply because of latency if the site is
hosted in the US only. I visited the US a couple of years ago and was amazed
at just how fast the Internet was, simply due to reduced latency.)

~~~
Veratyr
> I really want more evidence of the importance of performance in web systems
> (to justify my hobby, if for no other reason), but things from ten years ago
> just don’t cut it.

> Can we please stop citing articles from ten years ago and cite some studies
> that aren’t more than two years old?

Could you explain why? New data is good, sure but why should we disregard old
data? I think instead of asking for people to simply discard old data, you
should point out the issues you believe the data has so that they can be
addressed (with newer data if necessary).

Anyhow, from [https://riteproject.files.wordpress.com/2014/10/fact-
sheet.p...](https://riteproject.files.wordpress.com/2014/10/fact-sheet.pdf):

\- "In 2008 the Aberdeen Group found that a 1-second delay in page load time
costs 11% fewer page views, a 16% decrease in customer satisfaction, and a 7%
decrease in searches that result in new customers."

\- In 2009 Microsoft Bing found that introducing 500ms extra delay translated
to 1.2% less advertising revenue.

I also found a whitepaper from 2010 done by Gomez.com that shows how speed
impacts various metrics:
[https://github.com/JasonPaulGardner/po4ux/blob/master/InfoPa...](https://github.com/JasonPaulGardner/po4ux/blob/master/InfoPack/wp_why_web_performance_matters.pdf)

There's also an article from 2013 that's only loosely related but shows that
reducing TTFB latency can increase search result rankings:
[https://moz.com/blog/how-website-speed-actually-impacts-
sear...](https://moz.com/blog/how-website-speed-actually-impacts-search-
ranking)

> Also I’d be interested in more geographically diverse results.

I'd love these too, let me know if you find them.

~~~
martin-adams
I think citing data before the wide spread uptake on mobile is non-
representative of the modern use of the web.

~~~
addicted
But it's probably very reasonable to believe that people's expectations of a
faster response time has only risen since 10 years ago.

If I had to make a guess whether the same studies performed 10 years ago were
performed today, whether the drop in page views would increase or decrease
with slower response time, Id guess that today you'd have even fewer page
views than 10 years ago.

~~~
chrismorgan
I don’t believe it’s reasonable to assume that, having presented an
alternative view that I find plausible in other comments in this thread. I
_hope_ that people’s expectations have increased, but I don’t believe it’s a
reasonable _assumption_.

We need data.

~~~
cramforce
There is lots of recent data out there. The general trend is that those
findings from the mid 2000s hold even more true today. People are much more
sensitive to latency, while the problem has gotten harder due to last mile
flowing through congested air.
[https://www.doubleclickbygoogle.com/articles/mobile-speed-
ma...](https://www.doubleclickbygoogle.com/articles/mobile-speed-matters/)

------
guitarbill
For anybody not versed in web design, here's a link to the mildly ungooglable
Lighthouse tool:
[https://developers.google.com/web/tools/lighthouse/](https://developers.google.com/web/tools/lighthouse/)

(If you search for "lighthouse benchmark", "lighthouse speed test", or
"lighthouse app" you get nothing. "lighthouse tool" and "lighthouse web"
works.)

------
adrianN
I think eventually we should start distinguishing between a _website_ whose
main purpose it is to present some minimally interactive hypertext to the user
and an application that uses HTML as a GUI description language.

The former is trivial to make fast: just write it like it's 1999. You don't
really need a database or Javascript, just make sure that your images are not
huge and don't load too much stuff from other sites.

The latter requires a lot more work.

~~~
gareim
I thought we had this already; website vs webapp

~~~
Klathmon
IMO the former is a superset of the latter.

In other words, all webapps are websites, but not all websites are webapps.

I think having another term for the things which are only "sites" like blogs,
news articles, etc... Would be useful.

------
olavgg
5\. Don’t server-render HTML

This is exactly what I do and why the average render time for my e-commerce
site is less than 200ms. I use JS for minor DOM manipulations, everything else
is static.

The secret ingredient is using Varnish cache server that beats the pants off
everything else and that can fill a 10G pipe while still have plenty of
capacity left on a single cpu core.

------
Dunedan
He lost me somewhere during #3. Simply too much story telling around the facts
for my liking. I don't want to know that somebody recently got a tattoo and
stuff like that, when I click on a link about making fast websites.

~~~
thenomad
Counterpoint - I really enjoyed the style. It was entertainingly over-the-top
and chatty. I'd probably have given up on a very dry "just the facts" article
quicker, and I'm fairly sure I'll remember this one better because of the
stylistic touches.

------
throwaway2016a
As an old binary file hacker I can't help but to think that the performance
would also be improved by using a different format than Json that doesn't
require 75,000 lines to be parsed on load.

One drawback of formats like Json and XML is that they require reaching the
ending tag ( "}" or "]" usually for Json and </root> for XML ) before the file
can be considered parsed. A properly designed binary format can be used like a
database of sorts with very efficient reads.

~~~
kelvin0
Well instead of JSON you can use Google's Protocol buffers:
[https://developers.google.com/protocol-
buffers/](https://developers.google.com/protocol-buffers/)

Haven't used it myself, but worked with people on a project which did, and boy
does it fly compared to JSON!

~~~
madeofpalk
The last time I looked into it, pure JS implementations of profound (that runs
in the browser) were lacking and made destroyed much of the speed
impreovements.

------
the_duke
I have already fathered a child with Firebase and quite enjoyed myself

Our <scripts>, much like our feet, should be at the bottom of our <body>. Oh I
just realised that’s why they call it a footer! OMG and header too! Oh holy
crap, body as well! I’ve just blown my own mind.

Sometimes I think I’m too easily distracted. I was once told that my mind
doesn’t just wander, it runs around screaming in its underpants.

Pure gold. :D

------
mozumder
Pretty sure I have the fastest site in the world:
[https://www.futureclaw.com](https://www.futureclaw.com)

Speed test:
[https://tools.pingdom.com/#!/FMRYc/http://www.futureclaw.com](https://tools.pingdom.com/#!/FMRYc/http://www.futureclaw.com)

Average page generation time from the database is 2-3ms & cached pages
generate in 300 microseconds. Also, this includes GZip.

One day I'll write a blog post on it, but it's a Django app with a custom view
controller. I use prepared statements and chunked encoding & materialized
database views & all sorts of techniques I forgot that I need to write down. I
also gzip data before storing in Redis, so now my Redis cache is automatically
10x bigger.

I just checked and it's faster than Hacker News:
[http://tools.pingdom.com/fpt/bHrP9i/http://news.ycombinator....](http://tools.pingdom.com/fpt/bHrP9i/http://news.ycombinator.com)

~~~
ilarum
Impressive! You can do some more front-end stuff to improve the speed too,
like adding a good CDN and optimising your images. For example, [1] is ~790KB
which is great for viewing on a 5k iMac, but is probably unnecessary when
someone is viewing your website from a low powered phone on a slow 3G
connection. There are various tools like ImageOptim or Dexecure (which I work
on) to solve this issue. See [1] and [2] for a comparision on how this single
image can be compressed further.

[1]
[https://farm9.staticflickr.com/8380/29778359335_f59e0b4fcb_k...](https://farm9.staticflickr.com/8380/29778359335_f59e0b4fcb_k.jpg)
[2]
[https://bigdemosyncopt.dexecure.net/https://farm9.staticflic...](https://bigdemosyncopt.dexecure.net/https://farm9.staticflickr.com/8380/29778359335_f59e0b4fcb_k.jpg)

Note that [2] varies in size and format depending on your user agent and it
becomes ~70KB when viewed from a chrome mobile device.

~~~
mozumder
I do use PICTURE elements of various sizes, so it shouldn't be loading the
790kb version on a phone. Most likely either the 107kb version or the 220kb
version.

~~~
ilarum
Yep picture tag is really useful. I had tested on WPT and found a big image
[1] so I assumed you hadn't taken care of this yet.

[1] ~500KB image on 3G mobile device and load time of ~15.9s
([https://www.webpagetest.org/result/161224_M7_29Q/](https://www.webpagetest.org/result/161224_M7_29Q/))

------
jayajay
This is a well written article. I only read it because he initially presented
a link to his website, which ended up loading in 250ms. This begged the
question "why did it load so fast?" which in turn begged the entire article.
That presentation was genius, at some level. You can't _not_ read the article.

Reading this article is like witnessing a race between a bunch of lions, only
to see the winner unzip what appears to be a lion costume covering a cheetah.
The website appears as if it has the overhead of a DB, other networks, etc.,
when it actually doesn't.

Instead the article reads as "a few tricks to make really fast websites that
don't do anything". Of course, that's not entirely true, since the
optimizations mentioned _do_ apply to more involved websites, but with much
lower efficacy. Anyways, funny article.

------
quizotic
Hilarious :-) I don't care whether the lessons are useful or not. I just want
to be able to write like this.

------
hueving
Took 4 seconds to load on my phone. About 2 seconds slower than hacker news.

~~~
aibottle
If you want to see a quick site: blog.fefe.de

------
computator
> I have a big fat i7 CPU that I do most of my work on, and a brand new Pixel
> XL: the fastest phone in the world. What do you think the phone performance
> will be? It’s only 10%. If I slow my i7 down by ten times, it is the same
> speed as the $1,400 phone in front of me.

That's the most surprising thing I learned from the article. But I'm still a
little skeptical about this. One well-known CPU comparison site[0] gives the
following scores:

\- The _fastest_ desktop system they rated[1], which happens to have an i7 CPU
just as the author is using, is rated 9206.

\- Google Pixel XL smartphone[2] gets a score of 8153.

In other words, the Pixel comes out as having 89% of the performance of the
fastest desktop system.

I looked at some other metrics for comparing systems, and I'm not seeing how
smartphones are only 10% as fast as desktops -- neither in average cases nor
in extreme cases (fastest desktop vs fastest smartphone).

[0] PassMark Software Pty Ltd. Their PassMark rating is a composite of tests
for CPU, disk, 2D & 3D graphics, and memory.

[1]
[http://www.passmark.com/baselines/top.html](http://www.passmark.com/baselines/top.html)

[2]
[http://www.androidbenchmark.net/phone.php?phone=Google+Pixel...](http://www.androidbenchmark.net/phone.php?phone=Google+Pixel+XL)

~~~
inian
Take a look at this talk on why mobile devices are so much slower than desktop
devices ( they are indeed 10x slower in the traces I have looked at too) -
[https://youtu.be/4bZvq3nodf4](https://youtu.be/4bZvq3nodf4)

Also look at the speedometer benchmark
([http://browserbench.org/Speedometer/](http://browserbench.org/Speedometer/))
for a more realistic comparison of how slow your mobile device is compared to
your desktop when running real world apps. Here are some numbers from the
benchmark from some devices - [http://benediktmeurer.de/2016/12/16/the-truth-
about-traditio...](http://benediktmeurer.de/2016/12/16/the-truth-about-
traditional-javascript-benchmarks/#comment-3058874998)

------
greenspot
Slightly OT: I was once like the OP. I shaved off every bit of my pages,
almost no libs, CDN delivery, benchmarked and stress tested it with ab (Apache
Bench) after every commit (!), this thing was fast like a beast but tricky to
maintain. I did it for SEO reasons next to tons of other SEO techniques.

And you know what? My competitors still ranked all higher despite their
clumsy, megabyte heavy pages, loading for more than ten seconds. I know that
size and speed are not the only SEO signals but they seems to be not that
important as believed. Not sure though how AMP's importance will play in
future.

I still like his post, some of his tips are good (eg, start mobile first) and
some depend heavily on the use case (eg, don't render HTML on the server). As
other her in the thread say, does the ROI reflect the extra mile? If yes then
go for it.

------
ComodoHacker
Looks like website performance optimization is becoming a high-valued and
high-paid skill for the next 10 years at least.

10 years ago (and now, to a degree) it was database or C++ performance
optimization. You could specialize in these to earn above 10-15 percentile of
all the crowd.

~~~
Corrado
That's actually a good thought. In most companies you could probably
immediately make the site 10% faster by eliminating competing analytics. I've
personally seen sites with 4 different Google 'UA-XXXXX-Y' sections! The hard
part is talking to the various business owners and getting them to agree to
one central account.

------
bikamonki
Wow, it did load super fast on a slow phone and over 3g; however, once loaded,
and a couple of seconds after content skimming, interacting with the site was
clumsy. In particular, touching a category element was unresponsive. On a
second experiment I waited 10 seconds before interacting and it worked fine. I
guess there is some UI blocking JS scripiting going on right after load.

------
Maarten88
This was very funny to read and has several good tips that I'll use, but the
polyfilling tips need more testing: the site doesn't work at all on IE11 (on
Windows 10 and 8.1).

------
k__
don't ship too much synchronous code at your entry points.

go below 200kb at your entry points, so people see something fast.

now they have something to do and you can ship the rest of your app
asynchronously in the background.

I think this is the most important. Even more than build time rendering or
something. The 80% yield with 20% effort.

------
edem
There are two problems why I stopped reading this article: it is not fast
(took 20s to load compared to 3s on Hacker News. Note that I'm on a crappy
mobile network) and the site is non-responsive on mobile (I clicked things
which looked like clickable stuff and nothing happened).

~~~
RandomInteger4
Hmm interesting. Yeah I just had that same issue. Mobile was unresponsive for
about 3 seconds till everything loaded.

------
tomohawk
"Whenever I feel reluctant to throw out some work, I recall that life is
pointless, and nothing we do even exists if the power goes out. There’s a
handy hint for ya."

Worth reading just for this gem.

------
ing33k
This article took almot 45 seconds to load. Reason is I had the medium app
installed.

Just uninstalled that and it loads within 10 seconds.

------
rogermedia
Very cool thanks for sharing this.

------
andrewfromx
really impressive programmer went thru and made this page
[https://knowitall-9a92e.firebaseapp.com](https://knowitall-9a92e.firebaseapp.com)
super fast for both mobile and desktop and found a lot of interesting
benchmarks in the process.

------
zhte415
FTA:

> Hopefully that opened quickly and I have established credibility. If that
> sounds immodest it’s because I’m awesome.

Not by hosting via a blog on Medium, which while may seem nice, you're loading
a bunch of Medium links _in the header_ which causes the page to non-render
for anyone under a moderate-strict corporate firewall.

Eat dog food. Not preach it. Consistency, not showing off a one-wheel skid on
a scooter.

