Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web Performance Profiling: Google.com

requestmetrics.com

Post reply on HN
Print view View original

71–80 of 87 posts

Re: Web Performance Profiling: Google.com

#71

Post by drivebycomment »

MacsHeadroom wrote: post #51
johncena33 wrote: post #3

Earlier quoted context omitted.

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

https://lite.duckduckgo.com/lite is ~100x faster.

My chrome devtools says DDG took 900ms to load the search result on that page (searching for "foo bar"), vs Google search taking ~200ms for the initial result.

And subjectively, comparing side by side, Google is faster to display the result.

So your claim of 100x is not only inaccurate in quantity, it's opposite direction as well.

Re: Web Performance Profiling: Google.com

#72

Post by dmitriid »

fatnoah wrote: post #12

When I think of "fast", I always think of a time I was building a product that required subscribing to Twitter's API to receive updates from specific users. In my testing, I'd set a breakpoint on my server code to see when I'd get the "push" from Twitter's API and would use the Twitter App on my phone to create test tweets. Every single time, I'd create a tweet and my server breakpoint would be hit immediately. Not s…

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

Re: Web Performance Profiling: Google.com

#73

Post by Miraste »

jeffbee wrote: post #46
epanchin wrote: post #25

Conversely, why is Windows search so miserably slow?

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.

While that's true, Windows 10 search is visibly worse than even Windows 7 search, and much worse than MacOS search. And their fuzzy matching algo for the start menu is deranged.

Re: Web Performance Profiling: Google.com

#74

Post by jedberg »

saberience wrote: post #31

You can make Google searches plenty slow if you Google something uncached. I just Googled: the OR google OR a OR badger -the -google -a it took: 5.66 seconds. This is probably cached now so don't try it yourself, replace badger with some other weird word. :)

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

Re: Web Performance Profiling: Google.com

#75

Post by Traubenfuchs »

adventured wrote: post #58
ouid wrote: post #20

I have a related question. How is instacart so slow? I am usually pretty unbothered by slow load times, but searching for and selecting groceries is a full 10 times slower than any other experience on the internet. Is this a deliberate push to get me to use the mobile app? Some dark pattern thing?

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 should be doing a timed release on that. If you stop entering text for N ms, then go for a result.

I believe that is called debouncing and it's something any non-junior frontend developer should have in their toolkit.

Re: Web Performance Profiling: Google.com

#76

Post by samsquire »

offsky wrote: post #64

If you inline everything then you can’t take advantage of caching those resources. I wonder if there is a fancy way to inline the resources and then somehow use JS to cache the data, set a cookie and then on the second page load it’s even faster because you don’t have resend the inlined stuff.

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.

Re: Web Performance Profiling: Google.com

#77

Post by Answerawake »

MacsHeadroom wrote: post #48
fatnoah wrote: post #12

When I think of "fast", I always think of a time I was building a product that required subscribing to Twitter's API to receive updates from specific users. In my testing, I'd set a breakpoint on my server code to see when I'd get the "push" from Twitter's API and would use the Twitter App on my phone to create test tweets. Every single time, I'd create a tweet and my server breakpoint would be hit immediately. Not s…

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.

Technology can be understood and reasoned from first principles. Can you really say the same about human relationships, especially the complex kinds that can result in such a logical mismatch? There is a lot of irrationality in the real world.

Re: Web Performance Profiling: Google.com

#78

Post by dang »

johncena33 wrote: post #3
rsynnott wrote: post #2

I mean... is it? It feels a _lot_ slower than it used to, especially on slower devices. Possibly that 700kB of random crap is implicated :)

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

Please don't sneer, including at the rest of the community.

https://news.ycombinator.com/newsguidelines.html

Re: Web Performance Profiling: Google.com

#79

Post by ouid »

adventured wrote: post #58
ouid wrote: post #20

I have a related question. How is instacart so slow? I am usually pretty unbothered by slow load times, but searching for and selecting groceries is a full 10 times slower than any other experience on the internet. Is this a deliberate push to get me to use the mobile app? Some dark pattern thing?

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…

This makes sense technically, but it still doesn't answer the question of why it isn't fixed. Is it really that hard to experiment with caching policies? Is there secretly only one developer at instacart?

Re: Web Performance Profiling: Google.com

#80

Post by GretchenKlein91 »

stingraycharles wrote: post #19

Am I the only person here who wasn’t thinking about the frontend, but rather all the things that need to happen in the backend to render the search results? To me it feels like an oversight when answering the question “how the hell is Google so fast?” and not digging into how Google is able to return the results to your actual search query in a matter of milliseconds. That, to me, is the real miracle.

yeah me too
Post reply on HN