この記事をおすすめしたい人
- WordPressしか知らないのにNuxt.jsを始めようとしてる人
- 静的HTMLの速度に過大な期待を抱いている人
- つまりオレ
何も知らない超初心者が脱WordPressしたくてNuxt.jsでサイト構築していくシリーズです。
聞いてください。
Nuxt.jsで作った初めてのサイト。 トップページだけできたのでアップロードしたんです。
あ、違った。 今はデプロイって言うんですかね。
デプロイ！
僕がNuxt.js始めたきっかけは「静的出力するのでWordPressに比べて爆速！」というものでした。 詳しくはNuxt.jsを選んだ理由を見てください。
なので早速PageSpeed Insightsに突っ込んだ結果やらを今回はお話しします。
WordPressの上でな！
※ このブログはWordPress製です
このページの目次
PageSpeed Insightsの採点結果
さっそくPageSpeed Insights(以下PSI)に突っ込みます。
PSIはロード時間が長いのがいいですよね。 ドキドキする…。
そして結果↓。
へ…？
48点です。
チューンした後のWordPressよりぶっちゃけ遅いです。
静的HTMLだから爆速ってことはなく、ちゃんとチューンしないとダメみたい…。
「Nuxt.jsならテキトーにやっても爆速！」と思ってNuxt.js始めようと思ってる人(オレ)は注意してください。
まぁ…。
静的である以上、動的なWordPressに負けるはずがないのでこっからチューンしていきたいと思います。
まずは減点内容の確認
「レンダリングを妨げるリソースの除外」
Webフォントの読み込みに時間がかかっているようです。 もう0.45秒短縮できますよ、と。
Googleフォントなので「display=swap」つけてるんですけどね…。
「使用していない JavaScript の削除」
Nuxt.jsがロードしている「commons.app.XXXXXXXXX.js」が67.5KBで31.9KBまで減らせますよ、と。
これも0.45秒短縮できますよと。
「使用していない CSS を削除してください」
こちらもwebフォントのCSSが指定されてます。
つこてるがな！！
たぶんレンダリングのタイミングとCSSのロードとかその辺の問題なんでしょう。
「次世代フォーマットでの画像の配信」
これ一番嫌いです。
透過画像でPNG1枚、その他JPEGですが、JPEG 2000/JPEG XR/WebP使えばもっとファイルサイズ小さくできますよって怒られてます。
全ブラウザで対応できるフォーマットないやないか！
多くの場合は圧縮率改善することで怒られなくなるんですが、たまに何をやっても減点されるケースがあります。
以前は最適化済みの画像をPSIからダウンロード出来てた気がするんですが、最近のはできないですね…。
どうしろと…。 うぇっぴー？
どうしましょうかね…。
フォントと…JavaScriptどうにかできないか調べてみます。
Webフォント問題の解決…？
@font-faceとfont-display: swap
ネットで調べると至るところでこの話が出てきます。
「swap」を指定するとフォントがロードされるまで代替フォントが読み込まれるそうで、ページの表示を妨害しないとかなんとか。
で、この方法をやってみると…。
いくらか改善しました。
が、今度は「過大なネットワーク ペイロードの回避」という項目が赤字で登場します。
「これらの数値は、パフォーマンス スコアには直接影響しません。」と但し書きがありますが、明らかにスコアに影響してそうなのは次の実験で分かります。
Webフォントを外した
Webフォントの指定を外して計測。
劇的に改善しました。
これだけ簡単に改善するところを見るとWebフォントを諦めた方が早い気がしてきますが、ネット見てるとWebフォント使いつつ80点以上出してる人もいるので、僕のやり方が間違ってるんでしょう。
僕の中でもかなり大きな問題なので、解決策が分かったらまた記事かきます。
お手軽に解決したいなら今はWebフォントを諦めなさい。
JavaScriptのサイズ軽減はできる…？
「使用していない JavaScript の削除」で指摘されていたNuxt.jsのJavaScriptを覗きましたが、改行やスペースは削除されていたので、これ以上は本当に未使用スクリプトを削除するしかなさそうです。
Nuxt.jsにそういう機能があるのかというと…
分からん！！
おいおい調べておきます。
JavaScriptが邪魔なら使わなければいいじゃない
Webフォントの問題は「Webフォントを使わない」ことで解決しました(解決していない)。
ならJavaScriptの問題も同様に「JavaScriptを使わない」ことで解決してみようと思います。
nuxt.config.jsに以下のコードを追加してNuxt.jsが読み込みスクリプトを削除します。
export default {
render: {
injectScripts: false,
},
}
結果↓。
見てください、このスコア。
素晴らしい。
JavaScriptなんかいらんかったんや。
というのは冗談にして、僕はNuxt.jsが読み込むJavaScriptが何をやっているのか分かっていないので、こんな過激な事ができているだけです。 とりあえず僕が作っている範囲では機能的な問題は起きていませんでした。
1点だけ。 Googleアナリティクスのコードを自前で追加していて、それがNuxt.jsが読み込むJavaScriptに統合されていることを把握しているのでこのままではアナリティクスが使えません。
その点さえクリアすれば、Nuxt.jsが読み込むスクリプトが担っている内容次第ではこの選択肢はありかもしれない。
JavaScript使わないならAMPにすればいいじゃない
JavaScriptが不要なら高速と噂のAMPを使う手もあります。
Nuxt.js用のAMPモジュールを組み込んでAMP化してみます。
結果↓。
へ…？
そうなんです。
AMPはAMPであれば高速という意味ではなく、AMPキャッシュ(GoogleやTwitterから飛んだ場合)に高速なんです。
普通に見た場合はAMP用のスクリプトを読み込むせいで逆に遅いケースもあります。
実際、今回のPSIの結果でも「使用していない JavaScript の削除」の項目でAMPの必須スクリプトが挙がっていました。
それ、お前が用意したスクリプトちゃうんかい。
ＡMPが遅いならサーバサイドレンダリングすればいいじゃない
AMPはAMPでJavaScriptが動いているので言うほど高速ではないっぽいです。 それを高速化する手段としてサーバサイドレンダリング(以下SSR)が用意されています。
AMP Optimizerを使ってSSRした結果↓。
へ…？
SSRに多大なる期待を抱いて僕としては受け入れがたい結果です。
そこまで速くなるわけではないっぽい…。
減点内容としてはやはりAMP用のJavaScriptの読み込みに時間がかかっているみたいです。
いや、それ、君が用意したスクリプトだからね…。
Nuxt.jsではサーバのレスポンスうんぬんは一度も言われなかった
割とネガティブな内容が続きましたがポジティブな内容も1点。
PSIで速度チェックしてると、WordPress下では、
Reduce initial server response time
というのが何回かに1回出てました。
サーバの応答時間を短くしてください、というやつです。
おそらくこれはWordPressの場合、PHPでゴリゴリ処理しながら動的に出力するので、タイミングによってはサーバのレスポンスが悪いよーってことだと思うんですが、Nuxt.jsでは一度も出ませんでした。
この辺はやっぱり静的出力のメリットなのかなーと思います。
結論
Webフォントを使わない、JavaScriptを使わない、が最強という結果になりました。
期待していたAMP SSRの効果もそれほどではなく…。 やはりAMPはAMPキャッシュを使ってこそなのか…。
一番スコアの良かったパターンで、画像をJPEG 2000/JPEG XR/WebPにすれば100点出るかも知れないですが、全ブラウザで対応なわけじゃないですからね…。
高得点取ってる人はどうしてんだ…。
この問題はウェブサイト作る限りはずっとついて回ると思うので、また何か面白アイデアあったら追試したいと思います！
以上、WordPressからお届けしました！
PageSpeed Insightsの目次
- 第1回 静的HTMLが必ず速いわけではない(このページ)
- 第2回 スコア改善にはとにかく容量を減らす
- 第3回 フォントのサブセット化を掘り下げる
- 第4回 PNG最適化は妥協せず行うべし