サイトの高速化を難しく考える前に

iPhone6(LTE)偽装 11.82sec 4.8MB

例えばこのサイトはスマホページで4.8MBもダウンロードしています。
通信環境の悪いところで快適に閲覧できるようなサイトでしょうか？

iPhone6(LTE)偽装 2.8min 83.6MB

このページに関しては13回見るとキャリアの制限に達するというそもそも論外なレベルです。

PC(FTTH) 25.06sec 11.2MB

304 Not Modifiedいっぱい

GoogleAnalyticsより例

見てる間に不要なダウンロードが発生しなければ良いのでそれに合わせてしまえば比較的短く、そして効果的なクライアントキャッシュが出来るでしょう。
もちろんこれは小手先の対応で最終的にはURLを変える対応を行ってTTLは長めに設定するのが良いです。

そのETag適切ですか？

とあるサイトを見ていると304に混じって毎回何故かダウンロードしているものを見つけました。
そこで原因を調べてみるとファイルが更新されていないのにETagが変わるのを発見しました。

ハッシュ値が同じなのにETagが違うファイル

先ほどのリソースのリクエスト数を減らそうでも触れましたがINMではキャッシュで保持しているETagをサーバにリクエストして更新があればダウンロードを行うものです。
そのためETagが変われば更新されているものとしてダウンロードがされてしまいます。

同じファイルなのにETagが違うためボディを取得した例

画像などの既に圧縮されているようなものには効かないですがCSSやjs等のテキスト系には非常に効果的です。︵もちろんベースページも︶
テキスト系のものには適用できるように設定するとよいでしょう

2015/11/02追記
AmazonS3にcssやjsを直接置いているサイトが結構ありますが、gzipの考慮がもれているように思われます。
個人的には画像とかはともかくcss/jsをS3から直接配信するのはオススメしません。︵オリジンとして置くには良いと思います︶
最近jsで1MBを転送しているサイトを見かけまして少しきになりましたので追記しました。

画像のクオリティを調整しよう

JPGは画像のクオリティ(以下q)を調節することでサイズを大幅に小さくすることが可能です。(PNGも圧縮率等調整することで多少小さくすることは可能)
当然ながらqが低ければ画質は悪化しますがその分小さくなります。


q=100の画像のクオリティを下げていった場合のファイルサイズ

しかしq=90ぐらい落としてもwebで使う分には十分な画質が有ります。


q=100 / 368KB(オリジナル 焼肉奢ってくれる人募集しています)



q=90 / 122KB



q=80 / 81.2KB



q=70 / 63.6KB

q=1 / 6.4KB

どれ位サイズが小さくなるかは画像によって違いますし
どの程度のqが必要かはサイトの特性に対する考慮、その他ベンチマークをする必要はありますが普通は90もあれば十分綺麗です。80でもよく見なければ気づきにくいとおもいます。
また当然のことなのですが元々qが低い画像のqを上げた場合も無意味です。

q=1のものを100にした画像 (30.8KB)

もしサイト画像のqが既に90以下で一括で90にあげようとした場合は逆にサイズが増えるでのできちんと調べておくと良いです。

画像のサイズを適切にしよう / サムネを作ろう

当然ですがサイズが大きい画像はファイルサイズが大きいです。
適切なサイズ・クオリティで作成することでページは軽くなります。
先ほどの画像の元サイズを100%として10%刻みでサイズを落としていくとこうなります︵q=100のまま︶


10%刻みで小さくしてみた

なるだけ表示サイズに合わせて画像を生成するべきでしょう。
動的にサイズを指定してサムネイルを作成するMWもあるのでそれとキャッシュを組み合わせるなどしてもよいでしょう。

その写真は本当にPNG(可逆圧縮)が必要ですか？

先ほどの写真(JPG/q=100)をPNG(24bit)に変換するとサイズが大抵の場合膨れます。

もちろん8bit(256色以下)であれば小さくはなります。


PNG8(256Color) / 186KB

ですが個人的にはqを下げたほうが良いと思います。
もちろんアイコン等のtooltipはPNG8が良いでしょう。

PageSpeed Insightsを活用しよう

PageSpeed Insights

Google先生が割と教えてくれます。
とりあえずかけてみて参考にするとよいでしょう。

ApacheのMPMの違いとリバースプロキシでのキャッシュ

ApacheでPHPを使う場合大体mod_phpを利用すると思いますがこれはPreforkで動作します。
Preforkは1プロセスが1リクエストを捌くものです。
プロセスはそれぞれで独立したメモリ空間を持つためスレッドで動くworkerに比べ同時に捌けるリクエスト数は少ないです(workerは1スレッド1リクエスト)
これがなんの問題があるかというと画像等の静的リソースをPrefoekで動いているサーバでレスポンスしてしまうことです。
通常、ベースページに紐づく静的リソースは多いため大量のリクエストが来ます、静的なので高速にレスポンス出来ると思いますが無駄にサーバリソースを使っているのは確かです。
そのため可能であれば静的リソースはworkerなサーバでレスポンスして、動的コンテンツのみをpreforkなサーバで返したいところです。
ドメインを分けるのも手ですが、それが難しいばあいはリバースプロキシを入れるのも手です。
リバースプロキシで静的リソースをキャッシュしてしまいpreforkなオリジンサーバにリクエストがあまり来ないようにすればよいでしょう。
また、これは通信環境が悪くて遅いクライアントの影響を小さくする対する対策にもなります。
リバースプロキシのMWはNginxやApacheやVarnishを使うと良いと思います。僕はVarnishが好きです。 

その動的コンテンツは更新されますか？

