保護者がピックアップ時に携帯電話で学区ウェブサイトを開きます。ヒーロー画像が固まります。ナビゲーションメニューがレンダリングされません。彼らはGoogleの中央値である放棄閾値の3.1秒後にSafariを閉じます。先月、50のK-12学区ウェブサイトを監査しました。76%は2014年から2017年の間にインストールされたWordPress Multisiteで動作しています。モバイルLighthouseスコアの平均値：41。平均月間ホスティングコスト：1,890ドル。ほとんどの機関が同じフッターと1つのスタッフディレクトリを共有する7つのサブサイトを更新するために、月額11,250ドルの代理店に支払っています。このアーキテクチャはオバマ政権以来変わっていませんが、親の期待は、単一ページのReactアプリを使用して食料品を注文した日に変わりました。Next.js多テナントアーキテクチャは、スタック全体を1回限りの30,000ドルで置き換え、ホスティング費用を月額180ドルに削減します。構造は次のとおりです。

メトリック 結果
WordPress Multisiteを実行中 38 (76%)
モバイルLighthouseの平均スコア 41
サイトあたりのプラグイン平均数 23
検索が機能している 12 (24%)
モバイル最適化済み 18 (36%)
ADA準拠 7 (14%)
過去6ヶ月で更新済み 22 (44%)

これらは500万の家族がバススケジュール、学校の休校情報、ランチメニュー、教師の連絡先情報を見つけるために使用するウェブサイトです。もっと良いものに値します。

私は過去10年間ウェブプラットフォームを構築していますが、ユーザーが必要とするものと実際に得るものの間に、このほど大きな差がある分野は見たことがありません。学区ウェブサイトは電子商取引ストアやSaaSマーケティングページではありません。これらは重要な公共インフラです。親が午前6時に携帯電話で降雪の日の告知を見つけることができない場合、それは本当の失敗であり、現実的な結果があります。スペイン語を話す家族が無料ランチ申請書を見つけることができない場合、子どもたちは空腹になります。

この記事では、K-12ウェブサイトがなぜ停滞しているのか、最新の置換アーキテクチャがどのように見えるのか、およびスイッチを明白な選択肢にする実際のコスト計算について詳しく説明します。

目次

School District Websites Still on WordPress Multisite: The $30K Fix

K-12ウェブサイトを殺している4つの問題

学区ウェブサイトは1つの理由で失敗しません。4つの問題が互いに複合し、誰もそれらを解きほぐす帯域幅を持たないために失敗します。

ITスタッフの危機

あなたを驚かせるべき数字がありますが、教育に携わっている人を驚かせることはないでしょう：平均的な学区IT部門は2～3人です。これらの2～3人は、20～50のスクールウェブサイト、メール、学生情報システム（SIS）、学習管理システム（LMS）、ネットワークインフラストラクチャ、および約10,000のデバイス（Chromebook、教師のノートパソコン、インタラクティブホワイトボード、プリンター）を管理しています。

ウェブサイト管理の帯域幅はありません。ゼロです。

去年テキサス州の中規模学区のIT部長と話しました。彼は、彼のチームが8ヶ月間WordPress Multisiteのインストールに触れていなかったと言いました。彼らが気にしなかったからではなく、Chromebook修理、Google Workspace移行、そして3週間を費やしたランサムウェアの脅威に溺れていたからです。

結果？サイトは数ヶ月間更新されないままです。リンク切れが蓄積されます。古い情報はライブのままです。2年前に退職した副校長は主要な連絡先としてまだリストされています。ランチメニューは2023年9月を表示しています。登録フォームは404にリンクしています。

これは怠惰ではありません。リソース配分の危機です。ネットワークを稼働させることとウェブサイトを更新することの間で選択を強制する場合、ウェブサイトは毎回負けます。

教師のコンテンツ更新の内訳

教師はクラスページを更新したいと思っています。彼らは本当にそうしたいのです。彼らはシラバスを投稿し、宿題の課題を共有し、科学博覧会についての告知を貼りたいと思っています。

しかし、WordPressは技術以外のスタッフには複雑すぎます。それを見下すつもりではありませんが、WordPress管理インターフェイスは、ウェブサイトを構築する人々のためではなく、3年生の数学を教える人々のために設計されました。Gutenbergエディタ、プラグインの競合、メディアライブラリ、分類法システム、改訂履歴...それはたくさんです。

