【LINE証券 Frontend】requestIdleCallbackを活用して初期レンダリング時間を約14%削減した話
こんにちは。フィナンシャル開発センターの鈴木です。LINE証券のフロントエンドを担当しています。この記事は【LINE証券 FrontEnd】シリーズの4番目の記事です。 最近のWeb Vitalsの隆盛を受けて、LINE証券のフロントエンドでもパフォーマンスの改善に取り組み始めました。およそ2週間ほど改善に取り組んだ結果として、開発環境での計測ではLighthouseのperformanceスコアが従来より30点ほど上昇しました。 パフォーマンス改善のためにさまざまな施策を行いましたが、この記事ではその中でも興味深かったものとして、requestIdleCallbackを活用してLazy Loadingされるコンポーネントの読み込みを遅延し、その結果初期レンダリングにかかる時間を約14%削減できた事例をご紹介します。 環境 以前の記事でご紹介したとおり、LINE証券のフロントエンドはTyp
requestIdleCallback の使用 | Blog | Chrome for Developers
多くのサイトやアプリでは、多数のスクリプトを実行できます。JavaScript をできるだけ早く実行しなければならないことは珍しくありませんが、同時にユーザーの邪魔にならないようにする必要があります。ユーザーがページをスクロールしているときにアナリティクス データを送信したり、ボタンをタップしている間に DOM に要素を追加したりすると、ウェブアプリが応答しなくなり、ユーザー エクスペリエンスが低下する可能性があります。 便利な API requestIdleCallback が追加されました。requestAnimationFrame を採用することでアニメーションを適切にスケジュールし、60 fps を達成する可能性を最大化できたのと同じように、requestIdleCallback はフレームの終わりに空き時間があるとき、またはユーザーがアクティブでないときに作業をスケジュールします
サイト上のさまざまなページのパフォーマンスをまとめて測定できるツール「Unlighthouse」
「Lighthouse」はGoogleが作成したページの読み込み速度やアクセシビリティなどをまとめてチェック・採点してくれるツールですが、そのLighthouseをサイト上のさまざまなページで動作させることでサイト全体のスコアを一発で算出してくれるツールが「Unlighthouse」です。 Unlighthouse - Site-wide Google Lighthouse · Unlighthouse https://unlighthouse.dev/ Unlighthouseを利用するためにはNode.jsのインストールが必要です。下記のURLから、手元の環境に合ったインストール方法を選択してください。 パッケージマネージャを利用した Node.js のインストール | Node.js https://nodejs.org/ja/download/package-manager 今回は
Don't attach tooltips to document.body
10 Mar, 2021 Don’t attach tooltips to document.body TL;DR Instead of attaching tooltips directly to document.body, attach them to a predefined div in document.body. BAD <body> <!-- temporary div, vanishes when tooltips vanishes --> <div>my tooltip</div> <body> GOOD <body> <!-- this div stays forever, just for attaching tooltips --> <div id="tooltips-container"> <!-- temporary div, vanishes when to
フロントエンドが遅いと言われた時に
Webアプリケーションで、ブラウザ上でJavaScriptを用いてAPIからデータを取得して画面に反映する挙動が遅いと言われた時にフロントエンド側が確認することと対処方法。 ユーザのボタンクリックなどのアクションをトリガーとして、APIからデータを取得し画面に反映するというシナリオがあった際に、ユーザのアクションから画面への反映に時間を要しているという状況を想定しています。 Largest Contentful Paint (LCP)が遅い場合に関しては、別のアプローチになるので今回は除外します。 本当にフロントエンドがボトルネックになっているか まず最初にすることは、APIのレスポンスタイムと、APIのデータを画面に反映する処理のどちらがボトルネックになっているかの確認です。 ユーザのアクションから画面への反映までの時間の中でAPIのレスポンスが大部分を占めている場合、プリフェッチなどの
Intersection Observer API のパフォーマンス：複数インスタンス vs 共有インスタンス
はじめに きっかけは以下のかまぼこさんのツイートです。 僕からの回答は以下です。 この記事ではこちらについてもう少し詳しく解説いたします。なお、Intersection Observer API の解説は割愛しますので、詳しくはこちらをご確認ください。 検証 コンポーネントごとにオブザーバー スクロールに応じて要素をアニメーションさせる場合、React で素直に実装すると、おそらくコンポーネントごとに Intersection Observer のインスタンスを生成して、それぞれの要素を監視して状態を変化させることになるかと思います。具体的なコードを見たほうがわかりやすいと思いますのでサンプルコードを示します。
Reactのこともっとよくしろう! ~Reactパフォーマンス編~
今回も、リポジトリを用意しました。 branchをlesson/3に切り替えると今期時の作業が可能です。 差分検出方法 パフォーマンスを向上する為にはまず、Reactがどのようにして表示を切り替えているかの仕組みをおさえておく必要があります。 Reactはいわゆる仮想DOMの仕組みで動いているので、Reactで構築している仮想DOMの変更を検出し、HTMLに反映するのが主な流れです。 仮想DOMについてより詳しく知りたい方は、下記の記事がおすすめです。 仮想DOMは本当に“速い”のか？ DOM操作の新しい考え方を、フレームワークを実装して理解しよう 実際に仮想DOMの小さなフレームワークを実装しながら、仮想DOMの仕組みについて学ぶことができます。 つまりはReact仮想DOMと実DOMの差分を検出する方法をおさえておくことで、パフォーマンス向上のための取り組みが理解できます。 差分検出の
【パフォーマンス】Next.js から学ぶCSSのインライン化
こんにちは、@kaa_a_zu です。Zennにおける処女作であるこの記事では、スタイルをCSSファイルとして定義し読み込むのではなく、インライン化することが何故パフォーマンスに影響を及ぼすのか、またインライン化を行うときに何に注意をしないといけないのかについて書こうと思う。 インラインCSS の効果 まず、「CSSをインライン化することでパフォーマンスが改善される」ことが分かる事象について紹介する。 Next.js の automatic-webfont-optimization Reactのフレームワークである Next.js v10.2 で導入された automatic-webfont-optimization が機能したことで、WebFontを利用しているサイトでは、以下のようなパフォーマンス改善が(ほぼ)起こる (※LightHouseでのスコアが全てではないが、パフォーマンスが
Passive Event Listeners によるスクロールの改善 | blog.jxck.io
Intro DOM のイベントリスナの仕様に Passive Event Listeners というオプションが追加された。 このオプションは、主にモバイルなどでのスクロールの詰まり(Scroll Junk) を解決するために導入されたものである。 今回は、この仕様が解決する問題と、本サイトへの適用を解説する。 Passive Event Listeners Spec Scroll Event の PreventDefault() 画面のスクロールに合わせたインタラクションを実装する場合、 Scroll Event にイベントリスナを登録する。 典型的な例では touchstart や touchend をフックし、その中で DOM の操作などを実施するなどがある。 場合によってはイベントリスナ内で preventDefault() を呼ぶことで、スクロールそのものを止めることもできる。
Web Speed Hackathon 2021 miniでほぼ満点を出しました
gzip圧縮だとあまり圧縮できていなく、スライディングウィンドウが小さいせいかなと思ったのですが、実際に大きさがかなり違うみたいなので、それが原因としてありえそうです。 Gzip uses a fixed size, 32KB window, and Brotli can use any window size from 1KB to 16MB, in powers of 2 (minus 16 bytes). This means that the Brotli window can be up to 512 times larger window than the deflate window. Results of experimenting with Brotli for dynamic web content - The Cloudflare Blog AudioContextの
DOM操作の最適化によるJavaScriptチューニング（後編）
連載「Webサイト・アプリ高速化テクニック徹底解説」の第5回は、前回の「DOM操作の最適化によるJavaScriptチューニング（前編）」に続く後編です。後編では、createElement()などのDOM操作メソッドを使ったさまざまなテクニックや、パフォーマンスを劣化させるよくあるパターンについて詳しく解説します。 CodeIQとの連動企画！ この記事で学べるJavaScriptチューニングのテクニックを、実際にCodeIQの問題で試すことができます。もう既に自信がある方は腕試しに、もしくは理解度チェックのための復習として是非ご活用ください！こちらから問題にチャレンジ！ 前回は、DOM操作が遅い原因と仕組みについて簡単に説明し、チューニングのサンプルをいくつか解説しました。その中で、innerHTMLを利用したコードをサンプルにあげていますが、innerHTMLを利用する場合、いくつかの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
より速い WEB を目指す Next.js / nextjs-make-the-web-faster
性能に関する考え方