Webアニメーションとページ表示速度（１）
担当案件でこんな話が持ち上がった
とあるコーポレートサイトリニューアルプロジェクトで先方の担当者から、プロジェクト開始当初にこんな話をもらった。
「うちの社長は、サイトのページ表示速度にとてもうるさく、できればこのプロジェクトで作るコーポレートサイトはGoogleのPage Speed Insightで90点を目指したい」
ページスピードの基準を設けるのに、よく利用するGoogleのPage Speed Insight。毎回サイト構築時に確認するのはよくある話だが、90点と言うのはなかなか難しく、ウェブ業界の界隈で働いている人は、よくご存知の阿部寛さんのHPや、 デジタル庁のサイトなど、とにかくシンプルなサイトで高得点が出るケースが多い。なかなか挑戦的ではあるが、Page Speed Insightで90点を取得できるようなサイトを作ると言う事は、技術を監修する者としてはとても挑戦的であり、魅力を感じていた。
しかし、その2ヶ月後、ワイヤーフレーム作成時にこんな話が出た。
「うちの会社は、最先端の挑戦的なことをやっている会社だから、それがわかるようにメインビジュアルは、こだわってかっこいいアニメーションを実装させたい。」 いや、ちょっと待ってよ。品質基準でPage Speed Insightで90点以上取ることを目指すと定義していたけど、ゴリゴリに実装されたWebアニメーションでPage Speed Insightで90点も出るのだろうか、、、。
Webアニメーションは、cssやJS，WebGLなど様々な実装方法があるが、実装すると体感的なページスピードは遅くなると言われている。
実際、Webアニメーションを実装しているサイトは、ローディング画面を設け、体感的なページスピードが遅く感じないような工夫をよく施している場合もある。
最近はWebアニメーションの技術も発達し発展し、WebGLのように惹きつけられるようなインタラクションがどんどんサイトに実装されてきているので、担当者からそういったかっこいいアニメーションを実装したいという要望が多いのは当然である。その一方で、Webアニメーションは実装するとページスピードが遅くなったり、閲覧環境によっては動かなかったりするところが課題である。つまり、アニメーションを実装する=ページスピードが遅くなると言うのは、比較的Webの業界では当たり前のことであり、かっこいいアニメーションとページスピードを考慮した実装、両方ともかなう実装方法と言うのはなかなか難しい。 とは言え、担当者レベルではかっこいいアニメーションを実装したいが、上層部や会社の方針ではページ表示測度やSEO対策などを必須としている事はよくあることで、その両面を適した実装というのが、理想的ではあると思う。
技術を監修する立場としては、このリクエストはかなり頭を悩ませる。
しかも、当然だが予算も期間も限りがある。ひたすら研究し、お金を費やし検証を続ければ、もしかすると実装は可能かもしれないが現実はそうはいかない。
今回は、私がWebアニメーションとページ表示速度について、悶々と考えて調べた結果を2回にわけて共有したいと思う。
Page Speed Insightsとは
Page Speed Insightは、Googleが提供しているWebページの読み込み速度を測定するツールで、Webサイトの構築時や公開時によく確認する制作会社が多い。
Page Speed Insightはモバイル、パソコンそれぞれで確認したときの表示レイアウトに対応し、サイトのURLを入力すると、以下のようなスコア表を出してくれる。
なぜ、ページ表示速度が早いことが重要なのか
ページ表示速度はサイトのUX（ユーザー体験）とSEOにつながるとよく言われており、表示速度が遅ければ遅いほどユーザー離脱率は高くなると言われている。
Googleが2017年に発表したデータだと、ページの表示速度とページ離脱率は以下のようなつながりがあると記載している。
表示速度が1秒から3秒まで遅くなると、直帰率は32%増加する
表示速度が1秒から5秒まで遅くなると、直帰率は90%増加する
表示速度が1秒から6秒まで遅くなると、直帰率は106%増加する
表示速度が1秒から10秒まで遅くなると、直帰率は123%増加する
ページ表示速度がが早ければ早いほどページ離脱率は低いと定義している一例だ。
上記の記事をGoogleが発表したのは2017年だが、2018年には検索順位を決める要素にページスピードも取り入れると正式に発表した。
これにより、ページ表示速度はUXだけでなく、SEOにもつながるということがはっきりと明文化された形になり、ページスピードはサイトオーナーが懸念すべき項目の筆頭になりつつあると言っても過言ではない。
実際のページスピードや、サイト公開後の検索順位については、ネットワークや体感的なものも含まれるため、実際公開してみないとわからないものだが、開発時にページスピードの品質が問われている場合、Page Speed Insightの点数を品質定義に利用することができる。
つまり、ページ表示速度を問われるサイトの場合、Page Speed Insightで高得点が取れるような実装が必要なのだ。
Page Speed Insightで高得点が出るサイトとは
Page Speed Insightで高得点を出すためには、様々な実装の工夫が必要である。
Google自体もPage Speed Toolsでいろんな実装方法を紹介している。今回はその中の一部を紹介したいと思う。
各リソースファイルの圧縮
まず、よく言われるのが各リソースファイル（HTML/CSS/JavaScript）の圧縮化だ。
各リソースファイルを記述する際に、コーダーやフロントエンドエンジニアは改行やスペースなどを利用して、編集しやすいマークアップを行うが、この改行やスペースはファイルサイズの容量が増える原因となる。
そのため、納品する前は削除することを推奨されている。
最近は業務効率化のため、コーダーはコーディングする際にタスクランナーツールを使う場合が多いと思う。タスクランナーツールは圧縮（min）ファイルをかんたんに生成してくれるので、なるべくminファイルを生成する設定を行いページ容量の削減を心がけたほうが、Googleのサイト好評価につながる。
読み込むCSS、JSファイル数を減らす＆不要な記述を減らす
上述のリソースファイルの圧縮化の話の延長だが、複数のCSSファイルやJSファイルを読み込んでいる場合は、一枚にまとめたほうがいい。
ページを表示させるためには、head要素内に書かれた記述からブラウザが読みに行くことになるが、head内で読み込んでいるファイル数が多いと、ブラウザも読み込むファイルが多いため、自ずと表示が遅くなってくる。
本を読んでいる時に、ページ数が多いと読了まで時間がかかるが、その感覚と同じようにブラウザもファイル数が多いと表示が遅くなる。
なるべくファイルは一枚にまとめた方がいい。
特にJSは多くのオープンソースのライブラリを読んでいるケースがあると思う。これもタスクランナーツールを利用し、ファイル数を権限させることを推奨する。
また、ファイル内の記述が多いと、それもブラウザが読み込む記述が多くなるため、なるべく不要な記述は減らしたほうがベストと言える。
画像を最適化
画像は、ページの総容量の大半を示すと言われており、更に最近は高解像度うのRetinaディスプレイにも対応するように、実際表示する画像サイズより大きい画像を埋め込むケースも多々増えてきている。
しかし、大きい画像は当たり前だが画像の容量が大きい。さらに、画像が高解像度の方が美しく見えるため、運用担当者がCMSなどで画像をアップロードする際に高解像度の画像を利用したりするケースも多々増えてきている。
しかし、実際の表示する画像サイズより大きい画像を埋め込んだり、高解像度の画像を埋め込むと、その画像を読み込むためにページ表示速度が遅くなる。そのため、画像は表示サイズに適したサイズで用意し、圧縮ツールなどを利用して、画像を最適化する必要がある。
画像ファイルの遅延読み込み
画像の遅延読み込み（スクロールと一緒にふわっと出てくる方法）は、初回ページ読み込み時に画像を表示させないため、ページスピードが早くなると以前から言われていた。
更に、2020年にGoogleが定義したUXの指標である「CoreWebVitals」の中で、初回表示時に読み込むファイル容量が少ないほど良いということが明言化された。IEのサポートが切れた現在では、画像の遅延読み込みは全ブラウザで実装可能であるので、採用することが良いとされる。
ブラウザのキャッシュを利用する
ブラウザには過去に表示したページの情報を残しておくキャッシュという機能がついていて、これを利用すると表示スピードが早くなるのでよく対策として利用される。最近はブラウザーとサーバの間にCDN（Contets Delivery Network）というキャッシュをためておくネットワークを介しているサイトも多く、重要視されているのがよくわかる。
Page Speed Insightには「改善できる項目」というのが表示されるが、これに「ブラウザのキャッシュを活用する」と表示された場合、サーバの設定や.htaccessの設定を確認した方がよい。
運用面でキャッシュが残っていると情報が更新されないなどの障害はあるが、キャッシュを利用することでページ表示速度が早くなることはよく言われていることである。ページ表示速度を気にするのであれば
必ず設定したほうがよい。
Webアニメーションを実装していると高得点は難しい
Page Speed Insightに高得点を出す実装方法を紹介してきたが、Webアニメーションを実装する場合、上記をすべて実装したところで、そんなに高得点が出ないのが実態だ。
例えば、それぞれの実装方法はすべてアニメーションの障害になりやすい。
各リソースファイルの圧縮
→アニメーションの記述のソースコード自体が長くなるので、実装してない場合に比べて圧縮したところで容量が重くなるケースが高い。読み込むCSS、JSファイル数を減らす＆不要な記述を減らす
→アニメーションはthree.jsやgsap.jsなどのライブラリを利用する場合が多く、読み込むJSライブラリが複数ある場合も多いため、複数のJSファイルを一枚に纏めたところでファイルの総容量が高い場合が多い。画像を最適化
→画像自体が拡縮するアニメーションなど実装している場合も多いため、どこに基準を合わせるべきか難しい。表現を考えると画像表示が一番大きい時に合わせるべきだが、コンテンツが大きさがストップしたときにPage Speed Insightが走る場合が多く、それだと高い点数が出ない可能性がある。画像ファイルの遅延読み込み
→そもそも遅延読み込み自体が表現の邪魔になりやすい。
おそらく他にも理由があると思うが、様々な理由から、Webアニメーションとページ表示速度の関係は反比例な関係にある。
一体どんな実装方法だったら、表示速度が早くなるのか、、
私は様々な技術を使ったアニメーションを実装したサイトをPage Speed Insightにかけてみた。
今回、私が一番共有したいのは、この様々なサイトをPage Speed Insightにかけた結果なのだが、前提として、アニメーションとPage Speed Insightの相性の悪さを説明していたら、5000文字を超えてしまった。。。
noteの文字数は無制限だけど、だいたい読みやすいのは2000文字程度らしい。
UXは大事なので、本題は（２）で書きたいと思います。。。