9 ms·

Things I learnt making a fast website

385 points by inian 10y ago

throwaway2016a 10y ago
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.
- mozumder 10y ago
  We really need a binary version of HTML, CSS, and JSON. (WebAssembly would be the binary version of JS)
  - rbritton 10y ago
    There's MessagePack[0], which serves basically the same purpose a binary version of JSON would. It came up recently in an engineering article Uber posted. [0]: http://msgpack.org/ http://msgpack.org/
    - vog 10y ago
      According to their website, there is only one JavaScript implementation, this that one seems to be for server side (NodeJS), not client side (browser). And even if we had that, we would need some consensus (read: coding rules) on how to exactly encode HTML/CSS/etc. in MessagePack. Looks doable for me, but there is a long way do go.
- kelvin0 10y ago
  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 10y ago
    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.
- niftich 10y ago
  There are less verbose, binary formats for storing XML information models -- like Fast Infoset [1], and formats listed on Wikipedia under 'Binary XML' [2]. HTML5 can optionally be written in a mostly-XML-conforming syntax [3]. [1] https://en.wikipedia.org/wiki/Fast_Infoset https://en.wikipedia.org/wiki/Fast_Infoset [2] https://en.wikipedia.org/wiki/Binary_XML https://en.wikipedia.org/wiki/Binary_XML [3] https://html.spec.whatwg.org/#xhtml https://html.spec.whatwg.org/#xhtml
- dom0 10y ago
  The point is that the JSON parser runs in the browser - as native code - so it's rather difficult to match it's performance with some other parser in JS, even if that one has an easier job to do.
  - bzbarsky 10y ago
    It may be hard to match the performance of the parsing per se. But the typical data flow with JSON goes like this: 1) Get a string. 2) JSON.parse it into an object graph. 3) Use that object graph to build the data structure you really care about (e.g. a DOM). If you parse yourself you may be able to cut out the middleman object graph. That might be worthwhile; needs measuring.
andrewfromx 10y ago
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.
hueving 10y ago
Took 4 seconds to load on my phone. About 2 seconds slower than hacker news.
- aibottle 10y ago
  If you want to see a quick site: blog.fefe.de
mozumder 10y ago
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.com http://tools.pingdom.com/fpt/bHrP9i/http://news.ycombinator....
- deleted 10y ago
  [deleted]
- girzel 10y ago
  Blog about it!
  - mozumder 10y ago
    Will do in Spring, as it becomes more feature complete. (search, articles, user blogging, etc..) All compounded by the fact that I also do the content for the site. Anyone want to turn this into a platform product?
- ilarum 10y ago
  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.jpg https://farm9.staticflickr.com/8380/29778359335_f59e0b4fcb_k... [2] https://bigdemosyncopt.dexecure.net/https://farm9.staticflickr.com/8380/29778359335_f59e0b4fcb_k.jpg https://bigdemosyncopt.dexecure.net/https://farm9.staticflic... Note that [2] varies in size and format depending on your user agent and it becomes ~70KB when viewed from a chrome mobile device.
quizotic 10y ago
Hilarious :-) I don't care whether the lessons are useful or not. I just want to be able to write like this.
throwaway2016a 10y ago
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 10y ago
  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.html https://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20... 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-time-impact-engagement/ https://blog.optimizely.com/2016/07/13/how-does-page-load-ti... 100ms cost Amazon 1% of sales: http://blog.gigaspaces.com/amazon-found-every-100ms-of-latency-cost-them-1-in-sales/ http://blog.gigaspaces.com/amazon-found-every-100ms-of-laten... Akamai has a number of claims: 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 https://www.akamai.com/us/en/about/news/press/2009-press/aka... 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.
computator 10y ago
> 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+XL http://www.androidbenchmark.net/phone.php?phone=Google+Pixel...
- inian 10y ago
  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-traditional-javascript-benchmarks/#comment-3058874998 http://benediktmeurer.de/2016/12/16/the-truth-about-traditio...
  - deleted 10y ago
    [deleted]
