注意
タシロはそこまで「Core Web Vitals」に詳しいわけではないです。（片足ちょっと突っ込んだ程度…）
最近ちょっとやって見る機会があったので、そこでやったことを無理のない範囲でタシロがタシロのサイトに施してみるだけの話。
以前、「Core Web Vitalsなにそれおいしいの？」状態の時にタシロが趣味で作った「カイワレのサイト」のCore Web Vitalsを今回は改善して行こう！という感じにやって行こうかなと思います(笑)
まずそもそも、Core Web Vitalsってなんぞや？
とってもざっくり言うと、みんな多分大好きかもしれない(笑)Googleの検索順位の指標となるものです。
これにより、検索順位が上がったり、下がったり、したりしなかったりします！
詳しく知りたい人は「Core Web Vitals」でググろう！
| メリット | デメリット |
|---|---|
| ちょっとでも検索順位上げたい人にはメリットがあるかも | めんどい、何していいかわからん、 ほんとに検索順位上がんの？←成果が出るまでに時間がかかる |
ただ全く同じサイト・似たようなサイトがあった場合は「Core Web Vitals」を意識して作ったサイトの方が、順位は1つでも上がるのではないかなと思います。
まあ、ページの遅さ改善などを行うので、タシロ的には無駄ではないかなと思います！
普通に考えて、遅いページよりも早いページの方がアクセスしやすいですし、ユーザーのストレス軽減にはつながるかも？！
で、本題「なにすりゃいいの？」
サイトの読込速度を上げるために、HTML・CSS・JS・画像もろもろをとりあえず軽くしよう！
「いらないものは断捨離！」
何から手を付けたらいいかわからない人
PageSpeed Insightsをやって見よう！ こんな感じで色々教えてくれる！
↑そこまで、点数は悪くなかった(笑)
まあ、せっかくだし、100点目指してみよう！
どうやら「First Contentful Paint」と「Speed Index」がダメらしい
まあ、ざっくり言うと| First Contentful Paint | Speed Index |
|---|---|
| JSよくない！ | 画像が重い！サイトが遅ぇ！ |
じゃあ、サイト改善やってみよう！
①とりあえず、画像サイズで怒られてるっぽいので、画像を手っ取り早く軽くしていこう！
適切なサイズの画像 53.1 s
適切なサイズの画像を配信して、モバイルデータ量を節約し読み込み時間を短縮してください。
WebP や AVIF などの画像形式は、一般的に PNG や JPEG より圧縮率が高く、ダウンロード時間やデータ消費量が抑えられます。
過大なネットワーク ペイロードの回避 合計サイズは 11,147 KiB でした
ネットワーク ペイロードのサイズが大きいと、ユーザーの金銭的負担が大きくなり、多くの場合、読み込み時間が長くなります。
静的なアセットと効率的なキャッシュ ポリシーの配信 17 件のリソースが見つかりました
キャッシュの有効期間を長くすると、再訪問したユーザーへのページの読み込み速度を向上できます。
ちなみに、WebPはブラウザによって表示されないなどのデメリットがあります！
参考サイト：WebP(ウェッピー)とは？フォーマットの違いや作成方法をご紹介!
なので、タシロはあまり好きじゃないから今回はやらない…
| 現状 | |
|---|---|
| 4032 × 3024px というとんでもねぇ画像サイズに 735KB というとんでもねぇ画像の重さ… 自分で作っといてなんだけど、ないわ… |
 |
| 結果 | |
|---|---|
| 画像サイズ：4032 × 3024px → 1512 × 1134px 画像の重さ：735KB → 170KB |
 |
今回は、1512 × 1134pxで170KBなので、PC版を切り捨ててもっと画像を小さくすれば、軽くなってサイトがもっと早くなると思います！
（タシロはPC版切り捨てたくないので、やりませんけど笑）
②HTMLを改善しよう
画像要素で width と height が明示的に指定されていない
| URL | 問題のある要素 |
|---|---|
| /img/logo.png(gundji.html.xdomain.jp) | div.cell > h2 > a > img <img src="img/logo.png"> |
<img src="img/logo.png">
↓これをこうすればOK！
<img src="img/logo.png" width="280" height="45">
③JSなんとかしよう
使用していない JavaScript の削減 0.15 s
使用していない JavaScript を減らして、必要になるまでスクリプトの読み込みを遅らせると、ネットワークの通信量を減らすことができます。
第三者コードの影響を抑えてください 第三者コードによってメインスレッドが 450 ミリ秒間ブロックされました
第三者コードによって、読み込み速度が著しく低下する可能性があります。重複する第三者プロバイダの数を制限したうえで、ページのメインの部分を読み込み終えた後に第三者コードを読み込んでみてください。
スクロール パフォーマンスを高める受動的なリスナーが使用されていません
ページのスクロール パフォーマンスを高めるには、touch および wheel イベント リスナーを `passive` として指定することをご検討ください。
なんかここら辺は私が入れたJSで怒られてるっぽいですね(笑)
まあ、基本的にjQuery等のJSのDOM操作?は行わないほうがいいらしいです！
でも、今回このサイトはこの一つ一つ紙芝居形式に移動させるJSをメインに使ってます。
なので、このJSなくなるとちょっと困る…今回はJSなんとかはしないです(笑)
タイトル：JSなんとかしよう（なんとかするとは言ってない…）
もしやるなら、できる限りCSSで動きの方は何とかしたりで、JSなくすのが一番手っ取り早いです！（今回は無理 笑）
Core Web Vitals的にはJSをなくしても、レイアウトが崩れないサイトが望ましいらしい
まあ、こんな感じにうまいこといるものは残す、いらないものは捨てるみたいな感じでタシロは無理なくやって行こうかと思います(笑)
④色々軽量化しよう
テキスト圧縮の有効化 0.15 s
テキストベースのリソースは圧縮（gzip、deflate、または brotli）して配信し、ネットワークの全体的な通信量を最小限に抑えてください。
| URL | 転送サイズ | 減らせるデータ量 |
|---|---|---|
| /fullpage.extensions.min.js(gundji.html.xdomain.jp) | 43.4 KiB | 28.0 KiB |
| /style.css(gundji.html.xdomain.jp) | 12.7 KiB | 10.0 KiB |
| /kaiware.html(gundji.html.xdomain.jp) | 13.5 KiB | 9.9 KiB |
基本的にHTML・CSS・JS・画像は軽けりゃ軽いほどいいらしいです。
なので、HTMLとかCSSとかJSとかで、コード書く時に見やすいよう改行したりとか、スペース空けたりとかすると思うんですけど、それ全部なくそうという感じです。
「でも、それってメンテする時とか作業しづらくね？」
ええ、そうですね。
なので、最低限読みにくくならない範囲でスペース少なくしたり、改行少なくしたり、無駄なタグとかクラスとかなくしたりとかぐらいしかやりようがない…。
「もう、二度とこのサイト触らない！」「メンテなんてしない！」とかならありかもですけど、あまり現実的ではないですね(笑)
で、色々やってきて、PageSpeed Insightsの最終結果がこちら
注意
割とやる人の端末のスペックなどで変動するっぽいです。（私がやっと時はこうなった）
まあ、色々踏まえて結論
Webサイトとしての意味とかは一旦置いといて、Core Web Vitalsの点数上げる的な意味合いでは
真っ白な何も表示されないサイトが最強(笑)
タシログンヂのなにもないカイワレサイト
 |
|---|
