JSConf.jp 2022 の Closing Keynote (typo 等修正版)です https://jsconf.jp/2022/talk/web-runtime 日本語で33分33秒くらいかけてお話ししました https://youtu.be/luiNGMM9ZGU?t=31269
![Web Runtime](https://cdn-ak-scissors.b.st-hatena.com/image/square/13d8cb17cdba9d9817f7e3c2a5b5923273019ddf/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F0796efa19816403f9f2df44e133987a5%2Fslide_0.jpg%3F23605852)
Event Loopってみなさん聞いたことありますか? 「うん、なんか聞いたことありますが、よくわからないな・・・」や「分かりそうで、分からないな・・・」って思ってる方がいますかね? 長文ではありますが、Event Loop というものを改めて理解してみましましょう! まずこのコードの実行結果を考えてみましょう。 console.log('1') setTimeout(function callback(){ console.log('2') }, 1000) new Promise((resolve, reject) => { console.log('3') resolve() }) .then(res => { console.log('4'); }) console.log('5') 答えを分かりますでしょうか?正解はこの後記事内で公開します。 JavaScript 実行の仕組み
フロントエンド用語を100秒で解説するチャンネルを作りました! よかったらチェックしてみてください! はじめに 以前書いた記事「Webページがブラウザに表示されるまでに何が起こるのか?」で ブラウザレンダリングについて詳細に知りたいという意見をいただいたので、調べてまとめてみました。 全体図 レンダリングの大まかな流れです。 HTMLのダウンロード サーバから送られてきたHTMLをダウンロードします。 HTMLの解析 サーバから送られてきたHTMLファイルは、「0」と「1」でできたデータになっています。 ブラウザは、サーバから受け取ったデータをそのままHTMLとして解釈することはできないので、自分で扱うことができる形、つまりDOMに変換する必要があります。この作業を 解析 ( Parse ) と言います。 HTMLをダウンロードしたら、すぐにこの解析作業に入ります。作業は以下のようなステッ
February 18, 2019 How browsers schedule and execute scripts can impact the performance of web pages. While techniques like <script defer>, <link rel=preload> (and others) influence script loading, knowing how browsers interpret them can also be helpful. Thanks to Kouhei Ueno, we now have an up to date summary of script scheduling in Chrome.
JavaScript Start-up Optimization Stay organized with collections Save and categorize content based on your preferences. As we build sites more heavily reliant on JavaScript, we sometimes pay for what we send down in ways that we can’t always easily see. In this article, we’ll cover why a little discipline can help if you’d like your site to load and be interactive quickly on mobile devices. Delive
Note: The browser is picky about the import syntax, particularly where it comes to the URL. All paths must be either absolute or relative, and relative paths must start with '.' or '..' Up until now, we’ve been using bundlers like rollup and webpack to turn all of those modules into a single JavaScript file that the browser can run (or perhaps several of them, if we’re code-splitting). This is bec
Update: The Cost Of JavaScript In 2019 is now available to read. As web developers, we know how easy it is to end up with web page bloat. But loading a webpage is much more than shipping bytes down the wire. Once the browser has downloaded our page’s scripts it then has to parse, interpret & run them. In this post, we’ll dive into this phase for JavaScript, why it might be slowing down your app’s
最近、またGoogleアナリティクスの面倒を見ている。で、GAのドキュメントを見ていたら最近のイケてるトラッキングスニペットはこれだぜ!みたいなこと書いてあった。やれやれ、またかと思い、筆をとったのです。 トラッキングスニペットの移り変わり激しいもので、最近だとこうゆうのが一般的だろう。 <script> (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){ (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o), m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m) })(window,
「ピクシブ株式会社 Advent Calendar 2015」の24日目の記事です。こんにちは、今年8月からピクシブに入社した新米の@_furoshikiです。入社直後は、古くなって大変なことになっているJavaScriptのコードを、そーっと触る系エンジニアをやっていました! 私はピクシブに入る前から、オフィスの一部を借りて「東京Webパフォーマンス」という趣味丸出しなイベントを開催しています。その中で扱ったテーマのひとつである「requestIdleCallback」が、古いJavaScriptのコードにUIをブロックされ、荒んでいた私の心を救ってくれました! 今回、このrequestIdleCallbackというブラウザの新機能について、pixiv insideのブランド力を信じて、日本に多く広まるよう宣伝してみようかとおもいます! そもそも、ブラウザのなにが問題なのか? Windo
2015年にもなるのにJavaScriptでのDOM操作のパフォーマンスについて書く。ウェブページにインタラクションを持たせたい時に、JavaScriptでDOM操作を行うことがよくある。このDOM操作のパフォーマンスについて、よく聞く意見を大別すると次の2つがある。 JavaScriptによるDOM操作は重たい レンダリングが重いだけで、DOM操作そのものはそれほど重たくない JavaScriptでオブジェクトのプロパティを操作したりする単体の処理は通常1ミリ秒もかからないが、DOM操作をするとレンダリングが完了するまでに数十ミリ秒程度かかったりする場合がある。1番目のDOM操作が重たいと言っている人は経験則的にそう言っていることが多い。 レンダリングの仕組みを知っている人は2番目の意見を言うが、重箱の隅をつつくような話をするとこれも必ずしも正しいわけではない。DOM操作するコードによっ
QuirksMode.org - DOM This is the index page of all my DOM tests. Table of Contents All core DOM functionality; i.e. stuff that should work in any environment, and not just in JavaScript-driven web pages.
Nat Duca is an engineer on the Chrome team working to make an always-60fps, jank free mobile web a reality. If you want to move something at 60fps today, you must apply a littany of tricks, especially translateZ and friends. If you make a mistake, off the fast path ye shall go. On the Chrome team we think this sucks. Throughout the last year, we've been digging through examples of mobile UIs buil
What is performance? Creating a high performance web site is a delicate dance. Many people think it’s just about how fast your JavaScript performs. The reality is that it’s far more than that. There are also multiple ways to measure performance. The first is load time. From the time that a user clicks a link or enters a URL into the address bar, how long does it take to load that page? Even this h
Deep dive into the murky waters of script loading Stay organized with collections Save and categorize content based on your preferences. Introduction In this article I’m going to teach you how to load some JavaScript in the browser and execute it. No, wait, come back! I know it sounds mundane and simple, but remember, this is happening in the browser where the theoretically simple becomes a legacy
[フロントエンド] ブラウザレンダリングの仕組みを理解して、ブラウザに優しいJavaScriptを書こう こんにちは、@yoheiMuneです。 ブラウザのレンダリングの仕組みはHTML5 RocksやHow browsers workで詳しく解説されてきました。しかしそれらはとても詳細で、読破して理解するのは大変です。 今回のブログでは手軽にレンダリングの概要を理解できるように心がけました。またより詳しく学べるようなリンクも記載しました。 そしてブラウザのレンダリングの仕組みを理解した上で、どのようなJavaScriptを書くべきかについても記載しました。 目次 ブラウザのレンダリングの仕組み この章では、HTMLとCSSが読み込まれてから画面に表示されるまでの間に、ブラウザがどのような処理を行っているかを説明します。 ファイル読み込みから表示までの一連の流れは以下図の通りです。 [1]
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く