そこで、実際に起こることがあります：

  1. 教師がページを更新しようとします
  2. 何かが壊れます（間違ったテンプレート、フォーマットの問題、誤ってウィジェットを削除）
  3. 教師がITにメールします
  4. ITには3週間のバックログがあります
  5. 教師は諦めます
  6. 教師はGoogle Classroomに全てを投稿します

今、公式の学校ウェブサイトは毎日の学校コミュニケーションに無関係です。保護者は最終的に3～5の異なるアプリをジャグリングします：学校ウェブサイト（まだそこにある材料の場合）、Google Classroom（実際の課題）、ParentSquare（告知）、Remind（迅速なメッセージ）、そしておそらく良い尺度のためのFacebookグループ。

そして彼らはまだバススケジュールを見つけることができません。

この断片化は家族にとってうんざりしています。技術に精通していない保護者や学区内の複数の学校に子供を持つ保護者にとっては特に厳しいです。学校ウェブサイトは真実の単一の情報源であるべきです。代わりに、誰も見ていない唯一の場所です。

ADA準拠は刻々と迫る訴訟

このことは、スーパーインテンデント（学区長）を夜に起こさせるべきです。

学区は、アクセス不可能なウェブサイトのためのADA訴訟の標的がますます増えています。そして解決は安くありません。単一のADA訴訟は、学区に30,000ドルから100,000ドル以上の法的費用と改善コストがかかる可能性があります。2024年に、DOJはWCAG 2.1レベルAAの準拠を必要とする州および地方自治体のウェブサイト（学区を含む）の規則を最終決定し、より大きなエンティティの場合は2026年4月から始まる期限があります。

今、50のスクールサイトを持つWordPress Multisiteについて考えてください。これは50の潜在的に準拠していないサイトです。各サイトはさまざまな人によって維持されています（またはだれでもありません）。各サイトには異なるプラグインセット、異なるテンプレート構成、異なる画像代替テキストの習慣（または欠如）、および見出しの階層への異なるアプローチがあります。

50のサイトを個別に監査しますか？50のサイトを個別に改善しますか？それは何百時間もの仕事です。そして、誰かが適切なタグ付けのないPDFを追加したり、代替テキストのない画像を追加したりするたびに、再度実行する必要があります。これにより、その学校のページは再びコンプライアンスから外れます。

マルチテナントアーキテクチャが提供するものはここにあります：1つの準拠したコードベースは、50のスクール全てが自動的に準拠していることを意味します。コンポーネントはアクセシビリティを強制します。見出しの構造はデフォルトで正確です。画像のアップロードには代替テキストが必要です。PDFはタグ付けされていない場合は、フラグが立てられます。アクセシビリティの問題を一度修正すると、どこでも修正されます。

翻訳の失敗は公平性の危機

多様な学区では、30～50%の家族が家庭でのスペイン語以外の言語を話します。スペイン語、ベトナム語、アラビア語、中国語、ハイチ・クレオール語 - コミュニティ次第ですが、数字は重要です。

そして彼らの学校ウェブサイト？英語のみです。

これらの家族は登録情報を見つけることができません。彼らは無料および削減されたランチアプリケーションプロセスをナビゲートすることができません。彼らは交通ルートを把握することができません。彼らはイベント、期限、および機会を逃します。

これはいい得られるものではありません。公民権法のタイトルVIは、連邦資金を受け取る学区が限定英語能力（LEP）親と効果的にコミュニケーションすることを必要とします。英語のみのウェブサイトは、公平性の失敗の上に準拠リスクがあります。

これを修正するコストを見てみましょう：

ソリューション 年間コスト
WordPress上のWPML（50サイト×199ドル/年） 9,950ドル/年+継続的な翻訳コスト
Finalsite 本当の多言語サポートなし
Google翻訳ウィジェット 不正確、レイアウトを破壊、ADAの悪夢
Next.js+next-intl+一括翻訳 5言語で約110ドルの1回限り

その110ドルの数字は誤植ではありません。next-intlを使用して正しく国際化されたNext.jsアプリケーションでは、すべてのコンテンツ文字列を抽出し、翻訳APIを通じて実行します（言語あたり約22ドル）、ネイティブスピーカーで確認し、完了します。コミュニティが必要に応じて言語を追加してください。ルーティングは自動的に/es/schools/lincoln-elementaryを処理します。

これらの学区の半分が使用しているGoogle翻訳ウィジェット？それは文法的に破壊された翻訳を生成し、ページレイアウトを破壊し、アクセシビリティの問題を作成し、重要なことに、画像またはPDFの内容を翻訳しません。それは家族への包帯です：「私たちはこれを適切に行うのに十分な在宅勤務をしていません。」

