こんにちは、TechFeed CEOの白石です。

日本のフロントエンド界隈をリードし続ける古川陽介さんとTechFeedがコラボして、フロントエンド技術の最新動向を月イチでお届けする連載企画、「 古川陽介に聞く！フロントエンド最前線 」の新着動画が公開されました！

YouTubeのチャンネル登録はこちらから！

毎月3〜4つのトピックを取り上げ、TechFeed CEO 白石俊平とNode.js Association代表理事 古川陽介が縦横無尽に語ります。
フロントエンドエンジニア必見です😊

今回は、2023年4月のトピック（Next.js v13.4 / Lighthouse User Flows）を取り上げた動画を公開！

また、動画の内容を要約した本文も以下に掲載！
動画本編を見る時間がない方は、文章でお楽しみください😊

激震！Next.js v13.4

白石: Next.js v13.4ですが、どういったところが注目でしょうか？

古川: これちょうどゴールデンウィーク中に公開されたもので、みんなが休んでたときに、激震が走ったんじゃないかと思ってます（笑）
ここで激震が走った理由としては App RouterがStableになる という点で、これはかなり大きい。

Next.js v13.4

Next.jsにあまり詳しくない方のために解説しておくと、Next.jsって前まではPages Routerって言うルーターだけだったんです。
これはファイルシステムにマッピングされているルーターで、URLのパスから自動的にtsx/jsxファイルを探してきて、そのファイルを表示するというようなルーティングをしていました。

対して、App Routerと呼ばれる新しいルーターの開発が昨年始まりました。
秋ごろのNext.js Conf 2022でそれのβ版が出て、その安定版が5月5日にリリースされました。

このApp RouterはPages Routerよりも、より細かくコンポーネントのレイアウトを定義できるというものです。
例えばこういうツイート用のアイテムとかを取ってくるとか、っていうのをしたりとか、あとそれを入れ子にできたりするんですよね。

App Router

Pages Routerでは「リクエストされたらページを表示する」っていう動きしかできなかったのが、App Routerだとより細かく制御できます。例えば、「まずページ全体を返して、ページの一部は遅延読み込み」のような動きが実現できる。

suspenceを使用した遅延読み込み

例えばこのコードでは、PostFeedをローディングしてる最中は「Loading feed...」っていうローディングUIがまず表示され、読み込みが終わったらコンポーネントが描画される、というようなことができます。

このように、App Routerは非常に大きな可能性を秘めているのですが、これからのNext.jsの開発スタイルとかがガラッと変わるんじゃないかということで、皆さん激震が走ってるというところですね。

白石: それほどの変更だとすると、マイグレーションが必ず話題になると思うんですが、どうなるんでしょうか？

古川: マイグレーションについてのドキュメントはあるのですが、実際に移行するのはかなり大変です。
Pages Routerも残るので、無理にApp Routerに書き換えなくてはならないというものでもない。

ただ、これから追加される新しい機能のほとんどがApp Routerベースになるので、そこは悩みどころです。

白石: App Routerへの移行が難しいと思うのはどういうところでしょうか？

古川: まずPages RouterとApp Routerのルーティングの仕組みが違うので、Pages Routerで書いたコードをそのままApp Routerに移行することはできません。

あと、キャッシュの扱いがブラックボックスなのが難しいところですね。

Next.jsってたくさんキャッシュがあるんですけど、 クライアントキャッシュをApp Routerが完全に隠蔽しちゃってる んです。勝手に一定期間キャッシュされてしまうんですよね。「キャッシュしたくない」とか、そういう設定が書けないと困るんですが、今のところそういう設定ができなさそうです。

色々調べた結果、ぼくらのチームではまだプロダクションレディじゃないっていう判断をしました。しばらく様子見ですね。

Lighthouse User Flows

白石: では次のトピック「Lighthouse User Flows」をお願いします。

古川: Lighthouseの新しいバージョンからUser Flowsが利用できるようになりました

※ LighthouseはGoogleが提供しているWebサイトの品質を測るツール。Lighthouseを使うと、Webサイトのパフォーマンスやアクセシビリティ、SEOなどの品質を測ることができる。

Lighthouse User Flows

これは目新しい話かというと実はわりと古い話なんです。
3か月前ぐらいには出ていたんですけど、まだまだ知られていないので、今回取り上げてみました。

まず前提として、前回のGoogle I/Oで Core Web Vitalsに大きな変更が入った んです。

今までCore Web Vitalsっていうのは LCP（Largest Content Paint）、FID（First Input Delay）、CLS（Cumulative Layout Shift） の3つの指標からなっていました。

• LCP :画面の中の最大領域がどれだけか、それを出すのにどれくらい時間がかかったか、という指標
• FID :入力ができるようになるまでの時間がかかったか、という指標
• CLS :レイアウトが描画中にどれだけ動いたか、という指標

このうち、 FIDが廃止され、代わりにInteraction to Next Paint（INP）という指標が追加 されました。

INPというのは、 ユーザーの操作に対してWebサイトがどれだけ早く反応するかを測る指標 です。
例えば何かクリックしたとき、別のページに遷移したとか、ローディングアイコンが出たとか、そういうリアクションが返ってくるまでの時間を測る指標です。
これにより、「押しても反応が何もない」という状態が一定時間以上続くと、そのページはCore Web Vitalsの基準を満たしていないと判断されます。

ただ、この INPっていうのをどうやって測るんだろう？ というのが疑問だったんです。
Lighthouseって、ページを読み込んだときにしかスコアを測らないんですよね。

どうやるのかなと思っていたら、User Flowsでできるってことが分かったっていうのが今回の話です。

白石: なるほど。

古川: Lighthouseの今までの画面は、ナビゲーションっていうモードとして扱われてます。ナビゲーションモードで初期のページロードは測れる。

その後タイムスパンっていう別なモードが存在していて、このモードを使うと、サーチバーに何か入力したとかエンターキーを押したとか、そういうアクションが起きてからその結果が出るまでの時間を測ることができます。

タイムスパン

例えばこのデモで見ると、検索したら一旦ぐるぐる（ローディングアイコン）が出てくる。
このぐるぐるが出てくるまでが60ミリ秒だったので、LighthouseはこのページはOKだよっていうふうに判断してくれます。
何か反応がありさえすればいいんです。

ローディングアイコンの表示により、INPのスコアは改善する

これが例えばぐるぐるがなくて、結果が出るまでに10秒くらいかかってたりとかしたら全然ダメですね。

白石: なるほど〜

古川: これがGoogle I/OでCore Web Vitalsが変更されたのは知っていましたが、どうやって測るんだろう？と思っていたんです。
それがUser Flowsで測れるっていうのが今回の話です。三ヶ月くらい前の話で、ぼくが気づいてなかったってだけなんですけどね。

白石: 古川さん、ありがとうございました。この動画を見て面白いと思った方はチャンネル登録、高評価どうぞよろしくお願いします。ご視聴どうもありがとうございました。