静的ウェブサイトと動的ウェブサイト：違い、例、選び方

「 静的ウェブサイトと動的ウェブサイト 」の主な違いは、コンテンツがいつ、どこで生成されるかです。静的ページは、訪問者からリクエストされる前に用意されます。動的ページは、サーバーまたは訪問者のブラウザー上で、実行時にコンテンツを生成または取得します。

この違いは、公開、ホスティング、キャッシュ、リアルタイム情報へのアクセスに影響します。ただし、ウェブサイトにアニメーションを含められるか、フォーム送信を受け付けられるか、ショッピング体験を提供できるかを示すものではありません。これらの機能は、ページのコードや連携するサービスによって決まります。

ウェブサイトの制作や移行を検討する際に重要なのは、そのサイトが担う役割にどちらのアプローチが適しているかという点です。同じ企業のサイトでも、製品のランディングページ、リアルタイムの予約カレンダー、顧客向けダッシュボードでは、それぞれ異なる要件があります。

このガイドでは、2つのアプローチを比較し、共通する部分を説明するとともに、TeleportHQで静的ページやデータ連動型ウェブサイトをどのように扱うかをご紹介します。

このガイドの内容#

• 静的ウェブサイトと動的ウェブサイトの概要
• 静的ウェブサイトとは？
• 動的ウェブサイトとは？
• 静的ウェブサイトに動的な機能を追加できますか？
• 静的サイトと動的サイト：実用面でのトレードオフ
• SEO、AIによる概要、LLMでの可視性
• ウェブサイトビルダー、CMS、フレームワークの例
• TeleportHQが静的サイトと動的サイトに対応する方法
• どちらの方法を選ぶべきですか？
• よくある質問

静的サイトと動的サイトの概要#

静的ページは、あらかじめ生成されたドキュメントを配信します。サーバーでレンダリングされる動的ページは、必要に応じてドキュメントを組み立てます。また、最初のドキュメントが届いた後、ブラウザーでデータを読み込むページもあります。

これらの方法は併用できます。たとえば、オンラインストアでは、商品説明をあらかじめ生成し、APIで最新の在庫情報を取得し、バックエンドで注文を処理できます。

これらの分類は実装方法の違いを表すものです。小規模なウェブサイトと大規模なウェブサイト、あるいはシンプルなデザインと高度なユーザー体験を区別するものではありません。

静的ウェブサイトとは？#

静的ウェブサイトは、訪問者からのリクエスト時に、すでに存在しているページを提供します。これらのページには、構造を定義するHTML、表示を整えるCSS、そして操作のためのJavaScriptが含まれていることがよくあります。

ファイルはウェブサーバーから配信したり、コンテンツ配信ネットワーク（一般にCDNと呼ばれます）を通じて配信したりできます。ドキュメントはすでに用意されているため、訪問のたびにデータベースのレコードから再構築する必要はありません。

「静的」といっても、コンテンツをずっと変更できないわけではありません。ソースを更新し、新しいファイルを生成して、ワークフローに合わせた頻度で公開できます。

静的ページの作成方法#

作成方法はいくつかあります。

• HTMLを直接記述する。 小規模なプロジェクトには適していますが、テンプレートがないと同じ作業の繰り返しが多くなります。
• ビジュアルビルダーを使う。 インターフェースを通じてコンテンツやレイアウトを編集し、生成された出力を公開します。
• 静的サイトジェネレーターを使う。 テンプレートとMarkdown、構造化ファイル、またはAPIデータを組み合わせてページを生成します。
• コンテンツ管理システムを連携する。 編集者がCMSでコンテンツを更新し、ビルドプロセスによって公開用ページを生成します。

A 静的サイトジェネレーター を使えば、再利用可能な1つのレイアウトから多数のページを作成できます。たとえば、300講座のコースカタログでも、300個のドキュメントを人手で個別にデザインし、管理する必要はありません。

コンテンツの元データがデータベースに保存されている場合もあります。生成されたページが静的なのは、訪問者のリクエストごとに組み立てるのではなく、配信前にHTMLを生成するためです。

静的ウェブサイトのメリット#