WordPress Multisiteが間違った賭けだった理由

公平に言えば、WordPress Multisiteは2014年～2016年に不当な選択ではありませんでした。それは無料（ish）でした。複数のサイトを1つのインストールから技術的に実行できました。プラグインの巨大なエコシステムがありました。そして学区はWordPressの開発者を見つけることができました。

しかし、次の10年間に起こったことは次のとおりです：

  • プラグインスプロール：各サイトはコアが実行できなかった機能のプラグインを蓄積しました。SEO、フォーム、カレンダー、アクセシビリティオーバーレイ（実は機能しません）、翻訳、キャッシング、セキュリティ。私たちの監査では、サイトあたり平均23個のプラグインが見つかりました。それは23の潜在的なセキュリティ脆弱性、23の競合が生じる可能性のあるもの、23の更新が必要なものです。
  • PHPバージョンの債務：これらのインストールの多くは、サポート終了の配下のPHPバージョンで動作しています。PHPを更新するとプラグインが壊れるリスクがあります。PHPを更新しないことはセキュリティ上の危険です。
  • Gutenbergの混乱：ブロックエディタへのWordPressのシフトは、古典的なエディタをようやく学んだばかりの教師のワークフローを破りました。多くの学区は依然としてClassic Editorプラグインを実行しており、それ自体は老化しています。
  • パフォーマンスの死のスパイラル：WordPressはMySQLデータベースからサーバーレンダリングされたHTMLを提供してすべてのリクエストのためにそれを提供します。WooCommerce（はい、いくつかの学校はマーチストアを実行します）、BuddyPress、または重いプラグインを追加して、3～5秒の読み込み時間を探しています。学校の駐車場のモバイル接続を介して？それを忘れます。
  • セキュリティ表面積：WordPressはウェブの43%を駆動し、自動化された攻撃の#1ターゲットになります。マルチサイト全体で単一の侵害されたプラグイン？すべてのスクールサイトが公開されています。

WordPress Multisiteは10年前は実用的な選択肢でした。今はテクニカルデビットです。

ベンダートラップ：Finalsite、Blackboard、SchoolPointe

ほとんどの学区が検討する代替手段は、K-12ウェブサイトベンダーです。Finalsiteが大きな名前です。Blackboard（現在のAnthology）、SchoolPointe、Apptegy（Thrillshare）などもあります。

これらのプラットフォームはいくつかの問題を解決します。彼らはホスティングを処理します。彼らはテンプレートを提供します。彼らはアクセシビリティ機能があります。しかし彼らは深刻なトレードオフを伴います：

コスト：45の学校を持つ学区のための完全版サイトは135,000ドルから360,000ドル/年です。これは1回限りのコストではありません。繰り返されます。毎年。永遠に。あなたが去ることにした場合、あなたはゼロから始めています-コンテンツと構造の簡単なエクスポートはありません。

柔軟性：あなたは彼らが与えたものを得ます。SISとのカスタム統合が必要ですか？それは専門サービスの契約になります。カレンダーの動作を変更したいですか？フィーチャーリクエストを送信して待機します。学区に、カスタムルーティングを必要とするユニークなバイリンガルプログラムがありますか？申し訳ありませんが、それはテンプレートにはありません。

パフォーマンス：いくつかのFinalsite主催の学区ウェブサイトでLighthouseの監査を実行しました。スコアはモバイル上の35から62の範囲です。これらは本質的にマーケティングウェブサイトです-サーバーレンダリングされたページは重いJavaScriptバンドル、サードパーティの追跡スクリプト、最適化されていない画像です。彼らは速くありません。

ロックイン：これが大きなものです。あなたのコンテンツは彼らのCMSに存在しています。あなたのURLはそれらの方法で構造化されています。あなたのデータモデルは彼らのスキーマに従います。3年後、スイッチングコストは膨大です。彼らはこれを知っています。それがビジネスモデルです。

これらのベンダーが邪悪だと言っているわけではありません。彼らはゼロの技術的能力を持つ学区に本当のサービスを提供します。しかし、あなたが所有するインフラストラクチャに投資するオプションを持っている場合、数学は圧倒的にその方向を指しています。

School District Websites Still on WordPress Multisite: The $30K Fix - architecture

修正：マルチテナントNext.jsアーキテクチャ

ここで私たちが実際に構築するものです。1つのアプリケーション。一度デプロイされます。学区のすべての学校を提供します。

