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

61–70 of 87 posts

Re: Web Performance Profiling: Google.com

#61

Post by codegladiator »

sushshshsh wrote: post #57
jkaptur wrote: post #36

Earlier quoted context omitted.

Does using the .to TLD really imply that the request has to make a hop through Tonga? I'm not a DNS expert, but that doesn't sound right. (I ask as the owner of a .so site...)

I also am not an expert, but Dan J Bernstein (the owner of cr.yp.to) states that his website --- er actually hold on, I think I misremembered the story from his site. Let me paste it here: 2000-11-16: The .to administrators destroy yp.to for reasons that have never been explained. See more here: https://cr.yp.to/serverinfo.html

That's quite an interesting page.

They had a recent outage after 3 years

> 2017.07.24 roughly 21:50 to 22:10: Unexplained network outage at UIC.

> 2020.04.20 roughly noon GMT: Power outage at UIC.

Re: Web Performance Profiling: Google.com

#62

Post by scarmig »

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.

I would guess that aggressive caching and indexing are at least as important as having thousands of computers complete the request at once (and I'd be surprised if the number of computers on the request path is nearly that high--if nothing else, thousands of computers mean you're almost guaranteed to hit p999 latency every time).

Re: Web Performance Profiling: Google.com

#63

Post by jeffbee »

scarmig wrote: post #62
jeffbee wrote: post #46

Earlier quoted context omitted.

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.

I would guess that aggressive caching and indexing are at least as important as having thousands of computers complete the request at once (and I'd be surprised if the number of computers on the request path is nearly that high--if nothing else, thousands of computers mean you're almost guaranteed to hit p999 latency every time).

> guaranteed to hit p999 latency

That's why people invented the backup request.

Re: Web Performance Profiling: Google.com

#64

Post by offsky »

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.

Re: Web Performance Profiling: Google.com

#65

Post by rsynnott »

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.

I mean, it's fast _for an SPA that weighs 700kB compressed_. It is, however, substantially slower than it used to be, for no clear benefit.

Re: Web Performance Profiling: Google.com

#66

Post by rsynnott »

SketchySeaBeast wrote: post #33
james412 wrote: post #24

Earlier quoted context omitted.

A cold cache google page load here pushes 725kb just to render a logo and search box. To avoid fingerprinting my cache is always cold. Google search is a huge dog

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?

Re: Web Performance Profiling: Google.com

#67

Post by bagacrap »

Nextgrid wrote: post #30
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.

He makes a valid point; why does a page with a text field and links to other pages need to weigh anywhere close to 700kB?

knowledge cards are a lot more than links

Re: Web Performance Profiling: Google.com

#68

Post by sushshshsh »

codegladiator wrote: post #61
sushshshsh wrote: post #57

Earlier quoted context omitted.

I also am not an expert, but Dan J Bernstein (the owner of cr.yp.to) states that his website --- er actually hold on, I think I misremembered the story from his site. Let me paste it here: 2000-11-16: The .to administrators destroy yp.to for reasons that have never been explained. See more here: https://cr.yp.to/serverinfo.html

That's quite an interesting page. They had a recent outage after 3 years > 2017.07.24 roughly 21:50 to 22:10: Unexplained network outage at UIC. > 2020.04.20 roughly noon GMT: Power outage at UIC.

Hehe, UIC is the bane of cr.yp.to's existence, between network and power instability... Makes you appreciate what the big cloud players abstract away from us!

Re: Web Performance Profiling: Google.com

#69

Post by tanilama »

Doesn't come as surprising to me honestly. Besides performance reason, inlining everything also minimizes your dependencies as well, and now you can make sure what you send out is what user would be able to see.

I can also see how this makes integration testing magnitude easier/effective.

Re: Web Performance Profiling: Google.com

#70

Post by drivebycomment »

rsynnott wrote: post #65
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.

I mean, it's fast _for an SPA that weighs 700kB compressed_. It is, however, substantially slower than it used to be, for no clear benefit.

You want to claim it's substantially slower than before. Do you have data to back that up ? If it's based on your personal anecdote, my personal experience is that the speed stayed roughly similar. It has become more "cluttered" with lots of extra stuff - images, knowledge cards, list of items, maps, etc. But the page load speed has been mostly similar - fast enough, though not quite instant.

When they first launched the search-as-you-type, it did feel instant but then I don't search on google.com anymore but use the chrome url bar.

Post reply on HN