ふくいのふ ふくいのふ ふくいのふ

ふくいのふ

WEB ENGINEER

nuxt export で爆速ページ遷移

nuxt export で爆速ページ遷移

nuxt export?


"nuxt export" は、Nuxt.js のバージョン2.13.0 でリリースが予定されている静的ジェネレート機能です。
👉(2020/06/20 追記)2.13.0 がリリースされました。

静的ジェネレートに関しては既に "nuxt generate" というコマンドがありますが、nuxt export ではこちらのコマンドでの問題点を解消し、さらにパフォーマンスの強化が施されています。

詳しい機能や、先行導入は下記の記事が参考になります。
Going Full Static

すごいところ


<nuxt-link> でのページ遷移時に API 通信をしなくて良くなった


nuxt generate をすると全てのルートのページが静的 HTML として書き出され、ページへの初回アクセス速度(具体的にはTTFB)の面で大きなアドバンテージを得られます。
このとき、 asyncData / fetch (fetchOnServer:true)が予めサーバーサイドで処理された状態のページを生成します。

ですがアクセス後に <nuxt-link> を使用したページ遷移をすると、遷移先の asyncData / fetch が都度クライアントサイドで処理されます。
例えば、ページの情報を asyncData / fetch フックで API から取得していると、ページ遷移の回数分 API 通信が行われているということですね。

レスポンスや、API サーバーへの負荷懸念等、これを良しとしない人の為に、nuxt export では asyncData / fetch の サーバーサイドでの処理結果をキャッシュするようになりました。
具体的には、ページ生成時に処理結果(キャッシュ)を payload.js としてページごとに生成し、遷移時はその payload.js からデータを読み込むという構造です。
payload.js
↑ payload.js の中身の例(asyncDataで処理された結果がdataに格納されている)

これによって、asyncData / fetch の処理を待たなくて良くなり、パフォーマンスの向上へと繋がります。


この payload.js、どうせなら Cache-Control を設定したり、CDN に乗せたりしたいですが、キャッシュが残りすぎてしまわないか心配になります。
が、そのあたりもきちんと考慮され、 payload.js がまとめられたフォルダの直前にはキャッシュバスターとして timestamp がついています。


キャッシュを smart prefetch(イケてる先読み)してくれる


前項で生成したキャッシュ( payload.js ) を先読み、プリフェッチするようになりました。
しかもそのページへのリンクが画面内に現れて初めて先読みを開始するので、より効率的です。

次に遷移するページの情報が既にクライアントのローカルにある状態になるので、遷移速度が飛躍的に向上します。

ルート一覧を書かなくても良くなった


これまで nuxt generate で _slug.vue や _id.vue 等、ダイナミックルートを生成する場合、生成するページの一覧を nuxt.config.js に記載する必要がありました。
nuxt export ではこれらを書く必要はなくなり、生成時にページを全力でクロールして内部リンクを検知し、自動でルート一覧を認識してくれるようになりました。
(どこからもリンクが貼られていないページは手動で記載する必要があります。)

個人的に Svelte のフレームワーク、Sapper の仕組みと似てるなと思いました。
[Sapper] export で 完全静的サイトを作る [Svelte] - Qiita

ビルドとジェネレートの分離


nuxt generate は 「nuxt build をしてページ生成」までが一つの纏まりになっていましたが、nuxt export は nuxt build が分離され、それぞれ別々にコマンドを実行する方式になりました。
つまり nuxt build してから nuxt export を実行するという順番ですね。

nuxt build したファイルを保持しておける環境であれば、フロントエンドのソースが変更されておらず、API の情報だけ更新して生成し直したい場合にデプロイ時間の短縮が見込めますね。

この分離によって、将来的には Gatsby 等で可能な incremental build もおそらく可能になると個人的に思っています。
GatsbyJSのIncremental Buildsで静的サイト制作が劇的に変わる - code-log

デモ

は、今ご覧になっているこのサイトです。


nuxt export でのジェネレートを先行導入してみました。
👉(2020/06/20 追記)バージョン 2.13.0 を導入しました。
爆速な遷移をお楽しみください。
ブログページ等が丁度プリフェッチの体感に良いかと思います。(最近外部遷移のQiita記事多めなので2ページ目以降が良いかも)

ちなみに


ホスティングは Firebase hosting、それに Cloudflare を CDN キャッシュとして被せております。

Cloudflare はキャッシュレベルを Cache Everything に設定しているので、payload.js さえも CDN キャッシュから届きます。



もちろん Firebase hosting にも CDN が付いていて、その実は fastly だとか言われていて実際レスポンスも良いです。
が、あくまで個人的な観測ですが、キャッシュヒットしない時、つまりオリジンサーバーとしての Firebase hosting ってレスポンスがいまいちな気がします。

Cloud Run へ Rewrite で流したときも、キャッシュヒットしない状態では Cloud Run のデフォルトドメイン直のほうが明らかに TTFB が速かったので、Firebase hosting のオリジンサーバーのミドルウェアがそこまで良い性能とは言えないようです。

あくまで個人の感想ですし、Pro plan 以下の Netlify (エッジサーバーが日本にない)よりは全然パフォーマンスいいと思います。




まぁ阿部寛のサイトが一番速いんだけどね。

© 2019 ふくい
ToTop