TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Web Performance Profiling: Google.com

117 点作者 toddgardner超过 4 年前

16 条评论

stingraycharles超过 4 年前
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?<p>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.
评论 #24482512 未加载
评论 #24482470 未加载
评论 #24483270 未加载
评论 #24482454 未加载
评论 #24488836 未加载
评论 #24482773 未加载
评论 #24487577 未加载
fatnoah超过 4 年前
When I think of &quot;fast&quot;, I always think of a time I was building a product that required subscribing to Twitter&#x27;s API to receive updates from specific users.<p>In my testing, I&#x27;d set a breakpoint on my server code to see when I&#x27;d get the &quot;push&quot; from Twitter&#x27;s API and would use the Twitter App on my phone to create test tweets. Every single time, I&#x27;d create a tweet and my server breakpoint would be hit immediately. Not soon, but immediately. I&#x27;d see my breakpoint triggered well before the UI in the app even refreshed after submitting the tweet.
评论 #24483259 未加载
评论 #24483021 未加载
评论 #24486024 未加载
dimtion超过 4 年前
One factor that is missing from this post is the processing time on the backend which is also insanely fast. This post only considers frond-end optimizations.<p>On the author&#x27;s benchmark, a roundtrip seems to take on average 30ms, and the time to first byte for the main content is around 140ms. Which means that in less than 110ms Google is able to parse the search query, and build the HTTP response.<p>I&#x27;m sure they are heavily relying on caches and other optimizations, and for tail-end requests the result might not be as impressive. But compared to many other websites in 2020 this is still unfortunately not the norm.
评论 #24482844 未加载
ouid超过 4 年前
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 <i>any other experience</i> on the internet. Is this a deliberate push to get me to use the mobile app? Some dark pattern thing?
评论 #24483405 未加载
评论 #24483253 未加载
TekMol超过 4 年前
It feels fast because most other sites are insanely slow.<p>Just build a normal HTML+CSS+JS site with serverside rendering, route the assets through a CDN and voila! your site will be just as &quot;fast&quot; as Google.
评论 #24482270 未加载
评论 #24482797 未加载
saberience超过 4 年前
You can make Google searches plenty slow if you Google something uncached.<p>I just Googled: the OR google OR a OR badger -the -google -a<p>it took: 5.66 seconds.<p>This is probably cached now so don&#x27;t try it yourself, replace badger with some other weird word. :)
评论 #24483422 未加载
评论 #24482698 未加载
评论 #24486820 未加载
offsky超过 4 年前
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.
评论 #24487019 未加载
tanilama超过 4 年前
Doesn&#x27;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.<p>I can also see how this makes integration testing magnitude easier&#x2F;effective.
cblconfederate超过 4 年前
What s the deal with the CSS thing? I &#x27;ve noticed that custom fonts cause considerable slowness, but CSS?
评论 #24482755 未加载
toddgardner超过 4 年前
It&#x27;s real sad that the title of this was changed from &quot;How the hell is Google so Fast?&quot;
epanchin超过 4 年前
Conversely, why is Windows search so miserably slow?
评论 #24483185 未加载
评论 #24482451 未加载
评论 #24482850 未加载
codegladiator超过 4 年前
&gt; How to Be Fast, Like Google<p>&gt;&gt; Make Less Requests<p>From 130 requests, that&#x27;s an odd takeaway.
评论 #24482190 未加载
评论 #24482241 未加载
sushshshsh超过 4 年前
Climb to the top of a mountain in the USA (or live in the countryside of a developing country), where you can only get 1 bar of 3g service.<p>Then try to load <a href="https:&#x2F;&#x2F;cr.yp.to" rel="nofollow">https:&#x2F;&#x2F;cr.yp.to</a><p>Ok now try to do a google search for dog food.<p>Tell me which one executes in less than a second, and which one hangs forever
评论 #24482331 未加载
newbie578超过 4 年前
Honestly, Google is one of the modern marvels, even when I read the article and understand _why_ Google is so fast, I still cannot comprehend it.<p>To people over 30 years ago, this is a literal example of magic.
chmod775超过 4 年前
&gt; How is Google so fast?<p>It is not. At least not in the way the article is talking about. So while yes, requests are fast, it doesn&#x27;t really feel that way when I can&#x27;t click anything for a good second after hitting search.<p>My browser takes roughly half a second crunching JavaScript, doing layout, and drawing the result page AFTER doing a whole boatload of HTTP requests. Annoyingly half that JavaScript runs AFTER the page is rendered (150ms-200ms of JS functions when I can already see results, why?), making the page appear to lag if you immediately try to click&#x2F;tap something.<p>If they would serve the page as static html and css instead, load times could easily be below 50ms with another 20ms for my browser to present me with something that is interactive right away.<p>The impressive part is how fast they generate results.
rsynnott超过 4 年前
I mean... is it? It feels a _lot_ slower than it used to, especially on slower devices.<p>Possibly that 700kB of random crap is implicated :)
评论 #24482144 未加载