このページは、外部サイト
CSS Nite公式サイト の情報をRSSフィード経由で取得して表示しているため、記事の一部分しか表示されていなかったり、画像などが正しく表示されなかったり、オリジナル記事が意図したデザインと異なっていたりする場合があります。
完全な状態のオリジナル記事は 「
CSS Nite LP58フォローアップ（5）阿部 正幸さん」 からご覧ください。
2018年9月29日に都内で開催したCSS Nite LP58「Coder’s High 2018」のフォローアップとして、阿部 正幸さん（モチヤ）の『Webサイト表示速度改善手法』セッションのスライドなどを公開します。
ハンズオンで学ぶBootstrap 4の基礎
阿部 正幸さん （Mochiya）を講師にBootstrapの基礎と、実際にプロとして使うためのノウハウをセミハンズオン形式で学びます。
- 1月10日[木] 19:30-21:30
- https://cssnite.doorkeeper.jp/events/85093
メッセージ、補足など
CSS Nite LP58 Coder's highに参加いただきました、皆さまありがとうございました。
Webサイトの高速化に登壇させていただきました、モチヤの阿部と申します。
セッションでは若干緊張しており、伝えもれてしまったことがありますので、こちらでフォローアップさせていただきます。
今回のセッションで一番伝えたかったこと
今回のセッションで一番お伝えしたかったことは、Webの高速化を行うには、なぜ遅いかを知るための原因調査がもっとも重要です。
原因を調査し高速化の対策を実施します。
速度調査ツール
まずはバックエンドに原因があるのか、フロントエンドに原因があるのかの大雑把な調査を行うためには、速度調査ツールを使うと良いでしょう。
バックエンドに原因がある場合
今回私のセッションでは主にバックエンドの施策の話をさせていただきました。
バックエンドで重要になるのが、キャッシュと、データベースの効率化で、下記の対策があります。
- サーバー引っ越し（スペックアップ）
- サーバー内部キャッシュを入れる
- データベース設計見直し、キャッシュを入れる
- データベースインデックス作成
「サーバー引っ越し（スペックアップ）、サーバー内部キャッシュを入れる、データベース設計見直し、キャッシュを入れる」 は、インフラエンジニアが必要ですので、今回のセッションは説明を除外させていただきました。
データベースインデックス作成について
データベースのレーコード数が多い場合、データベースインデックスを作成することにより高速になることが多くあります。
インデックスの確認や作成は、レンタルサーバーでも利用ができる、phpMyAdminからでできます。
インデックス作成時の注意点
- 必ずテスト環境で行う
- インデックス作成後は、しっかり検証を行う
- CMSのコアファイル、モジュール、Pluginのソースコードは変更しない
セミナー中は、気軽にインデックスの作成をしてみようと捉えてられてしまような発言をしてしまいましたが、インデックスの作成はメリットもありますが、デメリットも存在ます。
インデックス作成の目安は、スロークエリ（Slow query）を使って、遅いSQLの箇所を特定し、そのSQLのWHERE（検索条件）に対して行うのが有効です。
多くのシステムは適切なインデックスが作成されており、検索を高速に行っています。
またSQLの書き方によっては、インデックスを作成しただけでは早くならないケースも存在ます。原因がSQLにあると分かった時点で、一度エンジニア相談してみると良いでしょう。
インデックス作成のデメリットについて
上記でインデックス作成は必ず検証をしてくださいとお伝えしたのは、デメリットも存在するからです。
デメリットは下記の通りです。
- レコード数が少ないと速度は変わらない
- SQLの書き方が悪いと速度は変わらない
- データ追加時の動作が重くなる
- データベース容量が増える
検証
様々な施策を行ったあとは負荷をかけて、速度検証を行うことが重要です。
Apache bench
Apache benchはWebサーバーの性能をしらべることができます。
Macの場合はターミナル画面を起動し下記のコマンドを実施してください。
ab -n 250 -c 50 http://example.com/
- -n : トータルで発行するリクエスト数(250リクエスト)
- -c : 同時接続数(50同時接続)（最初は少ない数値で実施し、少しづつ負荷を上げる。共用サーバーで高い負荷をかけすぎないでください。）
- Failed requests : エラーの数ですので、ここが「0」だと良い結果です。
- Requests per second : 1秒間に何リクエスト応答できたかの数値です。高い数値の方が良い結果です。
LOAD IMPACT
LOAD IMPACTは、1日5回までの検証が無料で行うことができます。
- Vus : バーチャルユーザー数
- r/s : 1秒あたりのリクエスト数
- Response time : 応答時間
質問の回答サーバーをホスティングで運用していて、.htaccessで、なかなかキャッシュコントールやgzipがやりたくてもできない場合はどうすれば良いか。
昨今のホスティングはデフォルトでgzip圧縮配信されています。もしサーバーが対応していない場合は使えませんので、ウェブサーバーの引っ越しを検討してください。
ブラウザキャッシュについては、ウェブサーバー側でデフォルトの設定がよく入っていますので、ChromeのDevToolsから確認をしてみてください。
（確認方法スライドに追加いたしました）
入っていない場合は、.htacessに下記を追記することで、追加できます。
<Files ~ ".(gif|jpe?g|png|ico|svg)$">Header set Cache-Control "max-age=1209600, public"</Files>
キャッシュのクリア方法
キャッシュのクリア方法は、キャッシュの設計と同じくらい重要です。
理由は、キャッシュのクリアタイミングが適切でないと、お客様から「記事更新したんだけど反映されない」と必ずクレームに繋がります。
ですので、記事が更新されたら、同時にキャッシュがクリアされるようにシステムを設計する必要があります。
例えばWordPressと、CDNを導入している場合は、WordPressの記事が更新されたことをフックにCDNのキャッシュをクリアするAPIをたたいて削除します。
DBの内部キャッシュを使っている場合も同様に、記事が更新されたら、DB内のキャッシュをクリアするようにプログラミングしておきます。
Lazy Loadの画像遅延読み込みに関してSEOでは非推奨と聞いたがどうなのか。
Lazy Loadは、コンテツサイズが大きいものに関して使うと有効です。
例えば動画をトップに表示したい場合、実案件で下記のような要件がありました。
- [実際にあった要件：動画コンテンツ]
最初の読み込み時は静止画を表示しておいて、非同期で動画読み込み、動画の読み込みが終わったら、静止画と動画を切り替える。 - [実際にあった要件：画像コンテンツ]
画像の読み込みはスマホ用の画像（軽量）を初めに読み込んでおいて、PCの場合はPCサイズ用の適切な画像をあとから差し込む。
スマホファーストの場合は有効な手段で、SEOには影響しません。
デメリットとしては、PCの場合は別途で通信が発生してしまいます。しかし昨今のサーバー環境はHTTP2や、画像圧縮での配信など、ものすごく画像数が多くない限り問題になることは少ないです。
遅延読み込みがSEOで非推奨な理由は、Googleは遅延読み込みをした画像を検索用インデックスに登録できないからです。
その画像がSEOに必要ない場合は、遅延読み込みをしても問題ないですし、表示速度を落としてまで、画像を沢山読み込みたいということも無いでしょうから、適切に導入しても良いのではないでしょうか。
さいごに
イベントに参加いただきました皆さまありがとうございました、また皆さまにお会いできることを楽しみにしております。
下記は私のソーシャルアカウントです、お気軽にフォローいただけると幸いです。
Facebookいいね!の多い記事
Twitterで言及の多い記事
はてなブックマーク人気記事