私がサイトの読み込み速度を速くしようと思ったきっかけは
どうもホームページ(記事一覧)で読み込みが他のページよりも明らかに遅いからです。
表示が遅いとユーザーはどうしてもブラウザバックしてしまいがちです。私もある程度待っても表示されないと戻ることがしばしばあります。
サイトの読み込み速度を改善するために私が今回使ったサービスはこちらです。
PageSpeed Insights
モバイル端末やパソコン向けのページのパフォーマンスとページの改善方法を確認できるサービスです。
私も初めて使ってみたので色々調べながらやりました。
フォームに自分が調べたいページのURLを貼り分析をクリックします。これでそのページの速度改善策が分かります。
これが私のホームページの情報です。ページの速度はUnveiledとなっていますがある程度のアクセスがないと表示されないっぽいです。
ちなみにsite:https://~~~というリンクに飛ぶと次のような画面が表示されます。
サイト全体の速度が出てきます。私のサイトの速度はFastでしたが、FCPとDCLという見たことがない単語のせいでよくわかりませんでした。
少しググってみたところ、
FCP ( First Contentful Paint ) とは 直訳すると、コンテンツが最初に表示されたという意味です。その意味から分かるように、Webページのコンテンツが表示され始めた時間のことです。
ある記事を読みたいと思いリンクを押してから、その記事のコンテンツの最初の部分が表示されるまでの時間のことです。大体のサイトはヘッダーやナビゲーションなどが最初に表示されるコンテンツなので、それらが表示されたタイミングがFCPの近似になりえます。
一方のDCL(DOMContentLoaded)は
「DOMContentLoadedは、初期のHTMLドキュメントが完全にロードを完了するためにスタイルシート、画像、サブフレームを待たずに、ロードされ、解析された時間を報告します。」 – MDN。
ちょっと何言ってるかわかりませんね。色々調べて何となく理解したのでそれをまとめます。
あなたがWebページを見るときそのWebページはどのようにして表示されているでしょうか？
簡単な流れを紹介します。
まず利用者(クライアント)がこのページを読みたいというリクエストを送ります。リンクをクリックすることにあたります。
リクエストを受け取ったサーバーはリクエスト通りのデータを送り返します。
そしてレスポンス(送り返されたデータを)を受け取った利用者はそのデータをもとにブラウザ上で表させます。
こうしてWebページを見ることが出来ます。
でDCLとは何かですが、色々送り返されてきたデータの中のHTMLドキュメントが完全に読み込まれた時間です。送り返されてきたデータにはHTML以外にもスタイルシート画像やJSファイルなどあります。それらが読み込み終わった時間は関係ないです。
何となく理解できたところで戻ってもう一度みると、この二つの値の中央値がすべてのページの読み込みのどこに分布されているかで速さが決まります。
上位3分の1以内ならFast 中間の3分の1ならAverage 下位の3分の1ならSlowといった感じになります。
次は最適化をしたいと思います。
最適化してみる
この最適化スコアは何の指標なのかですが、どれだけページのパフォーマンスを改善できるを推定したスコアです。項目は次の2つです。
- スクロールせずに見える範囲のコンテンツの読み込み時間
- ページ全体の読み込み時間
画面全体のコンテンツの読み込みとページ全体の読み込みを速くできる余地で決まります。
スコアは0~100までで算出されGood,Medium,Lowの三段階に分類されます。ちなみに私はモバイルでLowでした。あくまで改善の余地なので遅いという意味ではないです。
スコアが大きいほど読み込みに対する対策が十分になされているということです。
モバイルはLowだったので最適化についての提案を実行してみようかと思います。
今回はサーバーの応答時間を速くしてみようと思います。なぜかトップページだけ1秒以上かかっています。他の記事のページは0.2秒くらいです。
サーバーの応答時間を短くしてみた
サーバーの応答時間が長いといってもどうやって原因を突き止めれば良いか分かりません。
googleの方のガイドには次のように説明されていました。
サーバーの応答が遅くなる要因としては、さまざまな理由が考えられます。たとえば、速度の遅いアプリケーション ロジック、遅いデータベース クエリ、遅いルーティング、フレームワーク、ライブラリ、リソースによる CPU の消費、メモリ不足などです。サーバーの応答時間を改善するには、こうした要因をすべて検討する必要があります。
https://developers.google.com/speed/docs/insights/Server
様々な要因が考えられるそうです。私の場合、ページの読み込みが遅いのが記事一覧の1ページ目と2ページ目のみでした。なんでそこだけ遅いのか不思議でしかありませんでした。
とりあえずF12キーを押してconsole画面を開きます。そしてnetwork画面にします。これでデータの受け取り時間とかが見られます。どのファイルが原因なのか色々調べました。
そしたらTTFBという時間がやたらかかっていることに気づきました。3.26秒もかかっています。普通ならば0.2秒くらいです。
ここでTTFBについて説明すると、リクエスト(クリック)してから最初にバイト(ファイルの一部分)を受け取る時間です。つまりそれまでの時間はサーバー側で色々準備をしています。
この時間が遅いということは、サーバー側で何らかの問題が発生しています。
最初はデータベースの方が遅いのかと疑っていたが、2ページ目以降は特に遅さはない。のでデータベースが原因ではない。
それ以外で違っている点はサムネイルくらいであった。もしやそれかもと思いファイル名に注目してみた。
するとURLに日本語が入っている。日本語が入っているとエスケープして英数字に直すというのをrubyの本で見ていた。これだと思いURL名をローマ字にしてみたものの、結果は変わらず。
うーんどうしたものか。。。
2、3時間ネットで調べるもいいものが見つからない。
あきらめかけていたところあることに気づく。
サムネイルの画像の解像度(px)が画像によって違っている。320×180と480×270の画像二種類ある。
私の記事一覧の画像のサイズは320×180にしているので前者の方でも十分だと思っていたが、consoleで要素を見てみると336×190くらいになっている。320×180では足りておらずサーバー側で何らかの処理かエラーが出ていたと思われる。
詳しくは私の力では分からなかった。
ということで全部のサムネイルを480×270にしてみたところ
やったーーgoodになったー
TTFBも0.2秒くらいに収まるようになりました。
これでめでたしめでたしです。
今回のことで学んだことは画像のサイズに気を付ける必要がある。ということです。
最後に
なんでファイルのサイズが指定のよりも小さいとTTFPが遅くなるのか全く分からなかった。分かったら記載します。