• シンプルな配信： リクエストごとにページ生成アプリケーションを実行せずに、生成済みのファイルを配信できます。
• 効率的なキャッシュ： 共通のファイルは、CDNを通じた配信に適しています。
• 運用コストを抑えられる可能性： 公開コンテンツの配信に、常時稼働するアプリケーションサーバーが必ずしも必要とは限りません。
• 柔軟なデザイン： テンプレートやコンポーネントを使って、ウェブサイト内でさまざまなレイアウトに対応できます。
• 公開環境の実行時コンポーネントを削減： 配信されるページで公開されるサーバーサイドのアプリケーションロジックを減らせる場合があります。

考慮すべき制約#

生成ファイルを最新の状態に保つには、更新を公開するためのプロセスが必要です。大規模なサイトでは、小さな変更のたびにすべてを再構築するのが煩雑になることがあるため、ビルド戦略が重要です。

また、静的ファイルだけでは、決済を安全に処理したり、アカウントの権限を確認したり、顧客情報を共有して保存したりすることはできません。こうした処理には、独自に管理する場合でもホスティングサービスを利用する場合でも、バックエンドが必要です。

静的アーキテクチャは、事前に用意できる公開コンテンツに特に適しています。サービスページ、記事、ドキュメント、ポートフォリオ、多くの商品説明などが該当します。

動的ウェブサイトとは？#

動的ウェブサイトは、実行時のロジックを使ってコンテンツを生成または取得します。訪問者のリクエスト、アカウント、選択したフィルター、データベース内の最新情報に応じて内容を変えられます。

動的なページがすべて個別にパーソナライズされているという意味ではありません。サーバーは、何千人もの訪問者に同じ公開記事を生成できます。あらかじめ作成されたファイルを配信するのではなく、リクエスト時にアプリケーションがページを組み立てる場合、そのページは動的に生成されています。

動的ページの仕組み#

よく使われるパターンは次の2つです。

• サーバーサイドレンダリング： サーバーがアプリケーションのロジックを実行し、必要なデータを取得して、ページのコンテンツを含むHTMLを返します。
• クライアントサイドレンダリング： ブラウザー上で動作するJavaScriptがインターフェースを構築または更新します。多くの場合、APIから取得したデータを使用します。

多くのアプリケーションでは、これらを組み合わせています。サーバーが初期ページ全体を返し、その後、ブラウザー上のコードがフィルターを処理したり、グラフを更新したり、追加の結果を読み込んだりします。

たとえば、学生用ダッシュボードでは、ログインしたユーザーを確認し、そのユーザーが履修している科目を取得して、進捗状況を表示できます。別の学生には、同じインターフェースを通じて異なる記録が表示されます。

動的ウェブサイトのメリット#

• 最新情報： サイト全体を再構築するのを待たずに、更新されたばかりのデータをページに表示できます。
• 継続的な操作： 訪問者はバックエンドサービスを通じて、アカウントの作成、注文の送信、設定の保存を行えます。
• パーソナライズされた体験： 認証されたユーザーは、自分の購入履歴、メッセージ、設定を確認できます。
• 構造化されたコンテンツ管理： 共通のテンプレートを使って、中央のデータソースにあるレコードを表示できます。
• アプリケーションのワークフロー： 送信されたフォームをきっかけに、入力検証、データベースの更新、その後の処理を実行できます。

考慮すべき制約#

実行時の機能には依存関係が伴います。データベースへのクエリが遅い、APIを利用できない、アプリケーションサーバーに負荷が集中しているといった状況は、訪問者の体験に影響する可能性があります。

また、チームはアクセス権限、データストレージ、ソフトウェアの更新、監視、復旧のプロセスも管理する必要があります。マネージドプラットフォームがインフラの多くを担う場合でも、ウェブサイトのロジックは適切に設定しなければなりません。

デザインの自由度が低いことや検索パフォーマンスが悪いことは、動的ウェブサイトに本質的に備わる性質ではありません。こうした結果は、プラットフォーム、実装、保守の選択によって左右されます。

静的なウェブサイトにも動的な機能を追加できますか？#

はい。静的なHTMLを配信するウェブサイトでも、インタラクティブな機能やデータに基づく機能を提供できます。重要なのは、ページ内で行われる処理と、その背後にあるサービスで行われる処理を区別することです。

静的サイトと動的サイトの違いを説明するとき、混乱が生じやすいのはこの点です。クリックして開くメニューはインターフェースを変化させますが、サーバーが新しいドキュメントを生成する必要はありません。静的なページに決済フォームを表示することもできますが、決済処理そのものは別のサービスで行われます。