- pitaj 10y ago
  That metric is likely multi-core performance. Contrarily, since JS is single-threaded (usually), the very weak single cores in a mobile processor don't do as well.
ing33k 10y ago
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.
guitarbill 10y ago
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.)
zhte415 10y ago
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.
Dunedan 10y ago
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 10y ago
  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.
PaulRobinson 10y ago
I bet you're a lot of fun at parties.
- Elrac 10y ago
  Context, dude! People go to parties to enjoyably waste time with and around other people. People read tech blogs to learn stuff to help them do better work. The author is mistaking his tech blog for a party. He can do that if he wants, it's his blog after all. But I can easily sympathize with the grandparent's annoyance at having his attention abused to parse an extrovert's lame stand-up comedic fluff.
- dang 10y ago
  Personal attacks are not allowed on Hacker News. We detached this subthread from https://news.ycombinator.com/item?id=13249148 https://news.ycombinator.com/item?id=13249148 and marked it off-topic.
  - PaulRobinson 10y ago
    It wasn't a personal attack, but OK.
    - dang 10y ago
      I believe you that you didn't intend it that way, but it is a cliché of personal swipes, so absent extra information one can hardly read it otherwise.
ComodoHacker 10y ago
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 10y ago
  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.
deleted 10y ago
[deleted]
jayajay 10y ago
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.
Maarten88 10y ago
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__ 10y ago
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.
the_duke 10y ago
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
olavgg 10y ago
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.
adrianN 10y ago
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 10y ago
  I thought we had this already; website vs webapp
  - Klathmon 10y ago
    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.
- RandomInteger4 10y ago
  Does it though? Does the latter actually take a "lot" more work to optimize? That sounds too much like a convenient excuse.
bikamonki 10y ago
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.
tomohawk 10y ago
"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.
edem 10y ago
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 10y ago
  Hmm interesting. Yeah I just had that same issue. Mobile was unresponsive for about 3 seconds till everything loaded.
rogermedia 10y ago
Very cool thanks for sharing this.
greenspot 10y ago
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.

385 points by inian 10y ago

throwaway2016a 10y ago

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.

mozumder 10y ago
We really need a binary version of HTML, CSS, and JSON. (WebAssembly would be the binary version of JS)
- rbritton 10y ago
  There's MessagePack[0], which serves basically the same purpose a binary version of JSON would. It came up recently in an engineering article Uber posted. [0]: http://msgpack.org/ http://msgpack.org/
  - vog 10y ago
    According to their website, there is only one JavaScript implementation, this that one seems to be for server side (NodeJS), not client side (browser). And even if we had that, we would need some consensus (read: coding rules) on how to exactly encode HTML/CSS/etc. in MessagePack. Looks doable for me, but there is a long way do go.
kelvin0 10y ago
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 10y ago
  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.
niftich 10y ago
There are less verbose, binary formats for storing XML information models -- like Fast Infoset [1], and formats listed on Wikipedia under 'Binary XML' [2]. HTML5 can optionally be written in a mostly-XML-conforming syntax [3]. [1] https://en.wikipedia.org/wiki/Fast_Infoset https://en.wikipedia.org/wiki/Fast_Infoset [2] https://en.wikipedia.org/wiki/Binary_XML https://en.wikipedia.org/wiki/Binary_XML [3] https://html.spec.whatwg.org/#xhtml https://html.spec.whatwg.org/#xhtml
dom0 10y ago
The point is that the JSON parser runs in the browser - as native code - so it's rather difficult to match it's performance with some other parser in JS, even if that one has an easier job to do.
- bzbarsky 10y ago
  It may be hard to match the performance of the parsing per se. But the typical data flow with JSON goes like this: 1) Get a string. 2) JSON.parse it into an object graph. 3) Use that object graph to build the data structure you really care about (e.g. a DOM). If you parse yourself you may be able to cut out the middleman object graph. That might be worthwhile; needs measuring.

