Why?<p>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.<p>At which point he accused me of being another product shill (not a real software engineer) and shut down the debate.<p>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.<p>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.<p>I'm guessing the answers are: too much, never, no and no.<p>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.
For anybody not versed in web design, here's a link to the mildly ungooglable Lighthouse tool: <a href="https://developers.google.com/web/tools/lighthouse/" rel="nofollow">https://developers.google.com/web/tools/lighthouse/</a><p>(If you search for "lighthouse benchmark", "lighthouse speed test", or "lighthouse app" you get nothing. "lighthouse tool" and "lighthouse web" works.)
I think eventually we should start distinguishing between a <i>website</i> 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.<p>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.<p>The latter requires a lot more work.
5. Don’t server-render HTML<p>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.<p>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.
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.
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.<p>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.
I have already fathered a child with Firebase and quite enjoyed myself<p>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.<p>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.<p>Pure gold. :D
Pretty sure I have the fastest site in the world: <a href="https://www.futureclaw.com" rel="nofollow">https://www.futureclaw.com</a><p>Speed test: <a href="https://tools.pingdom.com/#!/FMRYc/http://www.futureclaw.com" rel="nofollow">https://tools.pingdom.com/#!/FMRYc/http://www.futureclaw.com</a><p>Average page generation time from the database is 2-3ms & cached pages generate in 300 microseconds. Also, this includes GZip.<p>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.<p>I just checked and it's faster than Hacker News: <a href="http://tools.pingdom.com/fpt/bHrP9i/http://news.ycombinator.com" rel="nofollow">http://tools.pingdom.com/fpt/bHrP9i/http://news.ycombinator....</a>
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 <i>not</i> read the article.<p>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.<p>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 <i>do</i> apply to more involved websites, but with much lower efficacy. Anyways, funny article.
> 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.<p>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:<p>- The <i>fastest</i> desktop system they rated[1], which happens to have an i7 CPU just as the author is using, is rated 9206.<p>- Google Pixel XL smartphone[2] gets a score of 8153.<p>In other words, the Pixel comes out as having 89% of the performance of the fastest desktop system.<p>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).<p>[0] PassMark Software Pty Ltd. Their PassMark rating is a composite of tests for CPU, disk, 2D & 3D graphics, and memory.<p>[1] <a href="http://www.passmark.com/baselines/top.html" rel="nofollow">http://www.passmark.com/baselines/top.html</a><p>[2] <a href="http://www.androidbenchmark.net/phone.php?phone=Google+Pixel+XL" rel="nofollow">http://www.androidbenchmark.net/phone.php?phone=Google+Pixel...</a>
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.<p>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.<p>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.
Looks like website performance optimization is becoming a high-valued and high-paid skill for the next 10 years at least.<p>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.
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.
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).
don't ship too much synchronous code at your entry points.<p>go below 200kb at your entry points, so people see something fast.<p>now they have something to do and you can ship the rest of your app asynchronously in the background.<p>I think this is the most important. Even more than build time rendering or something. The 80% yield with 20% effort.
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).
"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."<p>Worth reading just for this gem.
really impressive programmer went thru and made this page <a href="https://knowitall-9a92e.firebaseapp.com" rel="nofollow">https://knowitall-9a92e.firebaseapp.com</a> super fast for both mobile and desktop and found a lot of interesting benchmarks in the process.
FTA:<p>> Hopefully that opened quickly and I have established credibility. If that sounds immodest it’s because I’m awesome.<p>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.<p>Eat dog food. Not preach it. Consistency, not showing off a one-wheel skid on a scooter.