00:04
3月11日、土曜日ですね。時刻は朝9時12分になりました。
本日は、ちょっと久しぶりに、ちゃんとした技術記事を読みたいと思っております。
はい、おはようございます。右のkkeethごとく川原です。
ではでは、本日も朝活を始めていきたいと思います。
今回はタイトルにありますけど、Next.jsの13.2のリリースブログがあるので、これを読んでいこうかなと思っています。
ちょっとですね、お仕事上でNextをまた見なきゃいけないというか、
Nextプロジェクトのコードレビューをするみたいな機会が出たので、
ちょっと久しぶりにですね、ちゃんとNext.jsの更新とかをしっかり追っていかないとレビューできないなというので、
まずはそのですね、更新ブログ、公式の方のブログを読んでいこうかなと思った次第になります。
はい、じゃあ早速読んでいきたいと思います。
Next.js 13.2では、安定化に向けてアップルーダーの大幅な改良を行いましたよと。
で、主に1,2,3,4,5,6,7、8個ですかね、ありますが、
1つ目、Built-in SEOのサポートだそうですね。
あ、そうなんや。
静的及び動的なメタタグを設定するための新しいメタデータのAPIを提供しますと。
で、次がルートハンドラーですね。
これ結構大きかったような印象がありますね。
Webリクエストとレスポンスをベースに構築されたカスタムのリクエストハンドラーだそうですね。
3つ目がMDX for Server Componentsということで、
サーバーコンポーネントのためのMDXが導入されたと。
4つ目がマークダウン内でのリアクトコンポーネントをサーバーサイトのみで使用できますということです。
5つ目、新しいラストプラグインでマークダウンのパージングというのを高速化できますよということですね。
あ、そうなんや。
続いて改善されたエラーのオーバーレイだそうですね。
Next.jsとリアクトのスタックトレースを分離して読みやすさを向上させたらしいです。
続いて静的な片付きリンクですね。
これでもベータ版らしいですけど、
Next.linkというモジュールがありますね。
あれとタイプスクリプトでリンク切れを防止させるようにしますということですね。
続いてターボパックの改善でした。
ターボパックまだまだ出たばっかりというのがあって、しかもこれアルファだそうですね。
ですけど、ウェブパックローダーとの互換性とサポートの向上をやってますと。
はーねー、なるほど。
ラスト、Next.jsのキャッシュですね。
こっちもベータ版ですけど、
プログレッシブISRとコード変更の再デプロイというのを高速化したよということです。
いやいやいや、本当にモダンなフレームワークなのが手つくずく感じますね、これ見る限り。
ではでは、早速一個ずつ入っていきたいと思いますけど、
まずはそのBuilt-inのSEOサポートというところですね。
新しいメタデータAPIによるSEOのサポートが組み込まれてますよというお話です。
Next.jsというのは当初から検索エンジンの最適化を可能にするために設計されていますと。
で、プリレンダリングされたHTMLコンテンツを提供するということは、
検索エンジンのインデックスを向上させるだけではなくて、
アプリケーションのパフォーマンスも向上させますと。
うん、そうね。
で、Next.jsは多くのバージョンでアプリケーションのメタデータを変更するためのシンプルなAPI、
03:00
Next.headというものを提供してきたんですけど、
アップルーターですね、括弧アップという英訳ですけど、
を使って検索エンジン最適化する方法を再設計して強化したいというふうに考えたんですね。
なんかこれのイシューがあったら聞いてみたいですね。
多分この辺の話って絶対ユーザー側からいろんな議論があったと思うんで、
その議論が行われたイシューがあったらちょっと見てみたいですね、これ。
はい、で、続きましょう。
新しいメタデータAPIではサーバーコンポーネントである任意のレイアウトだったりとか、
ページにおいて明示的なメタデータの設定で、
メタデータですね、HTMLヘッド要素内のメタタグやリンクなどっていうのを提起することができるようになりました。
で、まあ一応ソースコード具体例が出てきてて、
apps-layout.tsxみたいなファイルの中身に、
インポートタイプでメタデータか、from、nextでそういうのを持ってきて、
エクスポートコンソでメタデータっていうような型を定義しておいて、
例えばタイトルとかディスクリプションとかっていうのを設定するようにできますよと。
より明示的でわかりやすいですね、これは。
で、このAPIっていうのはシンプルでかつ合成可能にもなり、
ストリーミングサーバーレンダリングとの互換性があるように以上設計されてますと。
例えばアプリケーション全体のルートレイアウトに共通のメタデータの属性とかを設定したり、
アプリケーションの他のルートに対してメタデータオブジェクトを合成してマージしたりすることもできますと。
まあそりゃそうだよね。
これには静的なメタデータだけでなくて動的なメタデータのサポートも入ってますってことですね。
さっきの具体例のところにもう一個追加になるんですけど、
とりあえずスタティックなメタデータはエクスポートコンソでメタデータイコールほげほげみたいのでオブジェクトで設定しますと。
もう一個はダイナミックメタデータですね。動的なものですけど、
もちろんエーシンクのファンクションでジェネレートメタデータみたいな関数を作っておいて、
その中にパラメーターとかサーチパラムズみたいなやつを作っておいて、あとほげほげすると。
最後それをリターンで返すときにそのリターンの中身にまたオブジェクトを作っておいて、
タイトルごろんなんちゃらみたいなのを書いておくと動的なふうに設定することもできますと。
これ多分エーシンクファンクションで定義するのが前提なんだろうな、おそらくですけど。
ジェネレートメタデータっていう関数があるんですね、これは。
分かりました。
というので静的動的両方にメタデータの設定できるようになりましたよと。
分かりやすいな。
メタデータAPIはバージョン13.2において従来のhead.jsっていう特殊ファイルに代わって
アップルーターに対して利用可能ですと。
Pages Directではその代わり利用できませんというふうに注意してくださいと。
SEOの詳細またはメタデータAPIのリファレンスも見てみてくださいと。
APIパッケージの作成と初期のAPI設計へのフィードバックをしてくれたNEXT SEOというところに感謝をしますということでした。
より実際の現場に沿った機能に拡張していった感じですね。
これ考えるとNEXT 12と13でかなり大きく変化をするので、
12以前と13以降の対応で追われる気がしますね。
逆に言うと12から13ってバージョンが移行するときは結構エネルギーが要りそうだなという気もしているので、
これやっぱりちょっと追っていかないと後で痛い目見そうですね。
ただまあより便利になっている間違いはないので、
06:01
どんどんNEXTの進化はこのままずーっと見続けていきたいとは思いますね。
続いて今のがSEOの新しいBuilt-in SEOサポートのところでしたけど、
続いてはカスタムルートハンドラーに入りたいと思います。
今回はエクスポートエーシンクのファンクションでgetという、これ全部大文字ですね。
大文字のgetの括弧でリクエストコロンリクエストみたいな型を定義して
引数指定することができるようになると。
ちょっとパッと見は違和感があるというか、そんな名前の関数なんやって気はしますけど。
慣れの問題でしょうね。
ルートハンドラーというのはEdgeとNode.jsの両方のランタイムをシームレスにサポートする同系のAPIというのを持っていて、
ストリーミングオートのサポートも含まれています。
ルートハンドラーというのはページアレイアウトと同じルートセグメントの設定を使用するため、
汎用的なスタティックレンダリングだったりとか再検証などの待望の機能というのをサポートしています。
root.tsファイルというのはhttpの名付けられた非同期関数をエクスポートすることができます。
名付けられたっていうのはいわゆるget、head、options、post、put、delete、patchなどだというこういう名前ですね。
全部大文字の非同期関数というのをエクスポートすることができるようになりました。
ここはやっぱりちょっとパッと見、今まで見たことないので違和感はありますけど。
これらの関数というのはカスタムルートロジックへのヘルパーだったりとか再利用可能なロジックを作成するために
ラップして抽象化することができますよと。
クッキーとかヘッダーのような他のサーバー機能というのはルートハンドラーの内部で使用することができます。
これらの抽象化が基づいて構築された任意のWeb APIとともにそういうのを使うことができますよと。
これによってサーバーコンポーネンツとルートハンドラーの間で行動共有することができますよと。
ああ、そういうことか。思想というのはサーバーコンポーネンツという話が根本にあるわけですね。
ああ、そう言われると結構理解できますね。
使い方のソースコードがガッと載ってますけど、ちょっと音読で申し訳ないですけど。
とりあえずNextHeadersというモジュールからクッキーズというのを返すんですね。
レスポンスオブジェクトのインスタンスを作ってそれをリターンすると。
第1引数にはテキストが入っていて、第2引数にステータスだったりヘッダーみたいなさっきのクッキー情報とかもそのまま返してあげるというのをやるってことですね。
結構イメージできますね。サーバーコンポーネンツとの関わりってそういうことかって感じですね。
これによって共有できるようになるというのはより柔軟性があるんですね。なるほどでした。
ルートハンドラーというのは13.2以降アプリルーターですね。
いわゆるApp Directoryにおいてroot.tsという特殊なファイルを用いて利用することができますよと。
で、APIルーツの代替となるため、Pages Directoryではやっぱり利用できません。
はいはいはい。
ということはPages Directoryより何ですかね、本当に命令というか静的な方にシフトする。
なるべく処理とか何やらかんやらを乗っけないように分離しようとしてるんですかね。
これはなんかそんな風な思想に見えますね。
ルートハンドラーの詳細についてはAPIレファレンスを参照してくださいと。
SvelteKitの先行技術とかインスピレーションに感謝してます。
そうね、今回SvelteKitからインスパイアされたんですね。
09:02
逆に言うと実はSvelteKitはそれだけもう今熟成してきたっていうふうな捉え方もできるなって感じですね。
去年もそうですけどいろんな勉強会で、日本の勉強会でSvelteKitを使ったっていう登壇の僕何本か聞いたんですけど、
やっぱそれだけもう今アプリケーション作るのに十分なフレームワーク機能として熟成してきたんだろうなっていうのはよく分かったので。
なるほどですね。
いわゆるこのバーセルチームがそこを参照するレベルでSvelteKitは今もう進化したなっていう素晴らしいなと思いましたね。
こうやってお互いのアイディアとか機能だったりっていうのをインスパイアし合っているっていうこの文化もなかなかいいなと思いますけどね。
では続いていきましょう。
今のがカスタムルートハンドルだったんですけど、次はMDXですね。
MDX for Server Componentsのところに入ります。
MDXっていうのはマークダウンのスーパーセットになっていて、マークダウンファイルの中に直接JSXを記述することができます。
MDXは動的なインタラクティブ性を追加していて、コンテンツにリアクトコンポーネントを埋め込むための強力な方法になります。
13.2ではリアクトサーバーコンポーネントでMDXを完全に使用できるようになりました。
つまり動的なUIをテンプレート化するリアクトの強力な機能をそのままに、クライアント側のJavaScriptを減らしてページロードを高速化できます。
必要に応じてMDXのコンテンツにインタラクティブな機能を組み込むことができます。
これは中の人がツイートしていて、そのツイートのリンクが貼られていますね。
It looks me only an hour with NextMDX Remoteのバージョン4.3.0というのがかなり速くなったというのをツイートしていますね。
そのパフォーマンスを一応数字測ってみたらしくて、その数字がかなり劇的に変わったよということを言っていますね。
アブソリュートリーアメージングと言っているので、めちゃくちゃびっくりするぐらいパフォーマンス改善されたということを言っていますね。
それのツイートはあれとして、ちょっと本文に戻りましょうか。
next.atnext.mdxというプラグインがアップデートされていて、
カスタムコンポーネントを提供するためにアプリケーションのルートに定義される新しい特別なファイル、
mdx.components.jsもしくはtsというのがサポートされるようになりましたよと。
ファイルの中身はざっこりありますけど、
ファンクションのh1みたいな関数で引数にチルトンを受け取ったりとか、
h2でチルトンを受け取ったりとか、
それに対してエクスポートファンクションのuse.mdx.componentsで引数コンポーネントを受け取って、
リターンでh1タグだったらさっきのh1関数、h2だったらh2関数、
あとは残りはオブジェクト展開でコンポーネントを渡してあげるみたいなので、
リターンをするっていう使い方ができますよと。
僕あんまりmdxを使ってないので、ここがどれだけすごいのかがあんまりまだ理解できないですけど、
for-server-componentsって言っているので、
そのことの連携を関数で切り出してやっているというのが一つの進化なんだろうなと思いますね。
僕が本当にこの辺まだノータッチなので、感想しか述べられなかったですけど。
さらにmdxのコンテンツを取得するためのコミュニティパッケージ、
next-mdx-remoteとコンテンツレイヤーと連携して、
12:01
react-server-componentsのサポートも追加しています。
詳しくはmdx-with-server-componentsというドキュメントがあったりとか、
deployer-y-exampleというのがあるので、その辺のサンプルのリポジトリとかも見てみてください。
では続きまして、もうちょっとmdxの話が続くんですけど、
今度はlast-mdx-parserですね。
やっぱ今、ラスト本当に盛り上がってきてますね。
mdx-for-server-componentsの有効化の一環として、
mdx-parserというのをラストで書き換えてパフォーマンスを向上させました。
これは大量のmdxファイルを処理する際に顕著な速度低下というのが見られました。
以前のJavaScriptベースのパーサーを大幅に改善するようなものです。
JSという言語はやっぱり言語そのものの速度って遅いんですよね。
かつこういう処理というのはぶっちゃけバックエンド側でゴリゴリやりたいものなので、
それをラストで書き換えたらそれは速くなるでしょうというのはもちろんありますし、
そこに真剣に取り組んだのはやっぱバーセリラさすがなという感じがします。
ラストパーサーの仕様というのはnext-config.jsで選択することができると、
オプショナルなんですね。
例えば、next-mdxのところですけど、
const next-config.jsをオブジェクトにしておいて、
experimentalというキーにしているんですね。
その中にapp directoryをtrueでmdxrsというオプションがあります。
これをtrueにしておくと。
そうすると発火してくれる感じになると。
本当オプションは一発でやってくれると。
でも元通りのJSでやりたい人いるんですかね。
単純にパフォーマンスを改善するというだけであれば、
普通にデフォルトでいいんじゃないかという気はしますけど、
一旦は介護官とか何とかを加味してオプショナルにしたのだろうとはもちろん思います。
このプロジェクトにスポンサーとして参加されたタイタスウーマーには感謝します。
next-jsの他でこれを使いたい場合は、
新しいパッケージmdxjs-rsというのがモジュールで出ているので、
これもチェックしてみてください。
next-jsでなくても使いたい場合はこれを使えるようにしてますよと。
next-jsの外で講演を使う機会ってあるのかな。
mdxjs-rsっていうのがあるんですね。
単純にmdx、nextじゃなくてもmdxはありえるか。
jsxをマークダウンの中で使いたい人って別に他のフレームワークでもありそうなんで、
そのためにも一応パッケージとして切り出していますよということですね。
昨今のjsフレームワークって、
jsxとフックスの概念が入っているっていうフレームワークが主流というか当たり前になってきてますよね。
なのでこの流れは多分止まらない気がするので、
基本的にはmdxとjsxの需要っていうのはこのままずっと続けるし、
その辺のエコシステムのライブラリーが増えるんだろうなって気はしてます。
てかそういうふうなものに集約するんじゃないですかね。
逆にフックスがなかったりするものはどんどん淘汰されていくかもしれないなっていうのはちょっと僕は思ってますね。
個人の考えでした。
続いてスタティカリタイプドリンクですね。
静的片付けのドリンクのお話に移ります。
静的片付けリンクですけど、
Next.jsではアプリディレクトリ内のリンクを静的にタイプすることで、
15:02
next-linkっていうモジュールを使用時のタイプミスなどを防いで、
ページ間を移動する際のタイプセーフティを向上させました。
地味な改善ですけど地味にありがたいやつですよね。
ここをちゃんと型定義でタイプミスとかヒューマンエラーっていうのをちゃんと機械が教えてくれるようになるっていうのはすごくありがたいですね。
設定とかは別に特になくて、今のままそのまま使えるようになるよってことですね。
今まで通りインポート、リンクフローもnext-linkで使っておいて、
各中身のところで普通にエラーを検知することができるようになりますよってことですね。
この機能っていうのを利用するには、タイプスクリプトだけじゃなくて新しいアップルーターを使う必要がありますと。
ただ事実上もnext-13必ず上げろって言ってますね。
これが欲しい場合は。
まあまあ、そりゃ仕方ないよね。
12に対してこの機能を入れると結構重いんでしょうね、しかも。
はい、っていうところでした。
なので新しいアップルーター必ず使ってねということで、
さっきのそのnext-configですけど、
next-configのエクスペリメンタルのところにApp Directoryをtrueにするっていうのが前提です。
あとはタイプルーツっていうのをtrueにしてくださいと。
こっちのも一応オプショナルな設定で使えるようなものということですね。
デフォルトで入ってるってわけではないってことですね、これは。
使いたい場合はオプションをtrueにしてくださいってことでした。
はい。
っていうのはこの機能はまだ現在ベータ版として提供されてるからですね。
まあまあ、エクスペリメンタルで書いてるから。
まあそりゃそうなんでしょうけど。
で、あとこれですね。
リライドとリダイレクトっていうところがまだサポートされてないっていうのも注意してくださいと。
そう言われるとまあまあまだまだベータ版だっていうのはよくわかりますね。
はい。
リンクなのでそれはリライドとかリダイレクトはサポートしてほしいよね。
なのでこれ今後のNext.jsの進化を待ちましょう。
まあでも13.2では一旦頭出しとしてこんな機能を実験的に入れてますよっていうので見てみてください。
これでユーザーからの意見だったり感想を述べつつブラッシュアップをしていきたいんでしょうね。
はい。
まあ昨今そういう流れをやっているのはすごくいい話だなと思いますね。
別に一周に参加しなかったとしても自分たちでこう意見を出すことは全然できますしね。
では続いてですね。
Improved Error Overlayの話です。
はい。
まあエラーが出たときにオーバーレイのなんかいろんな改善があったそうですね。
エラーの読みやすさとデバッグのしやすさを向上させるためにNext.jsのエラーオーバーレイにさまざまな改良を加えましたよと。
13.2ではNext.jsとリアクトのスタックトレースが分離されましてエラーの発生元を特定するのが余裕になりました。
うわーこれもありがてえな。
スタックトレースがちゃんと分離している。
リアクトとNext.jsでスタックトレースを分離したっていうのはすごくいい話ですね。
さらにエラーオーバーレイにNext.jsの現在のバージョンが表示されるようになってお使いのバージョンが最新かどうか把握しやすくなりましたと。
地味なあれですけどやっぱ欲しかったやつだよねこれね。
ちゃんとバージョンが書かれるってのはすごく嬉しいですね。
記事内ではソースコードとかエラーが起きたときのコードのキャプチャーが貼られてますね。
リアクトの後のハイドレーションエラーの出力も改善してより読みやすくなってデバスクしやすくなったよっていう話をしてますね。
地味にその辺の改善をしてます。
ちょっとオーバーレイに関してはそれぐらいだけだけど入ってますよってことですね。
18:01
続いてがTurboPack Improvementsですね。
僕はTurboPackも全然使ってないというか。
Next.js 13を実は触ってないのでまだ情報だけしかないですけど一応見てみましょうか。
TurboPackの改善です。
TurboPackはNext.js 13のアルファ版として発表されたものでローカル開発だけじゃなくて将来のプロダクションビルドのスピードアップのために設計されたインクリメンタルなバンドラーだと言ってますね。
TurboPackっていうのはNext.jsの既存機能のサポートとベータ版への移行に伴う全体的な安定性の向上に重点を置いてます。
前回のリリースから次のような機能が追加されましたというので、1,2,3,4,5,6,7個ですね。
1つ目はnext-dynamicっていうモジュールのサポートが入りました。
2つ目にnext-config.jsでリライト、リダイレクト、ヘッダー、もしくはページエクステンションとしてのサポートをしました。
3つ目にページ内の404エラーに対応してます。
4つ目、CSSモジュールコンプレッスっていうのをサポートしてますよと。
要はこの頃のfromっていうのをサポートしましたよということですね。
experimental.turbo.loadersっていうのを使って、各ファイルの拡張子に対するローダーのリストを設定することができたりします。
これはソースコード見てみたら一目瞭然なので見てみてください。
config.jsの中のexperimentalでturboっていうキーを付けたオブジェクトがあって、その中にloadersっていうのがあって、
それぞれの拡張子ね。
.mdはこういう設定、.svgrはこういう設定。
で、その中にそれぞれのローダーを設定してもらえればいいですよってことですね。
これは100分は意見しかないので見てみてください。
あとは公式のローダーを使ったTurboPackのエグザンプルがあるので、そこを見てもらってもいいと思います。
これは完全なエグザンプルって書いてますね。
コンプリートエグザンプルって書いてあるので、参考になるんじゃないかなと思いました。
続いてはWebpackスタイルResolveAliasですね。
Aliasを解決するってことですね。
TurboPackっていうのはWebpackのResolve.Aliasと同様に、
Aliasを通してモジュール解決を行うように設定できるようになりました。
この設定もさっきと同じですね。
コンフィグでやるそうですけど、
Experimental.Turbo.ResolveAliasっていうのでやりますよと。
その一言で終わりました。
続いて、Next.jsのキャッシュのお話ですね。
これ結構大事な話だと思うんですけど、
Next 13.2ではISRの進化を解き放つ新しいNextキャッシュっていうものの
ベータ版が一応導入されてます。
大きく三つですね。
一つはコンポーネントレベルでのプログレッシブISRです。
これありがたいですよね。
細かく細かくプログレッシブにISRっていうのを導入できるようになったってことですね。
基本的にはページ単位な気はしましたけど、
これをコンポーネントレベルでできるっていうのはすごくありがたいけど、
それとも背景にリアクトサーバーコンポーネントがあるからっていう気はします。
続いて二つ目がネットワークリクエストなしで
より高速なリフレッシュを実現しているそうです。
これどうやってるのかすごい気になりますよね。
続いて三つ目が静的ページへのコード変更の再展開を高速化しているってことですね。
21:01
要はキャッシュを使うってことですね。
すなわち。
完全に静的なページではISRは現在と同じように動作します。
静的と動的が混在するより流度の細かいデータフェッチを行うページっていうのでは
Next.jsキャッシュっていうのはより流度の細かいエフェメラルキャッシュっていうのを利用しています。
エフェメラルキャッシュってのは初めて聞きました。
そんなのがあるんですね。
リアクトサーバーコンポーネントの基盤とNextのアプリルーターですね。
アップのところでデータ取得のコロケーションによって
静的動的データを消費するコンポーネントの一緒にカプセル化できるようになりましたよと。
ソースコードばーっと書いてますけど。
なんかエクスポートのデフォルトでレーシングファンクションでなんかページっていうのを作っておくと。
これはダミーですね。
フェッチを細かくいろいろできると。
そのフェッチするときの台に引数にいろいろなものを設定しますけど。
例えばリバリデートを設定するとかキャッシュをするとか。
キャッシュでノーストアを設定するとか。
いろんな設定できますけど。
今までのページのファイルの中で同じようなことをやればいいとかですね。
なんか制約とかあるのかな。
アップルーターを使用してローカルで開発する場合は
NextDevっていうコマンドで今までの本番と同じキャッシュ動作がNextスタートで表示されるようになりましたと。
これによってサーバーコンポーネントとかデータロードの行動が変更されるときの高速リフレッシュの速度も向上してますと。
NextのキャッシュではサードパーティーのAPIだけじゃなくて
クライアントのアプリがキャッシュを制御します。
これはキャッシュコントロールヘッダーとは異なって
上流の方で値をキャッシュする機関っていうのを制御するようになると。
側の方でよりコントローラブルにしたってことですね。
そこはそれでいいのかなって気はしますが。
バックエンドだけでやるってのも難しいですね。
キャッシュが必要になるのは結局ユーザー側だと思うんで、
ユーザーに近づけたってことか。
ちょっと思想が分からないんですけど、
この辺は今後の進化を追っていきたいと思いますね。
続いてもうちょっとキャッシュの端がコマコマ続きます。
続いてはNext.jsのキャッシュですけど、
with the BarcellキャッシュAPIですね。
BarcellキャッシュAPIでNextのキャッシュを実現しようと。
BarcellのNext.jsっていうのはフレームワークで定義されたインフラを提供します。
お客様はフェッチによるコンポーネントレベルでのデータ取得のような
コードを書くだけで追加の労力を必要とせず、
グローバルに分散したインフラストラクションのアーシュマークを得ます。
要はNextアプリを使って作っている人たちは
Barcellを使えばバーセルが勝手にキャッシュもしてくれるので、
そのインフラ周りをよしなりにやるから
アプリケーションに集中してねっていう話ですね。
これはもう完全にバーセルが俺らを使えって言ってますね。
新しいNextのキャッシュっていうのは
コードの変更をデータの変更から独立させます。
静的ページの生成に既存のキャッシュを使用できるようになるため、
静的ページの再展開を劇的にスピードアップすることができます。
それはそうだよね。
この新しいバーセルキャッシュAPIっていうのは
あらゆるフレームワークで動作するように設計されてはもちろんいますけど、
Nextキャッシュとのネイティブな統合を備えています。
ISRがNextのキャッシュに進化した経緯とか、
Nextキャッシュをバーセルにデプロイした時の動作については
別の記事があるのでそちらを詳しく知りたい人は見てみてください。
Learn more about how ISR resolves into the Next.js cache
24:03
という記事があります。
これ気になるんで明日もこのリンクの記事読もうかな。
明日の自分の気分によりますけど。
続けていきましょう。
続いてはNextキャッシュ運営セルフホスティングですね。
セルフホストの時のNextキャッシュについての話ですけど、
セルフホスティングの場合はURLキャッシュが使用され、
デフォルトで50MBに設定されています。
キャッシュの全てのエントリーというのはデフォルトで自動的にディスクに書き込めます。
このファイルシステムキャッシュというのは
同じキャッシュキーを持つノード間に共有することもできて、
現在のISRの仕組みとは結構似てますよと。
Nextキャッシュのコアはさらにカスタマイズして変更したい会社というのは、
基本的なキャッシュキーというのを変更して
キャッシュエントリーを永続化する方法と場所というのも変更できるようになります。
その永続化を完全に無効にすることももちろん可能ですよと。
さらにノーキャッシュを設定すればいいんでしょうけど、
おそらくこの辺はNextコンフィグに設定できるようになっているんじゃないかなと予想します。
あとはOther Improvementsでいっぱいいろんなのがあるんで、
その辺は見てみてねということですけど、
ざっと書いてあるのでざっと述べて、たぶんこれで終わりですね、この記事は。
最後ざっと読みますね。
その他の改善点ですけど、
まずフォントだと。
コミュニティでの教育的な採用を受けて、
NextフォントというモジュールはNext.jsに組み込まれになったと。
つまり、At Nextスラッシュフォントというのを個別にインストールする必要がなくなりましたと。
詳しくはこちらの記事を見てねということです。
続いてもう一個フォントですけど、
コミュニティフィードバックに基づいて、
Nextスラッシュフォントのデフォルトの
font-displayというプロパティがあるんですけど、
これがオプショナルからfont-display://に変更されましたよと。
続いてパフォーマンスビルドのプロセスを最適化して、
より少ないメモリを使用するようにしましたと。
これはなんかこちらのPR見てねってことです。
ここ、あとパフォーマンスがもういくつか続きますね。
プロジェクトのセットを何度も読み込まないように、
テストでは400ミリ秒の高速ビルドを実現したよということを言ってます。
大体で400ミリ秒になるよってことだそうですけど、
ほんまかいなって感じですね。
テストではって言ってるんで、
そのテストの流度とかテストファイルの多さとか、
設定周りとかでどれだけあるかもしれないのと、
あとはテスティングフレームワーク何を使うかによって
全然変わる気がしますけどね。
続いてパフォーマンスエラーのコンポーネントを最適化して、
スタイリングを変更せずにHTMLのペイロードを
0.4キロバイト削減しました。
0.4キロバイトに削減したならわかるけど、
ちょっとだけ削減したのかなこれは。
続いてバーセルのようなエッジ環境に展開した際の
コールとブートサイズをさらに削減するために、
エッジバンドルのサイズを
ほぼ半分の130キロバイトに削減した。
これはいい話ですね。
なるほどでした。
続いてセキュリティですね。
設定ですけど、
image.contents disposition type.attachment
っていうのを追加してるってことですね。
アタッチメントを追加して、
Image Optimization APIに直接アクセスしたときに、
画像を強制的にダウンロードされるようにしました。
これがセキュリティの話なのか、
っていうのはちょっと僕はわからないので、
PRの中身を見るとわかるかもしれないですね。
というところです。
いろんな改善も入ってますよってことだし、
27:01
パフォーマンス周りがやっぱり大きそうですね、これは。
さっきのフォントのところもサイズを小さくするって、
要はパフォーマンスの話だと思いますので。
はい、というところですみません。
相変わらず早口かつ駆け足だったんですけど、
いったんNext.js 13.2のリリースブログでした。
今後のフロントエンドもまだまだ、
結局主流はNextになるなって気はしますね。
Nextというか結局リアクトですけど。
今後はメタの思想に乗っかる流れにはなる気はしますけど、
さっきも言いました、
Fuchs周りとかJSXがデフォルトのフレームワークが今後、
その2つが入っているフレームワークが
今後の主流になることは間違いないと思ってて、
その中でやっぱりサーバーコンポーネンツっていうのを
入れてるのはやっぱり今のところリアクトだけなので、
まだまだリアクトが主流なんだろうなと思ったりしますね。
よりサーバーと細かく柔軟に設定できたり
変更できたりとかですね。
あとコンポーネント単位でISRできたりするっていうところで、
リアクトNextっていうのがまだまだ第一線の
一番に上がるんだろうなって気はしてます。
今後もこの思想を乗っかっていくのが
いいんじゃないかと思いますけどね。
スベルトとかソリッドJSみたいな、
仮想ドームを使わない奴らがどこまで食い込んでくるかってのは
今後の課題でありますけど、
書き方とか開発者に沿ったもの、
あとはアプリケーションの設計をどこまで柔軟にできるかっていうのを
フォーカス的に見てるのはやっぱりまだまだ
リアクトNextが一律の長があるので、
この2つなんだろうなって気はしてました。
しっかりこのフレームワークの進化を今後も持っていきたいというので、
読むだけじゃなくてやっぱり書いていかなきゃいけないと思いますので、
ここもしっかり手を貸していきたいかなと思ったりしています。
長くなりましたけど、
今日の朝活は以上にしたいと思います。
気づいたら多くの方参加いただきありがとうございました。
ねぐさんとさがっとさんとおゆさんと
陽平よしかわさんと最後ココさんですね。
はい、ご参加いただきありがとうございます。
明日もこんな感じで緩く読んでいきますので、
興味があれば参加してみてください。
じゃあ土曜日ですね。のんびり休んでいただければ。