andrewfromx 10y ago

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.

hueving 10y ago

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

aibottle 10y ago
If you want to see a quick site: blog.fefe.de

mozumder 10y ago

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.com http://tools.pingdom.com/fpt/bHrP9i/http://news.ycombinator....

deleted 10y ago
[deleted]
girzel 10y ago
Blog about it!
- mozumder 10y ago
  Will do in Spring, as it becomes more feature complete. (search, articles, user blogging, etc..) All compounded by the fact that I also do the content for the site. Anyone want to turn this into a platform product?
ilarum 10y ago
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.jpg https://farm9.staticflickr.com/8380/29778359335_f59e0b4fcb_k... [2] https://bigdemosyncopt.dexecure.net/https://farm9.staticflickr.com/8380/29778359335_f59e0b4fcb_k.jpg https://bigdemosyncopt.dexecure.net/https://farm9.staticflic... Note that [2] varies in size and format depending on your user agent and it becomes ~70KB when viewed from a chrome mobile device.

quizotic 10y ago

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

throwaway2016a 10y ago

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 10y ago
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.html https://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20... 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-time-impact-engagement/ https://blog.optimizely.com/2016/07/13/how-does-page-load-ti... 100ms cost Amazon 1% of sales: http://blog.gigaspaces.com/amazon-found-every-100ms-of-latency-cost-them-1-in-sales/ http://blog.gigaspaces.com/amazon-found-every-100ms-of-laten... Akamai has a number of claims: 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 https://www.akamai.com/us/en/about/news/press/2009-press/aka... 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.

computator 10y ago

> 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+XL http://www.androidbenchmark.net/phone.php?phone=Google+Pixel...

inian 10y ago
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-traditional-javascript-benchmarks/#comment-3058874998 http://benediktmeurer.de/2016/12/16/the-truth-about-traditio...
- deleted 10y ago
  [deleted]
pitaj 10y ago
That metric is likely multi-core performance. Contrarily, since JS is single-threaded (usually), the very weak single cores in a mobile processor don't do as well.

ing33k 10y ago

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.

guitarbill 10y ago

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

zhte415 10y ago

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.

Dunedan 10y ago

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 10y ago
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.

PaulRobinson 10y ago

I bet you're a lot of fun at parties.

Elrac 10y ago
Context, dude! People go to parties to enjoyably waste time with and around other people. People read tech blogs to learn stuff to help them do better work. The author is mistaking his tech blog for a party. He can do that if he wants, it's his blog after all. But I can easily sympathize with the grandparent's annoyance at having his attention abused to parse an extrovert's lame stand-up comedic fluff.
dang 10y ago
Personal attacks are not allowed on Hacker News. We detached this subthread from https://news.ycombinator.com/item?id=13249148 https://news.ycombinator.com/item?id=13249148 and marked it off-topic.
- PaulRobinson 10y ago
  It wasn't a personal attack, but OK.
  - dang 10y ago
    I believe you that you didn't intend it that way, but it is a cliché of personal swipes, so absent extra information one can hardly read it otherwise.

ComodoHacker 10y ago

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 10y ago
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.

deleted 10y ago

[deleted]

jayajay 10y ago

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.

Maarten88 10y ago

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__ 10y ago

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.

the_duke 10y ago

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

olavgg 10y ago

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.

adrianN 10y ago

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 10y ago
I thought we had this already; website vs webapp
- Klathmon 10y ago
  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.
RandomInteger4 10y ago
Does it though? Does the latter actually take a "lot" more work to optimize? That sounds too much like a convenient excuse.

bikamonki 10y ago

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.

tomohawk 10y ago

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

edem 10y ago

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 10y ago
Hmm interesting. Yeah I just had that same issue. Mobile was unresponsive for about 3 seconds till everything loaded.

rogermedia 10y ago

Very cool thanks for sharing this.

greenspot 10y ago

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.