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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Idle Until Urgent

295 点作者 bootslebaron超过 6 年前

14 条评论

alangpierce超过 6 年前
&gt; Important! While browsers can run input callbacks ahead of queued tasks, they cannot run input callbacks ahead of queued microtasks. And since promises and async functions run as microtasks, converting your sync code to promise-based code will not prevent it from blocking user input!<p>Wow, my initial reaction while reading was &quot;just use async functions and then then code will naturally allow user input in the middle&quot;, good to know that that doesn&#x27;t work.
评论 #18033062 未加载
评论 #18033453 未加载
评论 #18033851 未加载
sequoia超过 6 年前
[cw: tangential point]<p>&gt; This is the JavaScript equivalent of death by a thousand cuts.<p>Seems to me there&#x27;s one really big knife in particular, doling out most of the cuts: <a href="https:&#x2F;&#x2F;i.imgur.com&#x2F;Hzrfq13.png" rel="nofollow">https:&#x2F;&#x2F;i.imgur.com&#x2F;Hzrfq13.png</a><p>I wonder what analytics platform is contributing all this slow-down to his first interaction... ;)
评论 #18034190 未加载
enobrev超过 6 年前
I don&#x27;t think this comment matters, but since so many other comments on this article are speaking up against, maybe it does.<p>I don&#x27;t care, at all whatsoever, if this person wants to use JavaScript for their blog.<p>Otherwise, nice article about improving performance and prioritizing important functionality during page-load.
评论 #18033267 未加载
AstralStorm超过 6 年前
I&#x27;m not sure why you trust Google Web &quot;Fundamentals&quot; that 0-100ms is perceived as instant.<p>The upper bound is perceptibly laggy. I have no idea where Google took their numbers from.<p>FID of 100 ms is already bad as you have to add network latencies on top of it.<p>To put things into perspective, it&#x27;s more than the time it takes to fully boot embedded Linux as coreboot from not too fast flash or start up Commodore 64 with a good extension cartridge.<p>The browsers are terribly slow.
评论 #18034032 未加载
评论 #18031773 未加载
评论 #18036119 未加载
评论 #18031326 未加载
评论 #18031900 未加载
jgtrosh超过 6 年前
Reading this article and applying a similar technique to a different webpage could be a good exercise for advanced students in front end development. The core idea is put forward, and no implementation detail is left out; great article.
theandrewbailey超过 6 年前
I guess I&#x27;m an old man that hasn&#x27;t smoked the hype, but I don&#x27;t understand why one would write this:<p><pre><code> const main = () =&gt; { setTimeout(() =&gt; drawer.init(), 0); setTimeout(() =&gt; contentLoader.init(), 0); setTimeout(() =&gt; breakpoints.init(), 0); setTimeout(() =&gt; alerts.init(), 0); requestIdleCallback(() =&gt; analytics.init()); }; </code></pre> over this:<p><pre><code> function main(){ setTimeout(drawer.init, 0); setTimeout(contentLoader.init, 0); setTimeout(breakpoints.init, 0); setTimeout(alerts.init, 0); requestIdleCallback(analytics.init); };</code></pre>
评论 #18033182 未加载
评论 #18031978 未加载
评论 #18031991 未加载
评论 #18032026 未加载
评论 #18032987 未加载
评论 #18032914 未加载
评论 #18033839 未加载
thegeomaster超过 6 年前
What I don&#x27;t understand is why a very simple blog like this needs a ~56KB bundle of JavaScript at all.
评论 #18032368 未加载
评论 #18032686 未加载
评论 #18031349 未加载
评论 #18033045 未加载
评论 #18034158 未加载
评论 #18031356 未加载
benjaminjackman超过 6 年前
Here is:<p>- The [repo](<a href="https:&#x2F;&#x2F;github.com&#x2F;GoogleChromeLabs&#x2F;idlize" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;GoogleChromeLabs&#x2F;idlize</a>) implementing the pattern described in the article<p>- The [package](<a href="https:&#x2F;&#x2F;yarnpkg.com&#x2F;en&#x2F;package&#x2F;idlize" rel="nofollow">https:&#x2F;&#x2F;yarnpkg.com&#x2F;en&#x2F;package&#x2F;idlize</a>)
code-is-code超过 6 年前
A few month ago, I used a similar optimisation that does the same idle-awaiting but with server-requests instead of cpu-usage. So instead of submitting all ajax to the server directly, background tasks can be delayed until the important tasks have finished. This is useful especially when the 6 requests per origin limit gets hit often.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;pubkey&#x2F;custom-idle-queue" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;pubkey&#x2F;custom-idle-queue</a>
iofiiiiiiiii超过 6 年前
Not being a JavaScript guy, my eyes sort of glazed over after the flame graphs. Do I understand the gist of it right that a 200+ millisecond delay is normal if you just have 56KB of light blog page style JavaScript code whose loading you do not somehow optimize? Or is there something pathological in play here?
评论 #18031902 未加载
eridius超过 6 年前
If the measurement here is how long it takes to respond to the first user input, why does a 233ms main function matter? As a user, how am I expected to scan the page, locate a link, and click on it within that 233ms?
评论 #18035082 未加载
bovermyer超过 6 年前
While this is impressive work, I can&#x27;t help but wonder if this is solving the wrong problem.<p>If the goal is to load fast, wouldn&#x27;t it be better to just stop using JavaScript altogether? It&#x27;s a blog, not an app.
评论 #18032588 未加载
elfakyn超过 6 年前
The Amazon app has an absolutely horrendous FID of around 10 seconds or so. They could use a little bit of optimization.
a012超过 6 年前
Meanwhile, there are many websites don&#x27;t care if their page loads in a few seconds. For example: <a href="https:&#x2F;&#x2F;i.imgur.com&#x2F;coBKPa1.jpg" rel="nofollow">https:&#x2F;&#x2F;i.imgur.com&#x2F;coBKPa1.jpg</a>