ブラウザー上の操作に動的なページ生成は不要#

JavaScriptとCSSは、次のような操作を実現できます。

• ナビゲーションメニューやアコーディオンを開く。
• タブを切り替える。
• 訪問者のスクロールに合わせて要素をアニメーションさせる。
• ページ上で利用できる値をもとに、価格の目安を計算する。
• 読み込み済みのリストを絞り込む。
• ブラウザーにローカルの表示設定を保存する。

これらの機能は、あらかじめ作成されたページで動作します。必ずしもデータベースやアプリケーションサーバーを必要としません。

継続的に使う機能には、データを処理して保存する場所が必要です#

現在のブラウザーセッション終了後も保持する必要がある情報や、ユーザー間で共有する情報を扱う操作もあります。たとえば、次のようなものです。

• 問い合わせを受け取り、保存する。
• ログイン認証情報を確認する。
• 購入を確定する。
• 予約を保存する。
• 在庫を更新する。
• 顧客の注文履歴を表示する。

静的なフロントエンドは、これらの処理を実行するサービスに接続できます。フロントエンドは静的に配信されたままですが、システム全体としては動的な機能を備えています。

認証には、JavaScriptで要素を非表示にする以上の対策が必要です。保護対象の情報へのアクセスは、バックエンドで制御しなければなりません。すべてのブラウザーに機密データを送信し、画面上で隠すだけでは、そのデータは保護されません。

ハイブリッドWebサイトは複数の配信方式を組み合わせます#

オンライン講座を販売する事業者を考えてみましょう。

1. 講座の説明 は、公開されているシラバスが訪問者ごとに変わらないため、事前に生成できます。
2. 空席数 は、最新の受講登録データに基づいて表示できます。
3. 購入手続き には、バックエンドでの検証と決済処理が必要です。
4. 学生用ダッシュボード には、認証後に個人情報が表示されます。

同じWebサイトに、誰でも閲覧できるコンテンツ、最新の運用データ、非公開のアプリケーション機能が共存しています。すべてを一つのレンダリング方式に統一しても、ほとんど意味はありません。

ツールを比較する際に、SSG、SSR、CSRという用語を目にすることがあります。SSGは静的サイト生成、SSRはサーバーサイドレンダリング、CSRはクライアントサイドレンダリングを意味します。これらはコンテンツがページに表示される仕組みを表しており、一つのプロジェクトで複数の方式を使用することもできます。

公開後に一部のページを再生成したり、動的に生成されたレスポンスをキャッシュしたりするシステムもあります。こうした選択肢を評価する際は、コンテンツをどれくらい新鮮な状態に保つ必要があるか、また更新から次の訪問者のリクエストまでの間に何が起きるかを確認しましょう。

静的と動的：実用面でのトレードオフ#

最適な比較は、ウェブサイトでどのような作業を支える必要があるかを起点に始まります。速度は重要ですが、コンテンツの更新、信頼性、データの鮮度、サイトの保守にチームが費やす時間も同様に重要です。

パフォーマンスと読み込み速度#

静的配信では、リクエストごとに初期ドキュメントを生成する必要がありません。そのためサーバーの負荷を軽減でき、公開ページをCDN経由で配信しやすくなります。

ただし、画像の容量が大きすぎたり、JavaScriptを過剰に読み込んだり、不要なフォントや重いサードパーティ製スクリプトを使用したりすれば、静的ページでもパフォーマンスが低下します。HTMLが事前に生成されていても、ページの表示が遅くなったり、インターフェースの応答性が損なわれたりすることはあります。

クエリ、アプリケーションコード、キャッシュが適切に設計されていれば、動的ページでも優れたパフォーマンスを実現できます。公開用のレスポンスは共有キャッシュに保存できる場合が多く、処理の繰り返しを減らせます。

実際の使用感を比較しましょう。

• モバイル回線で、メインコンテンツはどれくらい速く表示されますか？
• 操作中もページの応答性は保たれますか？
• 画像、フォント、埋め込みコンテンツの読み込み中にレイアウトがずれますか？
• APIやデータベースの応答が遅い場合、どうなりますか？

一覧ページや詳細ページなど、代表的なページを測定しましょう。ホームページが速いからといって、サイト全体のパフォーマンスが良いとは限りません。

