Web Performance Profiling: Google.com (opens in new tab)

I find this to be the more fascinating part of Google's response time as well. Sending an optimized html file to a client in a matter of milliseconds is cool, but static pages should all load very quickly, so I don't see much surprise here - they've just optimized their front-end and done a good job of it.

Them being able to take your query, discover the data that answers your query, then optimize that data down to a little html snippet that fast is significantly more impressive to me.

There is a lecture from Jeff Dean about it: https://www.youtube.com/watch?v=modXC5IWTJI

It's from 2010, but the fundamentals probably haven't changed.

Sure, but that's a) impossible to dig into from the outside and b) less likely to yield useful information for the average developer who's trying to speed up a website.

It is handy, though, that search results are free to be very "eventually consistent" and easily distributed.

Not discounting the other magic, but exposing read-only data, close to the end user, where freshness isn't a huge concern does simplify things.

Something interesting I noticed is that the further you go down the pages, the slower it gets.

By their own metric, page 10+ take several times longer to arrive, and most search terms only have a few hundred results at best, even when showing billions of results, you only see the real number when you hit the last page. For example, for me, the word "the" only has 445 actual results (instead of 25 billions), and page 45 takes 2 seconds to complete, compared to 0.7 seconds for page 1.

It is an oversight, but equally for people like me it is helpful - I know how to optimise C++ (maybe not at google scale on my own!) but I've bullied compilers and measured pmc's, I haven't got a clue how to optimise frontends (beyond my usual solution of give up go and do something pleasurable)

yeah me too

Edit: I was too quick to judge your post. The article is indeed just about serving content, not about why their results are fast.

I think the point here is about how to make page faster about the same size.

I think every dev should try once in their life to write "fast" code. Learn Rust or C++ or whatever and write an echo server and try every trick you can find to make it fast. Run it a billion times for fun and just bask in it.

What's really wild is that the architects who envision and oversee implementation of systems that make these things possible earn a tiny fraction of what executives make.

They make 5x+ the next highest IC, sure. But if they worked half as much and BS'ed 100x as much they'd make 500x.

Personally, that makes me wonder a lot more than a clever combination of memcache and map-reduce.

I have a bot in Java that re-transmits messages between Slack/XMPP/Telegram.

Sending message in Slack is:

- sent to Slack servers

- bot looked up and data sent to it

- bot (on a server in DO) figures out what to do with the message (working with an MQ server running locally :))) )

- sends message back to a server (slack/xmpp/etc.)

- that message gets processed and pushed to the corresponding client

I could never properly measure the time between the original message and the translated message. It was always way way subsecond.

Everything we have now: networks, servers, code is very fast.

[1] Badly written bot here: https://github.com/dmitriid/tetrad

Just use “voidtools everything”. It allows you to search all files, even with regex patterns, and it returns realtime results.

If you want to search on file contents, use “agent ransack.

Outlook search is even worse, I doubt I would employ anyone with Outlook Search team on their cv.

Google search can be fast because thousands of computers complete your request at once, whereas the index of junk on your Windows box only has the one little computer to serve it. Same reason why operations in Gmail are so much faster than a local client like macOS Mail: the instantaneous compute power brought to bear on your request while it is running is thousands of times larger than one computer.

Classic HN. Snarky, condescending and nothing of substance. Reminds me why I visit HN less and less lately.

It is remarkably, painfully slow. Every letter entered into their search box (eg when searching a particular grocery store for a product) appears to be doing a full reload of results. You can feeeeel the horrible lag as you try to type and the site can't keep up with either your typed text or the results.

They should be doing a timed release on that. If you stop entering text for N ms, then go for a result. Otherwise they need to have cached results for a huge number of common combinations of letters, very frequently updated, for every store. It's a resource intensive thing to do well at their scale, for such a seemingly simple feature. If they are in fact caching all of those drop-down search results properly, something is very wrong on serving up the cached content.

And for the full results pages, when you try to load them for a given grocery store - the only answer I can guess for that is again mediocre caching. There usually isn't any other culprit other than that for such simple pages. In an effort to match current inventory, my guess is their caching isn't very good (constantly invalidated or rarely put into cache, so they're doing something that isn't very performant; I'd be astounded if they weren't doing some amount of caching on the results).

Early on they built a Rails app backed by Postgres [0] to store, these days, 500 million items. Then in this post [1] they say they're rearchitecting the database, then mention Snowflake. It sounds to me like they need a document store like Lucene in order to get fast search performance--but they may be optimizing for other use cases like tracking orders which is probably easier in a RDMBS.

It also looks like they might first do all the work to retrieve all the results for a query. The first request is to an endpoint `search_v3/{term}?cache_key={key}` then subsequent requests are to `asyncresultset_{n}?cache_key={key}` so seems like they might have the result set cached from the first query.

The response to the autocomplete endpoint, which is fast, contains an `elastic_id` so perhaps they do partially use a document store.

[0] - https://stackshare.io/posts/the-tech-behind-instacarts-groce... [1] - https://tech.instacart.com/the-story-behind-an-instacart-ord...

The slowness of this query is more related to the negations than the fact that the query is uncached. Most uncached queries will be handled much more quickly. I'm surprised this one takes so long, because I would have expected the negations to eliminate the corresponding branches of the OR during query simplification, but maybe there is some expansion happening before we get to that point that makes it hard to detect this logical conflict.

Probably also the sheer frequency of the terms in the OR don't help. Normally "the" would be treated as a stopword (https://en.wikipedia.org/wiki/Stop_word). But I'm not sure if that logic applies when it appears alone in a sequence of terms (as when it's the child of an OR).

About 9,33,000 results (5.97 seconds)

Perhaps cache evicted. :D Or probably my PoP is different.

5.3 seconds. I think you may have found a pathological case. Or we're just all on different pops (because I got .38 seconds when I did it again so obviously it was cached the second time).

I don't think you read the article. Devtools shows 130 requests because it considers inline data URIs to be a request--instead, there are lots of inlined images. so the page looks mostly complete with only the original document request.

Clearly the article means "make fewer render blocking requests."

Are you comparing search with a static page load ?

Just compare the google page load if you want to compare with that ?

Nothing special about it, it's just another round-trip that you'd have to make.

There's also the statistical impact of many round-trips: imagine a network where 1% of connections take 1 second, while 99% take 1 milisecond. If you issue > 100 request then most page loads will be slow.

> for tail-end requests the result might not be as impressive

Yep, it is possible to craft search queries that take multiple seconds to process. Example [1]:

    the OR google OR a OR "supercalifragilisticexpialidocious" -the -google -a

[1] https://news.ycombinator.com/item?id=20605589

I had this idea too. I proposed it as an alternative to web bundles.

Include a cache attribute to inline resources to mark the inline resource as cacheable. Whenever an empty element with the same attribute is encountered, use the cache. Could use a header with a serialized bloom filter to convey what has been cached to the server.