/                          → 学区ホームページ
/schools/[slug]            → 学校ホームページ（45の学校）
/schools/[slug]/calendar   → 学校固有のイベント
/schools/[slug]/staff      → スタッフディレクトリ
/schools/[slug]/staff/[id] → 教師のクラスページ
/[lang]/schools/[slug]     → 翻訳版（es、vi、ar、zh、ht）
/portal                    → 保護者ポータル（認証が必要）
/admin                     → 教師/スタッフコンテンツポータル

45の学校=1つのコードベースからの45のプログラマティックルート。1つのデプロイメント。バグを修正する1つの場所。アクセシビリティを強制する1つの場所。機能を追加する1つの場所。

テックスタック

フレームワーク：     Next.js 15（App Router）
CMS：           ヘッドレス（SanityまたはPayload CMS）
認証：          Supabase Auth+行レベルセキュリティ
I18n：          next-intl
ホスティング：       Vercel（またはCloudflare Pages）
検索：          AlgoliaまたはTypesense
アクセシビリティ：    axe-coreがCI/CDパイプラインに含まれています

教師ポータル

これは毎日の操作に関して全てを変える部分です。教師は彼らの学区Googleアカウント（Supabase Authを介したSSO）でログインします。彼らは自分のクラスページを見ます。彼らはできます：

  • シラバスを更新（リッチテキストエディタ、WordPress Gutenbergではなく）
  • ファイル添付付きの宿題の課題を投稿
  • 告知を追加
  • オフィスアワーと連絡先情報を更新

それだけです。サイドバーなし、ウィジェットなし、プラグイン設定なし、「本当に更新しますか？」確認ページなし。4つのことをうまくやる焦点を絞ったインターフェイス。

Supabase内の行レベルセキュリティ（RLS）は、教師が独自のコンテンツのみを編集できることを意味します。管理上の監督は不要です。ITチケットはありません。

-- Supabase RLSポリシー：教師は独自のコンテンツのみを更新できます
CREATE POLICY "Teachers can update own content"
  ON class_pages
  FOR UPDATE
  USING (auth.uid() = teacher_id);

保護者ポータル

保護者は認証し、登録された子どもに基づいてカスタマイズされたビューを表示します。彼らの子どものためのバスルート。彼らの学校のランチメニュー。関連する学校にフィルタリングされた今後のイベント。彼らの子どもの現在の教師の教師の連絡先情報。

45のスクールサイト全体を掘り下げて、3つの異なる学校の3人の子どもについての情報を見つける必要はなくなりました。

デフォルトによるアクセシビリティ

コンポーネントライブラリはWCAG AAを強制します。すべての<Image>コンポーネントには代替テキストが必要です。見出しの階層は、ページテンプレートによって強制されます。色のコントラストはビルド時に検証されます。フォーカス管理はナビゲーションコンポーネントで処理されます。

CI/CDパイプラインでaxe-coreを実行します。すべてのプルリクエストはアクセシビリティ監査を取得します。失敗した場合、デプロイされません。期間。

これは200人の教師がコンテンツを追加するときに重要です。200人をアクセシビリティについて訓練することはできません。非準拠を構造的に不可能にするシステムを構築できます。

パフォーマンス

静的生成を使用したNext.jsは、スクールページがビルド時に事前レンダリングされ、CDNから提供されることを意味します。学校の駐車場にいる親が3G接続で1秒以内にページを取得します。Lighthouseスコアは一貫して90+に達します。

私たちは41のLighthouseスコア（監査の平均のWordPress Multisite）と95のスコアの違いについて話しています。それは段階的な改善ではありません。それは異なる経験です。

これを明白にする数学

45の学校を持つ学区の3年間の総所有コストをしましょう：

ソリューション 1年目 2年目 3年目 3年合計
Finalsite 135,000ドル～360,000ドル 135,000ドル～360,000ドル 135,000ドル～360,000ドル 405,000ドル～1,080,000ドル
WordPress Multisite（既存を維持） 30,000ドル～50,000ドル 30,000ドル～50,000ドル 30,000ドル～50,000ドル 90,000ドル～150,000ドル
Next.js マルチテナント（ビルド+ホスト） 60,000ドル～100,000ドル+540ドル 540ドル 540ドル 61,000ドル～101,000ドル

Next.jsのホスティングコストは、Vercel ProでBrowser月45ドル、またはCloudflare Pagesではさらに少なくなっています。それは45の学校を提供するプラットフォームの年間540ドルです。WordPressのホスティングだけは通常、管理されたマルチサイトのインストールに月500ドルから1,500ドルです。