公開とコンテンツの鮮度#

静的コンテンツは通常、ファイルの再生成や再公開によって更新されます。これは、開発者が手動でHTMLを編集するのではなく、CMSの更新をきっかけに自動で行われる場合があります。

動的ページでは最新情報をリクエストできますが、キャッシュによって訪問者に変更が反映されるまで時間がかかることもあります。「動的」だからといって、必ずしも「即時」を意味するわけではありません。

情報が古いままであることの影響に応じて、更新方式を選びましょう。

• チームメンバーの紹介は、通常、公開まで時間がかかっても問題ありません。
• 講座の説明は、公開日時を設定する必要がある場合があります。
• 在庫数には、明確な更新ルールが必要です。
• 予約または購入を確定する際は、取引処理時に空き状況を検証する必要があります。

公開画面での表示と、取引の正確性は別の責務です。空き状況が最新に見える表示であっても、予約を確定する前のバックエンド確認に代わるものではありません。

編集、テンプレート、拡張性#

どちらの方式でも、構造化コンテンツや再利用可能なレイアウトに対応できます。静的サイトジェネレーターはデータから何千ものページを生成でき、動的アプリケーションは1つのテンプレートを使って多数のデータを表示できます。

編集者にとっては、アーキテクチャの呼び方より、次のような実務的な問いのほうが役立つことがよくあります。

• コードを変更せずにコンテンツを更新できますか？
• 公開前に変更をプレビューできますか？
• コンテンツのカテゴリ全体でレイアウトを再利用できますか？
• 公開日時を設定し、権限を管理できますか？
• ページごとに編集することなく、共通コンポーネントを修正できますか？

大規模になると、ボトルネックは構成によって異なります。静的プロジェクトでは、ビルド対象の選別やアセット処理の効率化が必要になる場合があります。動的プロジェクトでは、クエリの最適化、キャッシュ、十分な実行環境の容量が必要になることがあります。

セキュリティとメンテナンス#

静的ファイルで構成された公開サイトでは、訪問者に対して稼働中のCMSやページ生成用バックエンドを公開せずに済みます。これにより、実行時に発生する一部のリスクを低減できます。

ただし、システム全体が攻撃を受けなくなるわけではありません。ホスティングアカウント、ビルドシステム、依存関係、埋め込みスクリプト、フォーム、連携サービスも引き続き保護する必要があります。

動的な機能を導入すると、アクセス制御や保存情報に関する責任が増えます。特に、誰がレコードを読み取り、作成、変更、削除できるのかを確認してください。認証はユーザーを識別し、認可はそのユーザーに許可される操作を決定します。

キャッシュにも注意が必要です。公開コンテンツは複数のリクエストで共有できることが多い一方、設定ミスによってプライベートなアカウントデータが別の訪問者に提供されないようにしてください。

開発費用と継続費用#

静的コンテンツの配信は、特に公開情報ページでは低コストで済むことがあります。それでも、総予算にはCMS、フォーム、検索、分析、ビルド用インフラ、継続的な開発の費用が含まれる場合があります。

動的なウェブサイトにはアプリケーションとデータの要件が加わりますが、マネージドプラットフォームを利用すれば運用作業を減らせます。適切に管理されたコンテンツシステムは、編集作業にかかる時間を大幅に節約できることもあります。

ワークフロー全体にかかる費用を見積もりましょう。

• 初期実装とコンテンツの移行。
• ホスティング、データベース、サードパーティのサブスクリプション。
• コンテンツの制作と定期的な更新。
• 保守、監視、サポート。
• 将来的な機能やホスティングの変更。

コンテンツを変更するたびに手作業で開発する必要があるなら、最も安価なホスティングプランが必ずしも最も低コストな選択肢とは限りません。

SEO、AIによる概要、LLMでの可視性#

ウェブサイトのアーキテクチャは、検索システムがコンテンツをどれだけ容易に発見し、アクセスできるかに影響します。実装によって有用な情報がブラウザー上での処理、リンク切れ、アクセス制限のあるページの背後に隠されると、大きな影響が生じる可能性があります。

ただし、アーキテクチャだけで検索順位やAIの回答への掲載、ブランドへの言及が決まるわけではありません。静的ページもサーバーでレンダリングされる動的ページも、アクセス可能な公開コンテンツを提供できます。

