Next.jsでプロダクションリリースするときに確認したい項目 in スペースマーケット

梅雨も明けて、海で過ごすのが夏らしい季節になってきました。うぇいうぇい 🏖

こんにちは！エンジニアのほりです。

この度スペースマーケットでは、ワークスペースに特化した、遊休スペースとなっている会議室やオフィスをシェアできる「スペースマーケットWORK」の提供を開始しました。

スペースマーケットWORK | 貸し会議室からレンタルオフィスまでワークスペース簡単予約

今回、フロントエンドの開発にあたりNext.jsを採用し、弊社としては初めての本番運用だったので、リリース前にチェックしたい項目としてのポイントをnoteにまとめようと思います。

プロダクトやチームによってもちろん差異がありますが、もしこれから新規サービスをローンチする場合の目安にしていただければと思います。

実装編

不要なconsole.logを残していないか

開発用に実装したログ出力が残っていないかを確認します。Linterなどでチェックしてもいいですね。また、ログ出力をミドルウェアで行う場合はproductionビルド時に必要最低限のものだけ表示されているかなどをチェック。

ページのソースで不要な情報が出力されていないか

Webブラウザでページのソースを表示したときに、公開されるべきではない環境変数やシークレットな情報がレンダリングされてしまっていないかを確認します。

環境変数などに固定文字列を使っていないか

サードパーティのライブラリに使うAPIKeyなどがきちんと環境変数化されているかを確認します。

本番ビルド時にSourceMapが出力されていないか

Sentryへの連携やデバッグ時に必要となるSourceMapが本番環境で出力されないように設定します。実際に配信されるJSファイルを確認し、SourceMapに関する記述がないかを確認します。

https://github.com/vercel/next-plugins/tree/master/packages/next-source-maps

セキュリティ系の設定が有効になっているか

helmetなどでセキュリティの設定をした場合や、Next.js用にセキュリティに関するpluginを導入した場合に設定が有効に働いているかを確認します。

テスト編

サポートしているブラウザでの動作確認、UIくずれの確認

対応ブラウザでマークアップの崩れがないか、JSの読み込み失敗がないかなどを確認します。IE11などChromiumベースではないブラウザもサポートする場合はpolyfillが効いているかなど別途確認していきます。

TIPS：Next.jsではnode_modules以下のpackageについてはトランスパイルをしないためquery-stringの6系以上だとIE11で対応できないarrow functionを含んだまま配信されていることでIE11でJSエラーが起こることがありました。IE11をサポートする場合、そのようなpackageがないかという観点での確認も必要になります。

モバイルは実機での動作確認、UIくずれの確認、使い心地

モバイルの場合は、PCでのエミュレート以外にも実機での確認を行います。また、実機ならではの操作感や使い心地などに違和感が無いかなども確認します。（タップ領域やスムーズスクロールなど）

TIPS：SafariやiOS Safariなどブラウザの「戻る」の挙動が異なる場合（戻る場合にリロードではなくキャッシュから読み込まれる）や、iOS実機ならではのスワイプバックでのブラウザ操作でも影響がないという観点での確認をすると良いと思います。

既存のネイティブアプリとの連携部分が動くか

スペースマーケットでは、予約時の日時選択カレンダー〜予約完了までの画面を本サイト／ネイティブアプリ／WORKサイトで共通で利用しています。特にネイティブアプリに関してはDeepLinkを使用している場合など、サブドメインからの画面遷移を行う場合にネイティブアプリが割り込もうとしてくるかどうか、新サービスによるデータ仕様の影響範囲がどの程度あるかどうかを、アプリの現行バージョン／過去バージョンに関して確認することが必要になります。

サーバーサイドレンダリングが正しくされているか

insomniaなどのRESTクライアントでページをGETして期待通りのHTMLが組み立てられてレスポンスされるかを確認します。Webブラウザでは問題なさそうでも、実はCSRだったということもあるので実際にレスポンスを確認するのが良いと思います。

リリース編

インフラ（ホスティング先）の選定

Next.jsであればVercelへのデプロイが簡単ですし、node.jsアプリケーションとしてECSでもGAEでも動かすことができます。

今回は既存の仕組みやプライベートなnpm moduleの絡みで、ECSでマネージメントすることにしました。

エラーレポーティングツールとの連携確認

今回はSentryを使用し、こちらを参考に設定しました。

Sentry連携のために1度SourceMapを有効にしてビルドした後、配信のためにSourceMapを無効にして再度ビルドするという方法を採用しました。

Next.jsでは、ビルドごとにビルドIDが発行されるので、配信しているJSのビルドIDと、Sentryに送信されたSourceMapの最新のビルドIDが一致していることを確認します。

アクセスログを取得できるようにする

標準のままだとアクセスがあった場合に特にログを出力しないため、morganなどを利用してHTTPアクセスを自動的にログ出力するようにすると運用時に助かります。

アセット類のCDN配信

JSや画像ファイルなどをCDNで配信するように対応したら、Next.jsでのアプリケーション側についても取得先をCDNに向けるように設定します。

https://nextjs.org/docs/api-reference/next.config.js/cdn-support-with-asset-prefix

robots.txtの設置

SEO観点、負荷軽減の観点など、プロジェクトごとの方針になりますが、robots.txtが読み込める状態で設置されていることを確認します。

パフォーマンスの検証

Lighthouseなどでパフォーマンスを計測します。Webページが誰でも見れるようになったらPage Speed Insigntsでも確認します。CDNにしたことで実際にデリバリー速度が向上しているか、JSや画像などアセット類のサイズが適正か、レンダリングに関するボトルネックが無いかなどを確認していきます。

リリース後

アナリティクスツールの連携確認

Google Analyticsなど設置している場合は、リリース後に正しく連携されているか、アナリティクスが開始されているかをダッシュボード等で確認します。必要であれば各イベントが送信されているかもテストします。

サイトマップの送信

サイトマップを作ってGoogle Search Consoleで送信します。

visualsitemaps等を使用して視覚的にサイトマップが有効かどうか確認してみると良いと思います。

以上、一部ではありましたが最低限確認したい項目をまとめてみました。

今後自分でもサービスを公開する場合などには振り返ってチェックしてみたいと思っています。