フロントエンド速度改善で遭遇した悲しき「罠」 ベスト７

ディップ Advent Calendar の 12日目です。

はじめに

こんにちは。
ディップでUXデザインや速度改善、潤滑油などをやっている@y-tsunaです。
前回の記事では多くの方からの反響があり、非常に感謝しております。
今回はフロントエンドの速度改善に取り組んだ際に見つかった罠７つを、順位付けて紹介します。
「罠」ということで外的要因が多めになっております。

読んでほしい人

・フロントエンドの速度改善に取り組んでいる人 （またはこれから取り組む予定の人）

悲しき罠たち

第７位　リクエスト数削減の罠

技術の進歩が牙を剥いたという罠です。

HTTP/1.1では諸々の事情により、ブラウザがドメイン毎の同時リクエスト数を制限していました。
これを回避するため、CSSスプライトや Data URI といったリクエスト数を減らす手法が速度改善施策として活用されていました。

時は流れ、問題となっていたこの制限が HTTP/2 によって解消されました。
私たちのサイトも速度改善の一環として HTTP/2 対応をしたのですが、その際に前述の CSSスプライトや Data URI について特に修正していませんでした。

その結果、個々の CSS や画像が肥大化したままになっており、逆に 不要なレンダリングブロック の要因となっていました。

現在は適切な形でファイルを分割し、レンダリングブロックが起きないよう対処しています。

第６位　Lighthouse は痒いところに手が届かない罠

計測ツールの仕様の罠です。

私たちはサイトの速度計測をする際に Google が提供している Lighthouse を利用しています。
（※ 本稿ではLighthouse の詳しい説明は割愛します）

この Lighthouse を使った計測では状態を持つことができません。
つまり Cookie や LocalStorage なども利用できない し、リソースをキャッシュさせることもできません。
これにより、後々に使う CSS などを事前キャッシュさせたとしても、計測上でそれらを反映することが不可能です。

Catchpointというサービスではページ遷移を考慮したテストができるらしい（※ 参考サイト）のですが、まだ取り入れられていません。

現在は諸々検討中です。

第５位　スムーズな動画再生の罠

一見良さそうだけど実は…という罠です。

私たちの運営しているサイトでは、コンテンツの詳細ページに埋め込み動画のパーツがあります。
ユーザが再生ボタンを押した際に動画をスムーズに視聴できるよう、動画データの先読みを行っていました。
この「先読み」がまさに問題で、ユーザのページ着地時に 1MBほどの通信が発生 していました。

サイトにおいて動画は重要な要素ではあるものの、100%のユーザが再生しているわけではありません。
また、今の日本の通信網であれば、1MB 程度の先読みの有無による体験の差はあまり感じられませんでした。
そこに加え、一定の人たちは月末の通信量ひっ迫（いわゆるギガ不足）に困っているという事実もあります。

これらを総合的に考慮し、現在では動画データの先読みを廃止しています。

第４位　「いいね」ボタンの罠

いいねどころか普通に悪かった罠です。

経緯は把握できていませんが、サイト内にFacebook公式「いいね」ボタン が設置されていました。
実はこのボタン……結構な曲者なんですよね。「いいね」ボタン設置で発生する通信は以下の通りなのですが

特に一番下の javascript は圧縮されて 111KB、展開後は 487KB と大きなサイズだったりします。
パフォーマンス測定をしたところ、単純にパースするだけでもそこそこリソースを消費しているようでした。

現在は必要最低限の画面以外の「いいね」ボタンは撤去しています。

第３位　A/Bテストツールの罠

親切心が仇になった罠です。

昨今ではサイトグロースのためのA/Bテストが一般的になってきました。
また、A/Bテストをフロントエンド側で実施できるよう支援するサービスも色々と出てきています。
私たちも外部サービスを利用し、フロントエンド側でのA/Bテストを実施しています。

これらの外部サービスを利用する場合、A/Bテストを実現するための javascript をサイト内に埋め込み、画面の表示内容を書き換えます。
しかし、もしこの javascript の読み込みや実行が遅れた場合、書き換え途中の状態が見えてしまって表示がガタつきます。
親切なサービスではこの「ガタつき」を防ぐため、書き換えが終わるまで、画面全体を非表示にする javascript が併せて提供されています。

ただ、この javascript は「読み込みや実行が遅れた場合」であったり、「ファーストビューに対する書き換え」の場合にしかあまり効果がありません。
そして画面全体を非表示にすると Speed Index（サイト速度を表す指標値） のスコアは低下しますし、UX 観点でも悪影響を及ぼします。

現在はなるべく必要がある場合のみ「ガタつき防止」が組み込まれるよう運用しています。

第２位　Lighthouse バージョンアップ の罠

計測ツールに振り回された罠です。

前述の通り計測には Lighthouse を利用しており、専用の環境から定期的に計測を実施する運用をしています
この Lighthouse が今年の5月に メジャーバージョンアップ しました。

このバージョンアップにより、lighthouse における標準の計測方式が変わりました！

以前の Lighthouse ではモバイル環境を再現するために、事前に実行速度や回線速度に制限をかけた状態で計測 が実施されていました。
しかし新しいバージョンでは制限無しで計測したのち、その結果を 独自のアルゴリズムで後処理してモバイル環境での結果をシミュレートする 方式になりました。

この両者でそれなりに計測結果が変わってしまい、一時は 今までの方式でいくか？ 新方式にするか？ と頭を悩ませる羽目になりました。

現在はGoogleに問い合わせた結果を踏まえ、新しい方式の計測で運用しています。

第１位　広告用タグの罠

Web広告に潜んでいる罠です。

広告を運用するにあたり、サイト内にもコンバージョン測定タグなどの様々なタグを設置する必要があります。

……これ以上は詳しく書きませんが、分かる人には分かってもらえるはずです。
他の全ての罠を凌駕する破壊力 を持っていました

終わりに

最後まで読んでいただきありがとうございました。
あまりの悲しみと諸々の関係で最後はお茶を濁しましたが、以上が自分の遭遇した罠でした。
共に速度改善をする方に対して少しでも参考になったり、一緒に悲しみを分かち合えたりできていたら嬉しく思います。

例によってご意見、ご感想や「うちはこんな罠に……」みたいなコメント大歓迎です！