返されるHTMLに主要なコンテンツを含める#

公開記事、カテゴリページ、サービスページでは、ブラウザーでJavaScriptが実行される前にサーバーが返す内容を確認しましょう。そこに実際の見出し、説明、リンクが含まれていますか。それとも、空のアプリケーションシェルだけでしょうか？

事前レンダリングされたページもサーバーサイドでレンダリングされたページも、意味のあるHTMLを返すことができます。生成されるタイミングは異なりますが、どちらの場合もクローラーに有用なコンテンツを届けられます。

GoogleはJavaScriptをレンダリングできますが、その処理には追加の段階があり、実装上の考慮事項も伴います。ほかのボットはJavaScriptを実行できない場合があります。Googleの JavaScript SEOに関するガイダンス では、ユーザーとクローラーのためにサーバーサイドレンダリングや事前レンダリングを検討することが推奨されています。

実用的な指針は、訪問者が操作ボタンをクリックしたり、ブラウザー上だけで完結する手順をすべて行ったりしなくても、重要な公開コンテンツを利用できるようにすることです。その後、インタラクティブな機能を、その利用しやすい基盤の上に追加できます。

AIによる概要で重視されるのは、検索結果への掲載資格であり、静的サイトであることではありません#

Googleの AI機能に関するガイダンス によると、AIによる概要やAIモードの参考リンクとして選ばれるには、ページがインデックスに登録され、スニペット付きで表示される資格を満たしている必要があります。ただし、資格を満たしていても選ばれるとは限りません。

ファイルが静的に生成されているというだけで、ウェブサイトが特別に優遇されることはありません。明確でアクセスしやすいコンテンツを提供する動的ページも、掲載資格を満たす可能性があります。

また、これらの機能のために、Googleが特別なAI用スキーマや追加のAIテキストファイルを要求することもありません。新しいファイル形式を最適化策と見なす前に、有用なコンテンツ、クロール可能性、内部リンク、適切な検索コントロールに注力しましょう。

LLMによる引用とブランドへの言及は、異なる結果です#

検索中にAIアシスタントがページを取得することと、言語モデルが過去に学習した情報をもとにブランドに言及することは異なります。製品によって、検索インデックス、リアルタイムでの情報取得、モデルの知識がさまざまな形で組み合わされています。

ページをアクセス可能にすることで、情報検索システムがそのページを利用できるようになります。ただし、そのページが根拠として選ばれること、引用が表示されること、特定の回答でブランド名が言及されることが保証されるわけではありません。

編集計画では、技術的なアクセス可能性とコンテンツの有用性を別々に確認しましょう。

• アクセス可能性： システムが関連情報にアクセスし、読み取れるか？
• 有用性： ページに、質問に対する具体的で信頼できる回答が含まれているか？

表示方法を変えても、サービス説明の曖昧さ、製品情報の不足、ページ間の矛盾は補えません。

公開情報は見つけやすく、非公開情報は保護する#

非公開のダッシュボードやアカウント記録は、保護された状態に保つべきです。事業の認知度を高めるために、これらをインデックス可能にする必要はありません。

その代わりに、製品、サービス、価格設定の方針、関連する機能を説明する明確な公開ページを作成しましょう。アプリケーションとは独立して見つけられるよう、ページに固定URLを設定し、ナビゲーションからリンクしてください。

コースプラットフォームの場合、公開されているコース説明で、シラバス、レベル、受講要件を説明できます。学生の進捗状況や支払い履歴は、認証の背後で保護します。

実践的なアーキテクチャのチェックリスト#

プラットフォームやレンダリング方法を変更する前に：

• 代表的な公開ページで返されるHTMLを確認します。
• レンダリング後のページと比較し、主要なコンテンツが欠落していないか確認します。
• 重要なページにそれぞれアクセス可能なURLがあることを確認します。
• 公開ページのナビゲーションには、通常のクロール可能なリンクを使用します。
• robotsのルール、インデックス登録の指示、canonical URL、レスポンスのステータスコードを確認します。
• コンテンツを変更し、公開後の出力に実際にいつ反映されるかを確認します。
• アーキテクチャが成果を保証すると考えず、インデックス登録とページエクスペリエンスを監視します。

