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

81–87 of 87 posts

Re: Web Performance Profiling: Google.com

#81

Post by missblit »

anthony_r wrote: post #39
cblconfederate wrote: post #34

What s the deal with the CSS thing? I 've noticed that custom fonts cause considerable slowness, but CSS?

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.

It doesn't need to be an extra round-trip in HTTP/2 or HTTP/3 thanks to server push (which is basically link rel preload, but without the roundtrip part)

Re: Web Performance Profiling: Google.com

#82

Post by oarsinsync »

dmitriid wrote: post #72
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 prop…

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

All of that said, if the time is measured in more than triple digit nanoseconds, relative to the hardware capabilities that we have today, it’s slow.

Please do not take that as a reflection on you personally or your work, but rather a reflection on the layers and layers of abstraction we’ve collectively added, and keep adding. While we’ve made it easier for people (especially developers) to write code, we’ve made everything slower, and just continue to mask that with hardware improvements.

Re: Web Performance Profiling: Google.com

#83

Post by GuB-42 »

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.

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.

Re: Web Performance Profiling: Google.com

#84

Post by james412 »

rsynnott wrote: post #66
SketchySeaBeast wrote: post #33

Earlier quoted context omitted.

Considering the functionality, what would be your limit to keep google from being considered a "huge dog"?

Reverting to their own search site from 10 years ago?

You might be pleased to notice Google Scholar is pretty much still the old design, such a breeze to use

Re: Web Performance Profiling: Google.com

#85

Post by dmitriid »

oarsinsync wrote: post #82
dmitriid wrote: post #72

Earlier quoted context omitted.

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 prop…

> 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. All of that said, if the time is measured in more than triple digit nanoseconds, relative to the hardware capabilities that we have today, it’s slow . Please do not take that as a reflection on you personally or your work, but…

I totally agree with you on that conclusion.

Re: Web Performance Profiling: Google.com

#86

Post by sozy777 »

kempbellt wrote: post #29
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.

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…

And setup ads biddings, customized to you...

Re: Web Performance Profiling: Google.com

#87

Post by anthony_r »

nevir wrote: post #16
thdrdt wrote: post #13

Earlier quoted context omitted.

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

By doing all the calculation in memory. Disk is too slow

There's also flash, which is also pretty fast, and fits nicely between magnetic and RAM.

Here's a handy rule of thumb about relative costs: the cost of a byte on magnetic_disk:flash:ram is about 1:10:100. I.e. the cost increases 10x when you go to the next level.

Post reply on HN