サイトにもよると思いますが、リクエストしても毎回同じコンテンツを返す場合はリバースプロキシでキャッシュすることを検討するのもよいでしょう。
高コストなLLでページを生成する必要がなくなるため、突然buzzっても割と耐えられるようになります。
また全体でサーバコストを減らすことも可能でしょう。
何かしら情報を取得するためにLLを動かす必要があるというのであれば、それはjsで代用ができないかとか検討するのもよいでしょう︵もしくはESIを検討するのもよいでしょう︶
動的コンテンツをキャッシュすることで一気に軽く、そしてコストを減らせるでしょう。 

サーバ情報を隠そう

パフォーマンスとは関係ありませんが
単純に危ないので不要な情報(特にバージョン情報)は消すようにしましょう。

phpのバージョンまで出てる

HTTPS(SSL/TLS)の設定を確認しよう

少し前に話題になったPOODLEやHeartbleedなど︵直近だとLogjamやFREAK︶HTTPSに関わる脆弱性をよく聞きます。
いろいろあるものの今自分のサイトの状態がわからないのであればとりあえずGlobalSignかQUALYS SSL Labsの診断をやってみましょう。
GlobalSignの診断はSSL Labsのを元にしているのですが日本語なので分かりやすいです。
とりあえず指摘事項を見つつサーバ設定を直していくと良いでしょう。︵セキュリティだけではなくパフォーマンスに影響する項目もあります︶


SSL使用をアピールしてるものの設定は・・・

SSL Labsのほうだとどのような環境で見れるかも確認できるので両方みると良いと思います。


SSL Labsは環境のシミュレーションをやってくれる

古いAndroidやガラケーをサポートする必要がある場合などサポートするべき環境などによって設定は変わるのでAを取るのは難しいのですが可能な限り不用意な設定等は排除したいものです。

そのVaryヘッダ本当に大丈夫ですか？(2017/02/17追記)

CDNやリバプロ等のクライアント・サーバ間でキャッシュを行う場合きちんと考えて設定したいVaryというヘッダがあります。
多くの場合はVary: Accept-Encodingが指定されていることが多いです。
このヘッダが意味するところは
Accept-Encodingによって内容が変わるので、中間でキャッシュする場合はクライアントから送られるAccept-Encodingヘッダ毎にキャッシュ持ってねということです。
cssやjsはgzip圧縮して転送したりしますが、gzipに対応していないクライアントも存在します。
もし、Varyを指定してない状態で、先にgzip圧縮されたcssが中間でキャッシュされ、gzip非対応のクライアントでリクエストをするとgzipなcssがレスポンスされて困ってしまいます。
そのためVaryを使うことでこのURLはAccept-Encodingで内容が変化することを宣言しているわけです。

なるほど、これは便利だということでUser-Agent(以下UA)を指定をするサイトもあるようです。
おそらくPC・スマホ・ガラケーでも同一URLで処理したいということなのかなと思いつつ
これは非常にもったいない設定です。
なぜならUser-Agentは非常に多いため、キャッシュのヒット率が低下します。︵もちろんパフォーマンスも︶
わかりやすいところだと、AndroidのUAは機種名が入ってたりします。
つまりその機種毎・そしてバージョン毎に個別のキャッシュが作られてしまいます。
もちろん意図したものであれば問題ないのですが、大抵の場合はなんとなく設定されているのでは考えてしまうものが多いです。
上記は割と大きな音楽・本の配信サイトなんです。見たところ画像をパラメータによって動的にリサイズしておりそれをキャッシュしようとしていますがVaryにUAを指定しています。
当然なのですがUAを変えてリクエストをしたところMissになりました。
パラメータで生成条件を変えているためおそらくUAでユニークである必要はないと考えられ、そもそも外すか︵画像は既に圧縮されてるのでgzipがあまり効かないためそのまま送ることが多い︶Accept-Encoding指定でよいのではと思います。
ちなみに、CDNやミドルウェアによってはこのあたりを賢く制御(PC/スマホで個別にキャッシュを持つ︶などもできたりします。
CDNやキャッシュを使う場合は、Varyに気をつけてみてください。

︵小ネタ︶クライアントとCDN/リバースプロキシでのキャッシュの違い

さて、クライアントでのキャッシュとCDN/リバースプロキシでのキャッシュは何が違うのでしょうか？
すごく簡単にいうとそのキャッシュが参照されるクライアント数が1なのか多なのかだと考えています。
当然ながらクライアントに格納されているキャッシュは他のクライアントに参照されません。
そのため極端なことを言ってしまえば、サイトがほぼ100%直帰されて再訪もないのであればクライアントのキャッシュをいくら頑張っても無意味です︵そんなサイト無いと思いますが︶
対するCDN/リバースプロキシでのキャッシュはその場合でもうまく動きます(ちなみに/としていますがCDN=リバースプロキシと言ってるわけではないです併用するのが大事です)
両者の違いを意識してうまく併用できると良いかなと思います

まとめ

もちろんサイトの状況によっていろいろ変わると思いますが
これらの対策をやるだけで割とサイトのパフォーマンスは良くなると思います。
また、今回紹介したのは割と基本的なところで他にもいろんな高速化の方法があります。
他にも最低限気にすべきこともありますがパフォーマンスとはあまり関係ないので削りました。︵なんとインターネット上にmysqlのポートを開けてるとこがありました・・︶
みなさんのサイトが速くなればいいなーとおもってます。
参考になれば嬉しいです。

参考リンク

パフォーマンスの最適化
ESIの効果と気をつけた点
Varnishを多段にする利点と注意するところ
SSL証明書のインストールチェックはどのサイトを利用すべきか
SSL のパフォーマンスでお嘆きの貴兄に
Webサーバ勉強会#5に参加してきましたよ

Tweet