実装の詳細については、 静的ウェブサイトのSEOに関するガイドをご覧ください。動的ページにも同じ基本要件が当てはまります。発見されたいコンテンツは、アクセス可能で、理解しやすく、有用である必要があります。

ウェブサイトビルダー、CMS、フレームワークの例#

ツールは、静的または動的のどちらか一方に明確に分類できるとは限りません。ファイルを生成するもの、アプリケーションを実行するもの、別のフロントエンドにコンテンツを提供するものがあります。

以下の表では、それぞれの役割を区別しています。ウェブサイトビルダー、公開システム、静的サイトジェネレーター、フレームワークを取り上げ、出力内容と実装に必要な作業量の両方を比較できます。

ヘッドレスCMSだけで、公開Webサイトのアーキテクチャが決まるわけではありません。同じコンテンツAPIを、静的サイトのビルドにもサーバーサイドレンダリングのアプリケーションにも利用できます。

同様に、CMSがあるからといって、訪問のたびにデータベースへの新たな問い合わせが発生するわけではありません。コンテンツシステムと訪問者の間に、生成済みのページやキャッシュされたレスポンスが介在する場合があります。

事前に生成した出力がプロジェクトに適している場合は、こちらの比較記事をご覧ください。 人気の静的サイトジェネレーター では、ほかの選択肢を紹介しています。ビジュアル編集を重視する場合は、技術の名称だけで選ぶのではなく、出力形式とあわせて公開ワークフローも評価しましょう。

TeleportHQが静的・動的Webサイトに対応する方法#

公開情報を表示するプロジェクトだけでなく、データを読み込んでアプリケーション機能を実行するプロジェクトにも対応しています。ビジュアルインターフェースを構築したうえで、プロジェクトに必要なデータ機能やサーバー機能を選択できます。

この違いは、ホスティング、コードのエクスポート、今後の変更を計画するうえで重要です。また、当社の製品カテゴリーにはそれぞれ明確な意味があります。TeleportHQ Websiteはデータを接続して表示できますが、それだけで自動的にTeleportHQ Web Appになるわけではありません。

ブラウザー上で操作できる静的ページを作成する#

当社の 静的ウェブサイトビルダー を使えば、再利用可能なレイアウトやコンポーネントを活用して、公開ページを視覚的に作成できます。静的な出力にもブラウザー上での操作を含められます。アコーディオンを開いたりタブを切り替えたりするだけなら、本質的にサーバー上のアプリケーション機能は必要ありません。

たとえば、サービスサイトに、操作可能なナビゲーションメニューや料金の説明、展開式の回答を設けながら、共通の公開コンテンツを掲載できます。操作できるというだけで、そのページがデータベース駆動型のアプリケーションになるわけではありません。

動作の一部は、選択するエクスポート形式によって異なります。当社の コンポーネントの状態に関するガイド では、クリックで切り替わるシンプルな状態の仕組みと、ダウンロードしたHTMLの制限について説明しています。

お好みのデータベースまたは外部APIを接続する#

当社の データソース連携機能 を使うと、既存の情報をプロジェクトに取り込めます。対応している選択肢には、PostgreSQL、MySQL、MariaDB、MongoDB、Firestore、Supabaseなどのデータベースサービスがあります。

対応する接続方法を使って、 データベースを接続 できます。適切なネイティブコネクターがないシステムでは、サービスが必要なデータとアクセス手段を提供していることを条件に、 JSONを返すREST API を別の方法として利用できます。

これにより、すべてのデータベースエンジンにネイティブ連携があると誤解させることなく、お好みのデータベースを柔軟に利用できます。接続要件や機能はデータソースによって異なります。

編集コンテンツについては、当社の ヘッドレスCMS連携 により、フロントエンドを既存のコンテンツシステムに接続できます。Strapi、Contentful、WordPress、caisy.io、FlotiqとのCMS接続に対応しています。接続手順については、 CMS設定ガイド をご覧ください。

TeleportHQが提供するデータベースを使う#

まだデータベースをお持ちでない場合は、プロジェクト用のホスト型PostgreSQLデータベースをこちらで用意できます。別途データベースサーバーを手配することなく、エディターからテーブルを作成し、レコードを管理できます。

「 組み込みのデータベース設定 」を利用すると、商品や会員などの構造化された情報を保存できます。公開済みのページは、コンテンツを変更するたびに再公開しなくても、更新されたレコードを読み込めます。