Finalsite対での損益分岐点：3～6ヶ月。進行中のWordPress保守対での損益分岐点：1年目。

そしてここで、WordPressコスト列がキャプチャしていないもの：ITスタッフの時間。ウェブサイトのファイアファイティングに週10～15時間を費やしている2～3人のIT職員？それは、字面通り他の何かに行くことができた30,000ドル～50,000ドルの給与配分です。Chromebook管理。サイバーセキュリティ。実は一晩中寝続けます。

60,000ドル～100,000ドルのNext.jsプラットフォームの構築コストは、1回限りの投資です。あなたはそれを所有しています。年間ライセンスなし。学校あたりの費用なし。ベンダーロックインなし。46番目の学校を追加しますか？それはCMSの新しいエントリであり、販売電話ではありません。

実際の移行の様子

45のスクールウェブサイトの移行が簡単だと主張するつもりはありません。それはプロジェクトです。分割方法は次のとおりです：

1～3週目：ディスカバリーとコンテンツ監査

  • 45のサイト全体にある既存のコンテンツをインベントリする
  • 実際に現在のもの対放棄されたものを特定する
  • 情報アーキテクチャをマッピングする
  • ITスタッフ、教師、保護者に関する痛みポイントについてインタビュー

4～8週目：プラットフォームビルド

  • ヘッドレスCMS統合を備えたマルチテナントNext.jsアプリケーション
  • Supabase Authを備えた教師ポータル
  • ベイクインアクセシビリティを備えたコンポーネントライブラリ
  • next-intlでi18nセットアップ
  • 自動化されたアクセシビリティテストを備えたCI/CDパイプライン

9～12週目：コンテンツ移行とトレーニング

  • 自動化されたコンテンツ移行スクリプト（WordPress REST API→ヘッドレスCMS）
  • 手動コンテンツレビューとクリーンアップ
  • 教師トレーニング（30分のセッション-それより長くかかる場合、UXはうまくいく必要があります）
  • 保護者ポータルソフトローンチ

13～14週目：ローンチ

  • DNSカットオーバー
  • リダイレクトマッピング（すべての古いURLは301を取得）
  • 監視とサポート

総タイムライン：14週。それはセメスターです。冬休み中に、トラフィックが最も少ないときにローンチできます。

重要な洞察：45のウェブサイトを再構築していません。45の学校にサービスを提供する1つのウェブサイトを構築しています。それは複雑さの桁削減です。

学区がこの種の移行を探索している場合、私たちはこの仕事をしたことがあります。連絡を取ってください。学区のサイズとニーズについて詳細を歩くことができます。また、このようなプロジェクトの概算範囲については料金ページをチェックすることもできます。

FAQ

学区ウェブサイトの再設計にはいくらかかりますか？

アプローチによって異なります。Finalsiteのようなベンダープラットフォームは、45の学校の学区で年間135,000ドル～360,000ドルで実行されます。既存のWordPress Multisiteを維持するには、ITの時間、ホスティング、開発サポートで年間30,000ドル～50,000ドルかかります。カスタムマルチテナントNext.jsビルドは、1回限りの投資として60,000ドル～100,000ドルで実行され、ホスティングに約540ドル/年です。3年間、カスタムビルドは広いマージンで最も安いオプションです-そして、あなたはプラットフォームを所有しています。

WordPress Multisiteは学区に適していますか？

2014～2016年に合理的な選択でしたが、負債となっています。プラグインの拡散、セキュリティ表面積、モバイルパフォーマンスの低下、50のサイト全体のアクセシビリティの強制不可能は、最新のK-12要件に対して不適切な適合を作ります。ネットワーク内の各サイトは異なる方向に漂流することができ、2～3のITスタッフがそれ以外のすべてを管理しているため、誰もそれを維持する時間がありません。2016年からWordPress Multisiteを実行している学区は、重大なテクニカルデビットを抱えています。

学区ウェブサイトのADA準拠要件は何ですか？

2024年にDOJは、州および地方自治体のウェブサイト（公開学区を含む）がWCAG 2.1レベルAAの基準を満たすことを必要とする規則を最終決定しました。より大きなエンティティは2026年4月から始まる期限に直面しています。非準拠は30,000ドルから100,000ドル以上の法律費用と改善で解決することができます。学区にとって重要な課題は、準拠が1回限りの修正ではないということです-追加されたすべてのコンテンツは準拠を維持する必要があります。これが、プラットフォーム自体にアクセシビリティ強制をビルドして入れることが唯一の持続可能なアプローチである理由です。

