画面がちらついていた時代
以前のウェブサイトはメニューを押すたびに画面が一瞬白くなった。回線が遅ければ長く、速ければ短く見えただけで、構造は同じである。
理由は単純だ。ページを移るたびにブラウザがサーバーへその住所に対応する新しい文書を求め、受け取ったもので画面を丸ごと描き直していたからだ。この方式を複数ページ方式という。
画面一つが文書一つなので構造が単純という利点があった。検索エンジンも住所ごとに完成した文書を受け取るので読みやすかった。
モバイルアプリが基準を上げた
そこへモバイルアプリが現れた。アプリはウェブと根本が違う。ストアから落とす時点で、画面を描くのに必要なものをすでに端末に入れてある。
だから画面を移るときサーバーへ文書を求め直さない。移動は即座に行い、その画面に入れる値だけをサーバーから受け取って埋める。ちらつかず、なめらかだ。
この感覚を味わった利用者の基準が上がった。ウェブでもできないのかという問いが生まれ、答えはできる、だった。
一ページ方式がその答えである。最初に入るとき必要なものを受け取っておき、利用者が別の画面へ行くと言えば、隠しておいた画面を出して見せる。捨てて取り直すのではなく、隠して出すのだ。
| 複数ページ方式 | 一ページ方式 | |
|---|---|---|
| 移動するとき | サーバーへ新しい文書を要求 | 受け取り済みの画面を出す |
| 体感 | 一度ちらつく | 即座に切り替わる |
| 検索エンジン | 読みやすい | 注意が要る |
| 最初の読み込み | 軽い | 重くなりうる |
そこで生じた問題とその解き方
一ページ方式には代償があった。画面をブラウザで描くと、検索エンジンが訪れたとき JavaScript が動く前の空白を見ることがある。
この問題は以前ほど深刻ではない。検索エンジンが JavaScript を実行して結果を読むようになって久しい。ただしリンクを共有したときに出る preview カードのように、サーバーがあらかじめ描いておいた内容を必要とする場所は残っている。
そこでサーバーで先に描いて送る方式が併用される。サーバーサイドレンダリングという。完成した画面をサーバーで作って送り、その後はブラウザが引き継いでなめらかに動く。
この二つを一つのプロジェクトの中で画面ごとに選べるようにしたのが Next.js だ。最初の画面や共有される記事ページはサーバーで描き、ログイン後のダッシュボードはブラウザで描く、といった分け方ができる。
フレームワークと呼ぶ本当の理由
Next.js をフレームワークと呼ぶのは描画方式のためだけではない。いまのウェブ開発がどう行われているかと関わっている。
今どきサイトを作るのにすべてを一から書くことはない。ログイン、カレンダー、動画再生機のように多くの人が繰り返し使う機能は、すでに誰かが作ってある。その作り置きの塊をパッケージといい、取ってくる倉庫が npm である。
だから自分のプロジェクトは、他人が作った部品の山と自分が書いたコードの組み合わせになる。問題はこの状態のままではブラウザが読めないことだ。ブラウザが読むのは第二回で見た三つのファイルだけである。
その変換をしてくれる工程がビルドだ。部品と自分のコードを合わせ、割って束ね、ブラウザが読める形に変える。デプロイに数分かかるのはたいていこのビルド時間であり、決められた規則どおりに書けば残りを代わりにやってくれるので、フレームワークと呼ぶ。
npm から受け取った部品
+ → ビルド → ブラウザが読める
自分が書いたソースコード HTML · CSS · JavaScript
デプロイにかかる数分は、たいていこの矢印の区間だ