PageSpeed Insightsでカラーミーサイトを改善する
PageSpeed Insightsで、ウェブページの表示速度とパフォーマンスを分析し、改善方法について書きました。
SEOにも影響があるということで、気になる方も多いかと思います。
以下の内容は、カラーミーショップ
の共通ページ・トップページを前提にしています。
カラーミーで改善できること・できないこと
PageSpeed Insightsで改善する、といっても、できること・できないことがあります。
カラーミーショップ上のショップサイトにおいては、ユーザー側ではサーバー周辺の改善はできません。
- サーバーキャッシュやサーバー速度
- カラーミーショップ
のサーバー側で読み込む一部ファイルの除去
それらを除いても十分改善できる余地はありますので、順次、改善点を見ていきます。
PageSpeed Insightsによる現状分析
今回、改善ページに取り上げるのは、当店配布の無料テンプレートのトップページです。
オーソドックスなサイトデザインになっていますので、他のカラーミーショップでも改善の参考になると思います。
まずは、皆さんご存知の「PageSpeed Insights」で、サイトの現状分析を行います。
トップページのURL（https://naeco2.shop-pro.jp）を入力して分析ボタンをクリック。
もっとも重要な改善箇所はパフォーマンスの評価と思います。
パフォーマンスは60程度、時間帯によっては40-70台くらいの幅で数値が出ました（カラーミーショップ的にはふつうくらいかなと思います）。
数値に振れ幅があるので、複数回、分析してみて傾向を見てみましょう。
改善すべき点は「診断」に挙がっています。上から順番に一つずつ見て検討します。
カラーミーのトップページの場合
パフォーマンスの評価ポイントはいくつかありますが、おもに
ファーストビュー（スクロールせずに最初に見える部分、First Contentful Paint, FCP）と
もっとも大きなコンテンツ要素（Largetst Contentful Paint, LCP）をいかに速く表示するか、
誤クリックを引き起こすような遅れたタイミングで発生するレイアウトシフト（描画によってカクッとレイアウトがずれること、Cumulative Layout Shift, CLS）が問題になります。
これらに大きな影響を与えている要因は、トップページにありがちな、Webフォントの読み込みと、スライドショーの読み込みです。
これらを取り払えば80-90台もかんたんに出ますが、使い勝手も見栄えも悪くなりますので、バランスよく対応します。
レンダリングを妨げるリソースの除外
上画像内の、colormekit.css、index.css、jquery.min.jsの３つは、カラーミーショップのサーバー側で挿入されるリソースになりますので、ユーザー側でコードをいじったり、読み込みタイミングを変更したり、JavaScriptを書いて読み込まなくすることはできません。
それに対して、Google Fonts（Webフォント）は対応可能です。具体的には以下の通りです。
３行目のプリロード（rel="preload" as="style"）します。読み込み後には、onload以降のJavaScriptが実行され、CSSが効くようになっています。
４行目のnoscriptは、JavaScriptが使えない環境でCSSを適用するためのものです。
Googleフォントの場合
<link rel="preconnect" href="https://fonts.googleapis.com" />
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
<link rel="preload" as="style" href="https://fonts.googleapis.com/css2?family=M+PLUS+Rounded+1c:wght@500&family=Noto+Sans+JP:wght@100..900&family=Roboto:wght@100..900&display=swap" onload="this.onload=null;this.rel='stylesheet'" />
<noscript><link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=M+PLUS+Rounded+1c:wght@500&family=Noto+Sans+JP:wght@100..900&family=Roboto:wght@100..900&display=swap" /></noscript>
これだけで、大幅改善（4500ミリ→300ミリ）しましたが、パフォーマンスの数値はほぼ変化なしでした。
「最大コンテンツの描画」要素
「最大コンテンツ」とは、Webページで最も大きな画像や動画、テキスト要素などのこと。
よりよいユーザー体験を提供するために、最大コンテンツを描画するまでの時間を短縮する必要があります。
| Time to First Byte（TTFB） | ユーザーがページの読み込みを開始してから、ブラウザが HTML ドキュメント レスポンスの最初のバイトを受信するまでの時間。詳しくは、TTFB の詳細をご覧ください。 |
| 読み込み遅延 | TTFB と、ブラウザが LCP リソースの読み込みを開始した時点との差分。 |
| 読み込み時間 | LCP リソース自体の読み込みにかかる時間。 |
| レンダリング遅延 | LCP リソースの読み込みが完了してから LCP 要素が完全にレンダリングされるまでの時間差。 |
上画像によると、レンダリング遅延がおもな原因で、LCPの描画が遅れているという指摘がされています。
CSSやJavaScriptを読み込むと、通常はレンダリングがブロックされますので、工夫が必要になります。
外部ファイルをプリロードする
レンダリングのブロックを回避するために、slick（スライドショー機能）は、プリロードします。
JSファイルとCSSファイルの計３つ。
トップページHTMLの一番上に書きます。
slickの３つのファイルをプリロードする
<link rel="preload" href="https://img.shop-pro.jp/tmpl_js/89/slick.min.js" as="script" crossorigin="anonymous" />
<script type="text/javascript" src="https://img.shop-pro.jp/tmpl_js/89/slick.min.js" defer></script>
<link rel="preload" as="style" href="https://img.shop-pro.jp/tmpl_js/89/slick.css" onload="this.onload=null;this.rel='stylesheet'">
<link rel="preload" as="style" href="https://img.shop-pro.jp/tmpl_js/89/slick-theme.css" onload="this.onload=null;this.rel='stylesheet'">
<noscript>
<link rel="stylesheet" href="https://img.shop-pro.jp/tmpl_js/89/slick.css">
<link rel="stylesheet" href="https://img.shop-pro.jp/tmpl_js/89/slick-theme.css">
</noscript>slickのlazyLoad
slickはスライド画像の読み込みタイミングを後ろにずらすパラメーター（lazyLoad: progressive）があります。
たくさんのスライド画像を読み込ませるには、時間がかかるため、あとから読み込ませる方がよい場合があります。
パラメーターの使い方は、スライド画像を指定するHTMLを変更する必要があります。
srcを取り払って、data-lazyに書き換えれば、読み込みタイミングを後にずらしてくれます。
<img src="???"→<img data-lazy="???"とタグを書き換えます。
<{$slideshow_html}>
カラーミーショップの独自タグ<{$slideshow_html}>を使ってスライドショーを表示している場合は、src→data-lazyの書き換えもSmartyを使って行います。
また、bxsliderを使っていない場合は、<{$slideshow_html}>で読み込むようになっている不要ファイル（bxslider関連のJS・CSSファイル、スタイル）を読み込まないように除去します。
replace:"src":"data-lazy"で、すべてのsrcをdata-lazyに書き換えています。
Smartyを使ってbxslide関連を除去、src→data-lazyに書き換え
<{$slideshow_html|regex_replace:'/<link rel[\s\S]+?<\/script>/':''|regex_replace:'/<style>[\s\S]*?<\/style>/':''|replace:'src':'data-lazy'}>
スライド画像の一枚目をsrcのままにしておくと、先に読んで表示くれます（その方が都合よい気がする）。
上の参考コードに追加して、Smartyと正規表現で書いてみてください。
レイアウトが大きく変わらないようにする
Cumulative Layout Shift（CLS）はレイアウトシフトに伴うズレによるユーザー体験の悪化を数値化しています（サイトの読み込み直後にコンテンツが下にズレるのは、よく見かけると思います）。
原因として、高さ指定のない画像、iframeや広告の埋め込み、Webフォントなどが挙げらています。
今回のレイアウトシフトの原因は、スライドショー描画直後に、コンテンツが下にずれることだろうと思われます。
対応としては、スライドショー描画前に、スライドショーが表示される場所の高さをあらかじめCSSで指定しておきます。
スライドショーの高さは、各ショップごとでまちまちなため、高さの指定の仕方も異なることでしょう。
当店配布の無料テンプレートのデモサイトでは、スライド画像は横幅1920px × 高さ768px（5：2）で統一していますので、CSSで height: 40vw;と、あらかじめ指定することができます。
このあたりまでやると、ネットワークの調子がいい（？）と、パフォーマンスの数値は90台まで出るようになります。数値はそのときどきで振れ幅があります。
適切なサイズの画像
画質調整してスライド画像のファイルサイズを45％ほど減量しました。
カラーミーショップの管理画面を使ってファイルをアップロードしても、減量後のファイルサイズに更新されませんでした。
カラーミーショップのサーバー側でのキャッシュか、画像形式をjpgからWebPに変換している影響かなと思います。
追記）時間をあけてから見ると更新されていましたが、減らした数値ほどの効果は出ていません。謎。
参考）オンラインイメージ最適化ツール
CSSファイルの最小化
ツールで、CSSファイルを軽量化します。
試してみましたが、影響が軽微な点と、メンテナンスしづらくなることを考えると、通常は行わないです。
参考）JavaScript / Css 圧縮・軽量化（Minify）：ファイルを圧縮して表示速度を上げる | ラッコツールズ
ユーザー補助
ユーザー補助は、数値的には80後半を付けています。
alt属性を付けるよう指示が出ています。対応すると、ユーザー補助の評価が90超えてきます。
画像要素に [alt] 属性が指定されていません
カラーミーショップの場合、独自タグで表示している、ショップロゴ、スライド画像、付加画像（Newなど）でalt属性が指定されていません。
また別件ですが、画像のwidth、heightを指定しておくようにと、PageSpeed Insightsから指示されます。
CSSでは付けられる場合もありますが、そうでない場合はJavaScriptで計算して指定します。
レスポンシブを考慮する場合は、元画像のアスペクト比を計算して維持しながら、スペースに綺麗に収まるように幅・高さを計算して、かつ、読み込み時以外にもリサイズ時の再計算も準備しておく必要があります（わりと手間）。
最低限、下記のコードがあれば、評価は上がります。
レスポンシブ対応については、わかる人はご自身でコードを追加してください。
JavaScript（ショップロゴにalt、width、height属性を指定）
const logoWrap = document.querySelector('.l-header-logo');
const logoImg = document.querySelector('.l-header-logo img');
const logoWidth = logoWrap.clientWidth;
const logoHeight = logoWrap.clientHeight;
logoImg.setAttribute('alt', 'ショップロゴ');
logoImg.setAttribute('width', logoWidth);
logoImg.setAttribute('height', logoHeight);レンタルサーバーがある方は
GoogleフォントやjQueryプラグインなど、CDNのファイルを利用する場合よりも、自前のレンタルサーバーに置くほうが読み込みが速くなる、ということもあるそうです。
当店配布の無料テンプレートのデモサイトの場合、
Googleフォント、slick（jQueryプラグイン）、共通HTML内にあるSVG画像、カラーミーショップのCSSファイル（index.cssやtop.cssなど）を自前のレンタルサーバーに移すと、FCP、LCPの改善することがありましたが。
LCPが大幅に悪化するときもあるので、サイトのいろいろな状態に影響されそうです。
手間や、改善効果とメンテナンス性などを勘案して判断しますが、やらなくてもよいような気がします。
試してみたい人だけやってみましょう。
参考までに、以前の記事にGoogleフォントをレンタルサーバーに置く方法について書いています。
CDNで読むより速い気がするのに、あまり効果が実感できなかった、Webフォントのプリロードのコード例。
各自で試してみて。
Webフォントのプリロード例
<link rel="preload" as="font" href="https://naeco.jp/fonts/NotoSansJP-VariableFont_wght.woff2" crossorigin />
<link rel="preload" as="font" href="https://naeco.jp/fonts/Roboto-VariableFont_wdth,wght.woff2" crossorigin />
<link rel="preload" as="font" href="https://naeco.jp/fonts/MPLUSRounded1c-Medium.woff2" crossorigin />
<link rel="preload" as="style" href="https://naeco.jp/fonts/font.css" onload="this.onload=null;this.rel='stylesheet'" />無茶してもいい場合は
カラーミーユーザーがいじれない場所で、ファイルがいろいろと読み込まれています。
カラーミーショップのサーバー側で共通HTMLの一番最後の行以降に、５つのJavaScriptファイルを読み込むようにコードが書き込まれます（ショップサイトのソースコードを見るとわかります）。
これをプリロードしたらどうなるんだろうと思って、試してみました。
共通HTMLの一番最後に</body></html>閉じタグと、以下をコメントにするための<!--。
そして、JavaScriptの preload と deferの行。
共通HTMLの一番最後以降をコメントアウトすることは、あとあとトラブる可能性がありますので、自分の責任で無茶できる場合だけ使ってください。パフォーマンスの数値は少し上がっていました。
共通HTMLの一番最後に追加
</body>
</html><!--共通HTMLの先頭、URLは各自変更
<link rel="preload" href="https://your-id.shop-pro.jp/js/cart.js" as="script" crossorigin="anonymous" />
<link rel="preload" href="https://your-id.shop-pro.jp/js/async_cart_in.js" as="script" crossorigin="anonymous" />
<link rel="preload" href="https://your-id.shop-pro.jp/js/product_stock.js" as="script" crossorigin="anonymous" />
<link rel="preload" href="https://your-id.shop-pro.jp/js/js.cookie.js" as="script" crossorigin="anonymous" />
<link rel="preload" href="https://your-id.shop-pro.jp/js/favorite_button.js" as="script" crossorigin="anonymous" />
<script type="text/javascript" src="https://your-id.shop-pro.jp/js/cart.js" defer></script>
<script type="text/javascript" src="https://your-id.shop-pro.jp/js/async_cart_in.js" defer></script>
<script type="text/javascript" src="https://your-id.shop-pro.jp/js/product_stock.js" defer></script>
<script type="text/javascript" src="https://your-id.shop-pro.jp/js/js.cookie.js" defer></script>
<script type="text/javascript" src="https://your-id.shop-pro.jp/js/favorite_button.js" defer></script>結果発表
最大限、プリロードした結果。
トップページのパフォーマンスは、95が出るようになりました。FCP、LCPもだいぶん短くなっています。
FCP、LCPはサーバーまわりの影響も受けそうですから、わりと上下に振れます。
プリロードのやりすぎか、LCP 32秒というのがときどき出ます。
なんでもかんでも、やりゃぁいいってものでもないらしいです。
おわりに
やることが際限ないくらい多いので疲れました（やれることはまだまだあります）。
各ショップサイトごとに、効果が出そうなものを採り入れるとよいです。
JavaScriptやCSSの読み込みは、通常は<head>内（カラーミーショップでは、ネットショップ＞検索エンジン対策）に書いて行いますが、個人的な都合で、ここではHTMLの先頭に書いています（パフォーマンスの数値はほとんど変わらない）。
同じコードでも、90台が出るとき、70台が出るとき、パフォーマンスの結果はまちまちです。
5-10回を時間を置きつつ実行して、傾向を見るのがよさそうです。
「実際のユーザーの環境で評価する」の数値がより重要だ、とGoogleの中の人が言ってました。
スライドショーの高さを指定すると数値がよくなりましたので、CLSの対応も重要です
（とくに当店が配布している無料テンプレートは、そうです）。
ほどほどのプリロードでもパフォーマンス 90台前半まで出ました。
そして、LCP 32秒というおかしな数値が出なくなりました（低速回線のネットワーク帯域をプリロードでつかいきって、激重になっていたという感じでしょうか？）。
プリロードはほどほどにやるのがよさそうです。
サイト全体の不要コードを整理して軽量化することも、効果があるそうです。
初見で不要かどうかの判断はむずかしいので、ふだん担当されている制作会社様に相談されるのがよいでしょう。
参考）対象範囲: 使用していない JavaScript と CSS を見つける | Chrome DevTools | Chrome for Developers
おまけ（カラーミー商品詳細ページ）
商品詳細ページを直した結果、パフォーマンスの数値は、59、73、92と出ました。
90台がときどき出るので以前よりは改善したのだろうと思います。
とはいえ、高い数値で安定しません。
トップページと同様に、スライドショーの高さを指定すると目に見えて改善します（CLS対応）。
縦横比がそろっているなら、CSSで入れるのが楽。
登録した画像サイズがばらついている場合はJavaScriptで計算します（手間です）。
執筆者
えいじ@naeco.jp この記事を書いた人
自作するのが好きですぐに試したくなる、凝り性なWebエンジニア。
カラーミーショップ、モールなどのECについて記事にしています。
ご相談・お問い合わせはこちら