複数の言語を学校のウェブサイトで処理しますか？

Next.jsアプリケーションでnext-intlを使用すると、国際化はルーティング構造に構築されます。各言語には、独自のURLプレフィックス（/es/、/vi/、/ar/）が付きます。これは、Google翻訳ウィジェットよりもSEOとアクセシビリティに優れています。5言語のコンテンツ翻訳は、ネイティブスピーカーレビューで翻訳APIを使用して約110ドルの1回限りで実行されます。これを年間199ドル/サイトのWordPressのWPML（50サイトの場合は9,950ドル/年）と比較します。貯蓄は劇的です。より重要なことに、翻訳は正確で、適切にフォーマットされており、ページレイアウトを破壊しません。

教師はITサポートなしで独自のページを更新できますか？

はい-それが全体のポイントです。教師は彼らの学区Googleアカウントで認証し、彼らのクラスページの簡素化されたエディタを見て、彼らのシラバスを更新し、課題を投稿し、告知を追加し、連絡先情報を更新することができます。行レベルセキュリティは、彼らが自分のコンテンツのみを編集できることを確認します。ITチケットなし、3週間のバックログなし、Google Classroomの代わりにすべてを投稿して諦める必要がなし。編集インターフェイスが30分以上の訓練セッションを必要とする場合、我々はそれをUXの失敗と見なし、それを再設計します。

学区ウェブサイトを移行するのにどのくらい時間がかかりますか？

45の学校の学区の場合、14週間のタイムラインを期待してください：ディスカバリーとコンテンツ監査のための3週、プラットフォームビルドのための5週、コンテンツ移行とトレーニングのための4週、ローンチのための2週。ローンチする最良の時間は、冬休みまたは夏休み中にウェブサイトのトラフィックが最も少ない場合です。コンテンツ移行は、WordPress REST APIを使用してコンテンツを新しいヘッドレスCMSに抽出することで部分的に自動化されていますが、古いコンテンツの多くは古くなっているため、手動のレビューとクリーンアップが必要です。

学区ウェブサイトの場合：Finalsite対カスタムビルド？

Finalsiteは、まったくゼロの技術的能力があり、継続的なライセンス予算がある学区にとって意味があります。継続的なビルドに投資できる学区の場合、カスタムマルチテナントNext.jsプラットフォームは3年間の費用が少なく（61,000ドル～101,000ドルと405,000ドル～1,080,000ドルと比較）、パフォーマンスが向上し（Lighthouse 95+と35～62と比較）、コンテンツとインフラストラクチャの完全な所有を提供し、SIS、LMS、その他の学区システムとのカスタム統合に柔軟性を提供します。トレードオフは、初期ビルドのために開発パートナーが必要であり、継続的な機能開発が必要なことです。

学区ウェブサイトをFinalsiteなどのベンダーを使用している場合、学区はそれを所有しますか？

いいえ。あなたのコンテンツはCMSに存在しており、そのデータモデルに従って構造化されています。彼らのインフラストラクチャでホストされています。あなたが去ることにした場合、あなたは本質的にゼロから始めています。コンテンツ、テンプレート、または構成の簡潔なエクスポートはありません。このロックインは設計によるものです-これがeサービス企業の収益モデルを機能させるのです。Sanityまたはを使用したカスタムビルドではPayload CMSを使用するカスタムビルド内では、すべてのコンテンツ、すべてのコード行、およびすべてのデプロイメント構成を所有します。ホスティングプロバイダを切り替えたり、フロントエンドフレームワークを変更したり、開発を内部に持ち込んだりできます。何も失うことなく。

学区ウェブサイトがモバイルで遅いのはなぜですか？

ほとんどの学区サイトはWordPressを20以上のプラグインで実行しており、それぞれがページ読み込みにJavaScriptとCSSを追加します。サーバーレンダリングされたページは、すべてのリクエストに対してデータベースクエリが必要です。画像は最適化されていないことが多いです。CDNはありません。またはCDNが誤構成されています。共有ホスティング環境を追加し、3～5秒の読み込み時間を探しています。学校の駐車場のモバイル接続では、さらに悪いです。静的に生成されたNext.jsサイトは、事前構築されたHTMLを世界中のエッジサーバーから提供し、通常1秒未満で読み込みます。親が午前6時に携帯電話で降雪の日を確認しているときは重要です。