このデータベースはTeleportHQのホスティングで動作します。ダウンロードしたコードを別のホストに移しても、引き続き利用することはできません。独自のホスティングを予定している場合は、ホスト型のオプションを前提に構築する前に、外部データベースを選び、プロジェクトのその他のエクスポート要件も確認してください。

利用可能な容量やトライアルの有無はプランによって異なります。最新の データベースの制限 は別途ご確認ください。

データを一覧ページや詳細ページに活用する#

データソースの接続は最初のステップにすぎません。次に、データの値をインターフェース内の要素に紐付けます。

たとえば、講座データベースから次の情報を取得できます。

• 各講座カードのタイトルとカバー画像。
• 受講可能な講座を繰り返し表示する一覧。
• 個別のコースの詳細ページ。
• 表形式に整理された行。

当社の データバインディングガイド では、フィールドの接続方法や、レコードごとにデザインを繰り返す方法を説明しています。これにより、表示レイアウトとは別に、基となる情報を管理できます。

サーバーサイドレンダリング、Webアプリ、エクスポートについて#

最初のデータソースを追加すると、データ駆動型ページはサーバーサイドレンダリングを使用し、コードのエクスポート先はNext.jsに限定されます。それだけで、別カテゴリのWebアプリが有効になるわけではありません。

ユーザー認証、ワークフロー、オンラインストア、組み込みブログなどの機能を使うと、Webアプリ機能が有効になります。TeleportHQのWebアプリは当社のホスティング上で動作し、コードとしてダウンロードできません。また、最初の7日間の利用期間終了後は、Webアプリ枠が必要です。

これらの機能を計画する際は、 TeleportHQのプロジェクトがWebアプリとなる条件 をご確認ください。ブラウザー上のインタラクションや連携コンテンツと、プロジェクトのデプロイ要件を変えるサーバー側の処理を区別できます。

どちらの方法を選ぶべきですか？#

静的サイトと動的サイトのどちらを選ぶか決める前に、まず明確にすべきなのは、今後作成するサイトの目的です。

訪問者が何をする必要があるかを考え、各要素の動作方法を決めましょう。ページ数や見た目の複雑さよりも、コンテンツの鮮度、アクセス要件、訪問者が保存または変更する必要のある内容を起点に考えるほうが効果的です。

事前に準備できる公開コンテンツには、静的配信を選びましょう#

次のようなコンテンツに適しています。

• 企業やサービスのページ。
• キャンペーンのランディングページ。
• ポートフォリオや導入事例。
• ドキュメントや学習用の記事。
• 訪問者ごとに生成する必要のないカタログの説明文。

チームに合った編集ワークフローを選びましょう。CMSを活用した構築なら定期的な公開に対応でき、 静的ウェブサイトのテンプレート は、一般的な公開ページのレイアウトの土台として活用できます。

必要な機能に応じて動的な機能を追加する#

次のようなニーズには、実行時サービスを利用しましょう。

• 顧客アカウントを安全に保護する。
• 個別のダッシュボード。
• 注文、予約、支払い。
• 最新の空き状況や、頻繁に変わる運用データ。
• 訪問者が作成または更新する共有レコード。

どの情報をすぐに表示する必要があり、どの情報をキャッシュできるかを判断しましょう。また、権限管理、バックアップ、エラー対応、継続的なメンテナンスの責任者も明確にしてください。

サイトのニーズに応じて手法を組み合わせる#

ビジネスサイトでは、すべてのページで一つのレンダリング方法を選ぶ必要はありません。一般向けのサービスページは事前に生成し、カタログにはサーバーサイドレンダリングを使い、アカウントページでは認証後に非公開データを読み込むことができます。

プラットフォームを決める前に、次の5つの質問に答えましょう。

1. すべての訪問者に同じ内容を表示できるのはどのコンテンツですか？
2. 操作の時点で最新である必要がある情報は何ですか？
3. 認証や永続的なデータ保存が必要な操作は何ですか？
4. 誰がどのくらいの頻度でサイトを更新しますか？
5. このプロジェクトでは、将来的にどのようなホスティングやエクスポートの柔軟性が必要ですか？

これらの回答を判断材料にすれば、静的サイトは基本的なもの、動的サイトは優れているものと決めつけるよりも、信頼性の高い選択ができます。