Webサイト（ページ）高速化の方法について

2018/7/17

SEOの一環として、ページの表示速度を上げる主な方法をご紹介します。

Googleは「2018年7月9日からページの表示速度をランキング要因にする更新を始めた」と公式ブログで明かしました。（下のURLの追記部分）
https://webmaster-ja.googleblog.com/2018/01/using-page-speed-in-mobile-search.html

ここでは、PageSpeed Insights というGoogle製のツールで検証される項目をもとに、ページの表示速度を速める方法をご紹介します。

静的ファイルの圧縮

CSS、JavaScriptの圧縮

CSSやJavaScriptなどの外部ファイルは基本的に圧縮しますが、「圧縮」といってもいくつか方法があります。

まず、改行や不要なスペースをなくす方法です。
改行、スペースとも、それぞれ1つにつき1バイトずつ容量を使うため、空白や改行をなくすことで手軽に容量を削減できます。

次に、ファイル圧縮技術を使って圧縮（エンコーディング）します。
圧縮といえば zip形式が一般的ですが、Web上では基本的に「gzip」という形式を使用します。
手元の圧縮ソフトなどで処理したものをサーバー上に置いても良いですが、Webサーバーが Apache や Nginx のようなものでしたら、サーバー側で自動的に圧縮するようなオプションが利用できます。

加えてJavaScriptの場合、パッキングという手法もあります。
例えば /packer/ といったツールでJavaScriptの変数名などを単純化し、さらに文字数を減らす手法です。
複雑なスクリプトの場合、不具合が出たり逆に肥大化する場合もあるため、検証して効果がありそうなら使ってみるのも良いかもしれません。

最近では Webpack や Gulp などの「タスクランナー」と呼ばれるツールがあり、これらはスクリプトを自動的に圧縮したりまとめたりしてくれますので、開発者でしたら覚えておいて損はないと思います。

また、CSSやJavaScriptだけでなく、HTMLに関しても、空白や改行は容量を消費します。
可能であればHTMLもすべての改行を排除かつgzip圧縮すると良いでしょう。

画像の圧縮

JPEGやGIFなどの画像は、すでに圧縮されている形式のため、再圧縮の必要はありません。
しかし、これらの画像にもメタデータ（例えば概要文や位置情報など）が付加されている場合があり、そういったものを削除することで容量が減らせます。
また、JPEGminiのような既存の圧縮効率を上げるツールなどもあり、より削減できます。

写真のような画像以外に、図形のような単純な画像でしたらSVG形式にするのも良いでしょう。
SVG形式の実態は、基本的に線と面のデータ配置情報で構成されたXML形式の文字です。
1ピクセルごとに色情報をもつ一般的な画像とは違って情報量が単純で少ないため、非常に軽いデータにできます。
加えてSVG形式は拡大・縮小しても、一般的な画像のようにギザギザになったりせず劣化しないため、近年のRetinaディスプレイ等には最適です。
例えばサイトロゴなどは、図形で表せるようなものでしたらSVG画像にするのが良いと思います。

ブラウザキャッシュの利用

ブラウザには、過去に閲覧したURLのデータをキャッシュ（一時ファイルに保存）しておく機能があります。
これにより、一度見たページなどは次回は高速に表示できます。
ただし、サーバー（またはプログラム）側でキャッシュさせる指定をしていなければキャッシュしてくれません。

ブラウザにキャッシュさせる場合、無効になるまでの期間が設定できます。
この期間が長いほど次回閲覧時に高速に表示できる確率があがりますが、「内容を更新したのに変わらない」などの弊害も生まれます。
こういった際に一般的に用いられる手法としては「URLを変える」方法です。
例えば /style.css?version=1 と /style.css?version=2 は、同じファイルですが別のURLです。
ブラウザキャッシュはURL単位ですので、こういった方法でキャッシュを更新できます。

画像に関しては特に容量が重いため、積極的にブラウザキャッシュを利用すると良いでしょう。
画像でも、同じURLで内容が変わるような運用をしているケースもあると思いますが、できれば更新するたびに違うURLになるような仕組みにした方が良いと思います。

レンダリングブロックCSS

ブラウザがWebページを表示する際、特に指定がなければHTMLソースの上から順に外部ファイル等が読み込まれていきます。
ここで、例えば最初にブラウザ画面に表示される部分だけでも先に読み込んで表示（レンダリング）することができれば、他の部分が読み込み終わる前に閲覧（情報提供）することができます。
表示を妨げる（ブロック）部分を後回しにして、体感的に高速に見せる手法を「レンダリングブロックCSS（対策）」と呼びます。
表示に関する対策ですので、主にCSSに対する手法です。
詳しくは以下のGoogleの記事も参考にしてください。
https://developers.google.com/web/fundamentals/performance/critical-rendering-path/render-blocking-css

レンダリングブロック対策はデザインや開発方式によって取れる対策がそれぞれですので、決まった方法があるわけではありません。
根本的な高速化を考える場合、既存サイトならサイトデザインの変更を、新規サイトならワイヤーフレーム時点から視野に入れると良いでしょう。
また、もしデザインの変更から考える場合、最初に表示される画面の要素自体を減らすことも考慮します。

ページ表示の応答時間を削減

ここまでは主に「表示側」の対策でしたが、本章は「サーバー側」の対策です。
「応答時間」というのは、ユーザーがURLに訪れ、サーバーがそれに応答する（HTMLを返す）までの時間です。
この部分が遅くなるのは様々な要因が関係してきます。

例としてGoogleのヘルプページを参考にすると、以下のようなものがあります。

速度の遅いアプリケーションロジック
遅いデータベース、クエリ
遅いルーティング、フレームワーク、ライブラリ、リソースによるCPUの消費
メモリ不足

パソコンをお使いであれば、長く使うにつれ動作が遅くなってくる経験をしたことがあるかもしれませんが、Webサーバーも同様です。
Webサーバーが動作している機器が経年劣化で遅くなる場合もあります。

このように、ページ表示の応答時間を短くするという施策には終わりがありませんので、重要になってくるのは現状の計測と分析になってきます。
まずは冒頭で言及した PageSpeed Insights などのツールを使用して現状を把握し、改善点を探るところから始めましょう。

おわりに

ページの表示速度をランキング要因にするというGoogleの決断は「表示速度が速いことはユーザーの利便性につながる」という確証から来たもので、個人的にも賛同しています。
しかし、表示速度を上げるのは一見簡単そうに思えるかもしれませんが、一筋縄ではいきません。
開発側の効率や、Webの場合はコンテンツが流動的なためキャッシュするのが難しい場合があったりするためです。
場合によってはサーバーの引っ越しなども視野に入れる必要があるため、コストや妥協点を考えつつ、段階的に行っていくのが良いと思います。