佐藤歩のレビュー一覧
-
-
Posted by ブクログ
ネタバレ■読んだ動機
最近パフォーマンスを気にする機会が多く、この本が気になり手に取った
■感想
ブラウザの仕組みについて非常に詳しく書かれており、
60FPSを目標とする
CSSのshadowやborder-radiosはレンダリングコストが高い
などそのほかにもブラウザがレンダリングを完了するまでに何が起きているか学べることが多くて良かった。
■以下気になった箇所
WebフロントエンドエンジニアがWebページの速度を表現するには、大きく分けてページロードとランタイムという2つの観点があります。この2つがいずれも高速であれば、そのWebページは速度面において高い品質を実現できていると言える。
RAILモデル 注16 は、Webページの速度の重要性について啓蒙するGoogleのエヴァンジェリストたちによって紹介されているモデルです。これはResponse、Animation、Idle、Loadの頭文字をとったもので、それぞれのタイミングの応答時間について 表1.2 の目標値を掲げています。
サーバがクライアントにデータを送信するときは、いきなり大量のデータを送るわけではなく、小さいデータサイズでの送信から始めて、 輻輳 注３ しないようにコントロールしながら徐々に転送速度を上げます。このようにTCP接続におけるデータのやりとりが徐々に高速になるしくみを、TCPスロースタートと呼びます
ネットワーク処理を最適化していくうえで意識するべき基本原則は、 ・データの転送量をなるべく小さくすること ・データの転送回数をなるべく少なくすること ・データの転送距離をなるべく短くすること の3つ。
FPSとは、画面が1秒間に何回更新されるかの単位です。FPSは動画、映像処理など全般で使われている単位で、たとえば我々が普段見ている日本のテレビはおよそ30FPS、映画やアニメは24FPSで作られています。 Webでは、60FPSを目標として考えましょう。これは、一般的なディスプレイのリフレッシュレート 注２ が60Hzだからです。
Webページのビジュアルを決めるスタイルは、レンダリング処理の速度に直結します。CSS3以降に追加された影やグラデーション、角丸などを表現するプロパティは、画像を使わないで実現できるビジュアルの幅を広げてくれた代わりに、複雑なビジュアル上の処理を必要とするためコストが高くなりがちです。 -
Posted by ブクログ
■Webフロントエンドを高速化する3つのポイント
Webページの速度に影響を与えるWebフロントエンド上の要因を実装観点で整理すると、ネットワーク処理、レンダリング処理、スクリプト処理の3つに分類できます。これらの要因がページロードとランタイムのそれぞれに影響することによって、Webページの速度が変わってきます。本書ではこの3つの要因を軸として、第2章以降でそれらを調査、改善するための具体的な説明をします。ここでは全体像をつかむために、それぞれの要因を簡単に紹介します。
①ネットワーク処理― HTMLドキュメントやサプリソースの取得
Webフロントエンドにおけるネットワーク処理とは、サーバから配信されるHTML、CSS、JavaScript、画像などの各種リソースを、ブラウザがダウンロードする処理を指します。このダウンロードに要する時間が短ければ、ページロードの高速化につながります。
ネットワーク処理については、ページロードに強く影響するため昔から注目されていたこともあり、さまざまな高速化のノウハウがたまっています。それらのノウハウのすべてが今も有効とは限りませんが、少なくとも速度の計測手段が整備されているので、ほかの要因と比べると調査と改善がしやすく感じられるでしょう。
ネットワーク処理を改善する方法はいろいろありますが、たとえばダウシロードすべきリソースの数やファイルサイズの最適化などが考えられます。どのように調査、改善を進めるかについては、第2章と第3章で説明します。関連して第8章では画像形式について、第9章ではネットワーク処理の効率化に役立つ今後の技術について、それぞれ紹介します。
②レンダリング処理―ディスプレイへの表示
Webフロントエンドにおけるレンダリング処理とは、HTMLとCSSに基づいて要素をレイアウトして表示したり、画像をラスタライズ(データをディスプレイに表示可能なビットマップに変換すること)して表示したりする処理を指します。ページロードとランタイムの両方に関わる処理ですが、レンダリング処理自体の遅延が問題になりやすいのはランタイムのときでしょう。
近年のWebページで表現されるコンテンツのリッチ化などを背景として、レンダリング処理は潜在的な問題を抱えがちな要因です。jQueryプラグインをはじめとした再利用可能なパーツによってアニメーションなどの実装ハードルは下がっていますが、それが低スペックなデバイスでもスムーズに動くパーツであるかは導入時に検証が必要です。
iPhoneやAndroidのネイティブアプリのメリットとして、高速でスムーズに動くUIを実現できるという点が挙げられますが、Webでもレンダリング処理を最適化すれば、ネイティブアプリのようにスムーズに動くUIの実現は不可能ではありません。
レンダリング処理は、画面の更新に関わる各種の処理が効率的に実行されるようにすれば改善できます。どのように調査、改善を進めるかについては、第4章と第5章で説明します。
③スクリプト処理―JavaScriptによる演算やDOM操作
Webフロントエンドにおけるスクリプト処理とは、JavaScriptによる処理を指します。これもレンダリング処理と同じで、多くの場合はランタイムのときに問題になりやすいです。
問題がある場合のほとんどは、JavaScriptのロジックに問題があるか、JavaScriptによって操作されるDOM(Document Object Model) やスタイル、つまりレンダリング処理にまつわる部分の問題に集約されます。しかし、JavaScriptを多用した高度なアニメーションを含んでいたり、SPA(Single Page Application) として構築されていたりするWebページでは、スクリプトの計算量やメモリリークにも気を付ける必要があります。
スクリプト処理はJavaScriptを丁寧にチューニングしていくことで改善できます。どのように調査、改善を進めるかについては、第6章と第7章で説明します。
■Jakob Nielsen氏が示した基準時間
応答時間による限界/基準時間
瞬時に応答があって自分がUIを直接コントロールしていると感じられる限界/0.1 秒
遅延を伴うが一連のナビゲーションが間断なく進んでいると感じられる限界/1.0秒
操作中のアプリケーションに関心を向けていられる限界/10秒
■RAILモデルにおける応答性の目標時間
応答性のタイミング/目標時間
Response (UI操作の応答があるまでの時間)/100ミリ秒
Animation (アニメーション1フレームあたりの時間)/10ミリ秒
Idle (アイドル状態で行われる処理単体の時間)/50ミリ秒
Load (ページロードの時間)/1,000ミリ秒
■ネットワーク処理最適化の３原則
・データの転送量をなるべく小さくすること
・データの転送回数をなるべく少なくすること
・データの転送距離をなるべく短くすること
■WebサイトのUIがスムーズである主な条件
・動きの滑らかさ―1フレームあたり10ミリ秒
・UIの応答速度―100ミリ秒
■FPSという基準
レンダリング処理がスムーズに行われているかどうかを判断するには、一般的にFPSを基準とします。FPSによって、Webページをスクロールしているときや、何らかのアニメーションが動作しているときのレンダリング処理の負荷がわかります。
FPSとは、画面が1秒間に何回更新されるかの単位です。FPSは動画映像処理など全般で使われている単位で、たとえば我々が普段見ている日本のテレビはおよそ30FPS、映画やアニメは24FPSで作られています。
Webでは、60FPSを目標として考えましょう。これは、一般的なディスプレイのリフレッシュレートがG0Hzだからです。ハードウェアの性能以上に表示されるFPSが高まることはないので、60FPSが一般的な限界値と言えます。
60FPSという数字を実現するのは、容易ではありません。60FPSを実現するには、1回のフレーム更新にかけられる時間は「1,000ミリ秒/60フレーム=16.666...ミリ秒」であり、およそ16.7ミリ秒です。よって、RAILモデルにおけるAnimationでも16.7ミリ秒に対してさらに余裕を持たせて、1フレームが10ミリ秒以内であることを理想としています。
スクリプト処理を実行している間、ブラウザはほかの処理ができません。そのため、処理に極端に時間のかかるスクリプトは60FPSの維持に影響します。
JavaScriptエンジンの性能が向上し処理速度が上がっても、シングルスレッドで実行されるという言語特性は避けて通れません。 -