We audited 50 school district websites last week. Here's what we found:

Metric Result
Running WordPress Multisite 38 (76%)
Average Lighthouse mobile score 41
Average plugins per site 23
Working search 12 (24%)
Mobile-optimized 18 (36%)
ADA compliant 7 (14%)
Updated in last 6 months 22 (44%)

Dit zijn de websites die 5 miljoen families gebruiken om busschema's, schoolsluitingen, lunchmenus en contactgegevens van docenten te vinden. Ze verdienen het beter.

Ik heb het afgelopen decennium webplatformen gebouwd, en ik heb nog nooit een sector gezien waar de kloof tussen wat gebruikers nodig hebben en wat ze krijgen zo groot is. Websites van schooldistricten zijn geen e-commerce winkels of SaaS marketingpagina's. Ze zijn kritieke publieke infrastructuur. Wanneer een ouder de sneeuwdagaankondiging om 6 uur 's ochtends op hun telefoon niet kan vinden, is dat een echt falen met echte gevolgen. Wanneer een Spaanssprekend gezin het gratis lunchprogramma niet kan vinden, gaan kinderen hongerig naar school.

Dit artikel beschrijft precies waarom websites van K-12 scholen vastzitten, hoe een moderne vervangingsarchitectuur eruit ziet, en wat de werkelijke kostenberekening is die de overstap tot een no-brainer maakt.

Inhoudsopgave

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

De vier problemen die K-12 websites doden

Websites van schooldistricten falen niet om één reden. Ze falen omdat vier problemen elkaar versterken, en niemand heeft de capaciteit om ze uit elkaar te halen.

De IT-personeelscrisis

Hier is een getal dat je zou moeten schokken, maar niet zal verbazen voor wie in het onderwijs werkt: het gemiddelde IT-team van een schooldistrict bestaat uit 2-3 personen. Deze 2-3 mensen beheren 20-50 schoolwebsites PLUS e-mail, het student information system (SIS), het learning management system (LMS), de netwerkinfrastructuur, en ongeveer 10.000 apparaten (Chromebooks, laptops voor docenten, interactieve whiteboards, printers).

Er is nul capaciteit voor websitebeheer. Nul.

Ik sprak vorig jaar met een IT-directeur van een middelgroot district in Texas. Hij vertelde me dat zijn team acht maanden lang niets aan de WordPress Multisite-installatie had gedaan. Niet omdat het hun niet interesseerde -- omdat ze verdronken in Chromebook-reparaties, Google Workspace-migraties en een ransomware-incident dat drie weken van ieders leven opslurpte.

Het resultaat? Sites blijven maanden ongewijzigd. Gebroken links stapelen zich op. Verouderde informatie blijft live. De adjunct-directeur die twee jaar geleden met pensioen ging staat nog steeds als het belangrijkste contactpunt vermeld. Het lunchmenu toont september 2023. Het inschrijfformulier linkt naar een 404.

Dit is niet luiheid. Het is een krisisverdeling van middelen. Wanneer je IT-medewerkers dwingt te kiezen tussen het netwerk draaiende houden en de website bijwerken, verliest de website altijd.

Het verband in content-updates door docenten

Docenten willen hun klassenpagina's bijwerken. Ze willen dat echt graag. Ze willen het lesprogramma plaatsen, huiswerkopdrachten delen en aankondigingen over de wetenschapsbeurs ophangen.

Maar WordPress is te complex voor niet-technische staf. Ik bedoel dat niet neerbuigend -- ik bedoel dat de WordPress-admininterface is ontworpen voor mensen die websites bouwen, niet voor mensen die wiskunde in het derde leerjaar onderwijzen. De Gutenberg-editor, de pluginconflicten, de mediabibliotheek, het taxonomiesysteem, de revisiegeschiedenis... het is veel.

Dit is dus wat werkelijk gebeurt:

  1. Docent probeert hun pagina bij te werken
  2. Iets gaat kapot (verkeerde template, opmaakprobleem, per ongeluk een widget verwijderd)
  3. Docent stuurt een e-mail naar IT
  4. IT heeft een achterstand van 3 weken
  5. Docent geeft het op
  6. Docent plaatst alles in plaats daarvan in Google Classroom

Nu is de officiële schoolwebsite irrelevant voor dagelijkse schoolcommunicatie. Ouders eindigen ermee om 3-5 verschillende apps te jongleren: de schoolwebsite (voor de spullen die er nog zijn), Google Classroom (voor werkelijke taken), ParentSquare (voor aankondigingen), Remind (voor snelle berichten) en misschien een Facebook-groep voor de zekerheid.

En ze kunnen nog steeds het busschema niet vinden.

Deze fragmentatie is frustrerend voor gezinnen. Het is vooral brutal voor ouders die niet technisch onderleggen zijn of kinderen op meerdere scholen in het district hebben. De schoolwebsite zou de enige bron van waarheid moeten zijn. In plaats daarvan is het de ene plek waar niemand kijkt.

ADA-compatibiliteit als een tikende rechtszaak

Dit houdt superintendenten 's nachts wakker -- of zou moeten.

Schooldistricten worden steeds vaker doelwit van ADA-rechtszaken wegens ontoegankelijke websites. En de schikingen zijn niet goedkoop. Een enkele ADA-rechtszaak kan een district $30.000 tot meer dan $100.000 kosten in juridische kosten en herstelskosten. In 2024 heeft het Department of Justice regels aangenomen die specifiek vereisen dat websites van staat- en lokale overheden (inclusief schooldistricten) voldoen aan WCAG 2.1 Level AA, met deadlines vanaf april 2026 voor grotere entiteiten.

Stel je nu WordPress Multisite voor met 50 schoolsites. Dat zijn 50 potentieel niet-compatibele sites. Elk onderhouden door een ander persoon (of niemand). Elk met een ander pakket plugins, een ander templateconfiguratie, verschillende alt-text-gewoonten voor afbeeldingen (of het ontbreken daarvan), en verschillende benaderingen van koppenstructuur.

50 sites afzonderlijk auditen? 50 sites afzonderlijk herstellen? Dat zijn honderden uren werk. En het moet elke keer opnieuw gedaan worden wanneer iemand content toevoegt, omdat één docent die een PDF-bestand uploadt zonder correct labeling of een afbeelding zonder alt-tekst, de pagina van die school weer uit naleving haalt.

Dit is wat een multi-tenant architectuur je geeft: één compatibele codebase betekent dat alle 50 scholen automatisch compatibel zijn. De componenten dwingen toegankelijkheid af. De koppenstructuur is standaard correct. Afbeeldingen uploaden vereisen alt-tekst. PDF's worden gemarkeerd als ze niet zijn gelabeld. Je lost een toegankelijkheidsprobleem één keer op, en het is overal opgelost.

Vertaalfalen is een gelijkheidscrisis

In diverse schooldistricten spreekt 30-50% van de families thuis een ander taal dan Engels. Spaans, Vietnamees, Arabisch, Mandarijn, Haïtiaans Creools -- het hangt van de gemeenschap af, maar de getallen zijn significant.

En hun schoolwebsites? Alleen Engels.

Deze families kunnen geen inschrijvingsinformatie vinden. Ze kunnen het proces van het gratis en gereduceerde lunchprogramma niet navigeren. Ze kunnen de vervoersroutes niet begrijpen. Ze missen evenementen, deadlines en kansen.

Dit is geen nice-to-have. Titel VI van de Civil Rights Act vereist dat schooldistricten die federale financiering ontvangen effectief communiceren met ouders met beperkte Engelse vaardigheid (LEP). Een website met alleen Engels is een nalevingsrisico en bovendien een gelijkheidsfalen.

Laten we kijken naar de kosten van het oplossen van dit:

Oplossing Jaarlijkse kosten
WPML op WordPress (50 sites × $199/jaar) $9.950/jaar + lopende vertaalkosten
Finalsite Geen echte meertalige ondersteuning
Google Translate-widget Onnauwkeurig, breekt lay-out, ADA-nachtmerrie
Next.js + next-intl + batchvertaling ~$110 eenmalig voor 5 talen

Die $110 is geen typo. Met een correct geinternationaliseerde Next.js-applicatie met next-intl extraheer je alle contenttekenreeksen, voer je ze uit via een vertalings-API voor ongeveer $22 per taal, beoordeel je met native speakers, en je bent klaar. Voeg een taal toe naarmate je gemeenschap dat nodig heeft. De routering verwerkt /es/schools/lincoln-elementary automatisch.

De Google Translate-widget die half deze districten gebruiken? Het produceert grammaticaal verbroken vertalingen, breekt de paginalay-out, veroorzaakt toegankelijkheidsproblemen, en -- kritiek -- het vertaalt geen content in afbeeldingen of PDF's. Het is een pleister die aan families signaleert: "Het interesseert ons niet genoeg om dit correct te doen."

Waarom WordPress Multisite de verkeerde keuze was

Om eerlijk te zijn, was WordPress Multisite geen onredelijke keuze in 2014-2016. Het was gratis (ish). Het kon technisch gezien meerdere sites vanuit één installatie draaien. Er was een enorm ecosysteem van plugins. En districten konden WordPress-ontwikkelaars vinden.

Maar dit gebeurde over het volgende decennium:

  • Plugin-uitbreiding: Elke site verzamelde plugins voor dingen die de kern niet kon. SEO, formulieren, kalenders, toegankelijkheidsoverlay's (die eigenlijk niet werken, trouwens), vertaling, caching, beveiliging. Onze audit vond een gemiddelde van 23 plugins per site. Dat zijn 23 potentiële beveiligingskwetsbaarheden, 23 dingen die kunnen conflicteren, 23 dingen die updates nodig hebben.
  • PHP-versionschulden: Veel van deze installaties draaien op PHP-versies die end-of-life zijn. PHP updaten riskeren om plugins te breken. PHP niet updaten is een beveiligingsgat.
  • De Gutenberg-chaos: WordPress's verschuiving naar de blokredacteur verbrakt werkstromen voor docenten die net de klassieke editor hadden leren kennen. Veel districten draaien nog steeds de Classic Editor-plugin, die zelf aan het verouderen is.
  • Prestatiesdodespiraal: WordPress serveerd server-rendered HTML uit een MySQL-database voor elk verzoek. Voeg WooCommerce (ja, sommige scholen draaien merch-winkels), BuddyPress of een zware plugin toe, en je kijkt naar 3-5 seconden laadtijd. Op mobiel via de celverbinding van het schoolplein? Vergeet het.
  • Beveiligingsoppervlak: WordPress voorziet 43% van het web, wat het #1-doelwit maakt voor geautomatiseerde aanvallen. Een enkele gecompromitteerde plugin in je multisite? Elke schoolsite is blootgesteld.

WordPress Multisite was de pragmatische keuze tien jaar geleden. Het is nu technische schuld.

De vendorval: Finalsite, Blackboard en SchoolPointe

Het alternatief dat de meeste districten overwegen is een K-12 website vendor. Finalsite is de grote naam. Er is ook Blackboard (nu Anthology), SchoolPointe, Apptegy (Thrillshare) en een paar andere.

Deze platforms lossen enkele problemen op. Ze verzorgen hosting. Ze voorzien templates. Ze hebben enkele toegankelijkheidsfuncties. Maar ze komen met serieuze afwegingen:

Kosten: Finalsite voor een district met 45 scholen loopt $135.000 tot $360.000 per jaar. Dat is geen eenmalige kostprijs. Dat is terugkerend. Elk jaar. Voor altijd. Als je weg wilt gaan, begin je vanaf nul -- er is geen gemakkelijke export van je content en structuur.

Inflexibiliteit: Je krijgt wat zij je geven. Behoefte aan een aangepaste integratie met je SIS? Dat zal een professional services engagement zijn. Wil je veranderen hoe de kalender werkt? Dien een functieverzoek in en wacht. Je district heeft een uniek tweetalig programma dat aangepaste routering nodig heeft? Jammer, dat staat niet in de template.

Prestaties: Ik voerde Lighthouse-audits uit op verschillende Finalsite-gehoste districtwebsites. Scores varieerden van 35 tot 62 op mobiel. Dit zijn in wezen marketingwebsites -- server-rendered pagina's met zware JavaScript-bundels, tracking scripts van derden en niet-geoptimaliseerde afbeeldingen. Ze zijn niet snel.

Lock-in: Dit is de grote. Je content leeft in hun CMS. Je URL's zijn op hun manier gestructureerd. Je gegevensmodel volgt hun schema. Drie jaar later zijn de switchkosten enorm. Ze weten dit. Dat is het bedrijfsmodel.

Ik zeg niet dat deze vendors kwaadaardig zijn. Ze bieden een echte service voor districten die nul technische capaciteit hebben. Maar als je de optie hebt om te investeren in infrastructuur die je bezit, wijst de wiskundige logica overweldigend in die richting.

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

De oplossing: Multi-tenant Next.js architectuur

Dit is wat we werkelijk bouwen. Één applicatie. Eenmaal geïmplementeerd. Serveerd voor elke school in het district.

/                          → District homepage
/schools/[slug]            → School homepage (45 schools)
/schools/[slug]/calendar   → School-specifieke evenementen
/schools/[slug]/staff      → Personeelsadressenboek
/schools/[slug]/staff/[id] → Klassenpagina van docent
/[lang]/schools/[slug]     → Vertaalde versie (es, vi, ar, zh, ht)
/portal                    → Parent portal (authenticatie vereist)
/admin                     → Content portal voor docenten/staf

45 scholen = 45 programmatische routes vanuit één codebase. Één implementatie. Één plek om bugs op te lossen. Één plek om toegankelijkheid af te dwingen. Één plek om functies toe te voegen.

De tech stack

Framework:     Next.js 15 (App Router)
CMS:           Headless (Sanity of Payload CMS)
Auth:          Supabase Auth + Row-Level Security
i18n:          next-intl
Hosting:       Vercel (of Cloudflare Pages)
Search:        Algolia of Typesense
Accessibility: axe-core in CI/CD pipeline

Docentenportal

Dit is het stukje dat alles verandert voor dagelijkse activiteiten. Docenten loggen in met hun Google-account van het district (SSO via Supabase Auth). Ze zien hun klassenpagina. Ze kunnen:

  • Hun syllabus bijwerken (rich text editor, niet WordPress Gutenberg)
  • Huiswerkopdrachten plaatsen met bestandsbijlagen
  • Aankondigingen toevoegen
  • Kantooruren en contactgegevens bijwerken

Dat is het. Geen zijbalken, geen widgets, geen plugininstellingen, geen "weet je zeker dat je wilt bijwerken?" bevestigingen. Een gerichte interface die vier dingen goed doet.

Row-Level Security (RLS) in Supabase betekent dat docenten alleen hun eigen content kunnen bewerken. Geen IT-overzicht nodig. Geen IT-tickets.

-- Supabase RLS-beleid: docenten kunnen alleen hun eigen klassenpagina bijwerken
CREATE POLICY "Teachers can update own content"
  ON class_pages
  FOR UPDATE
  USING (auth.uid() = teacher_id);

Ouderportal

Ouders authenticeren en zien een gepersonaliseerde weergave op basis van hun ingeschreven kinderen. Busroute voor hun kind. Lunchmenu voor hun school. Aankomende evenementen gefilterd naar relevante scholen. Contactgegevens van docenten voor huidige docenten van hun kind.

Niet meer door 45 schoolsites graven om informatie over je drie kinderen op drie verschillende scholen te vinden.

Toegankelijkheid standaard

De componentenbibliotheek dwingt WCAG AA af. Elke <Image>-component vereist alt-tekst. Koppenstructuur wordt afgedwongen door de paginasjabloon. Kleurcontrast wordt gevalideerd bij het compileren. Focus-management wordt afgehandeld in de navigatiecomponenten.

We voeren axe-core uit in de CI/CD-pipeline. Elke pull request krijgt een toegankelijkheidsaudit. Als het mislukt, wordt het niet geïmplementeerd. Punt.

Dit is van belang wanneer je 200 docenten content toevoegt. Je kunt niet 200 mensen trainen in toegankelijkheid. Je kunt een systeem bouwen dat maakt dat niet-naleving structureel onmogelijk is.

Prestaties

Next.js met statische generatie betekent dat schoolpagina's bij het compileren vooraf worden gerenderd en vanuit een CDN worden bediend. Een ouder op het schoolplein op een 3G-verbinding krijgt de pagina in minder dan een seconde. Lighthouse-scores bereiken consistent 90+.

We hebben het over het verschil tussen een 41 Lighthouse-score (WordPress Multisite-gemiddelde uit onze audit) en een 95. Dat is geen incrementele verbetering. Het is een ander ervaring.

De wiskundige logica die dit duidelijk maakt

Laten we de drie jaar totale kostenbezit doen voor een district met 45 scholen:

Oplossing Jaar 1 Jaar 2 Jaar 3 3-jaars totaal
Finalsite $135-360K $135-360K $135-360K $405K-$1.080K
WordPress Multisite (bestaande onderhouden) $30-50K $30-50K $30-50K $90-150K
Next.js Multi-Tenant (bouwen + hosting) $60-100K + $540 $540 $540 $61-101K

De Next.js hostingkosten zijn $45/maand op Vercel Pro, of nog minder op Cloudflare Pages. Dat is $540/jaar voor een platform dat 45 scholen bedient. De WordPress-hosting alleen is typisch $500-1.500/maand voor een beheerde multisite-installatie.

Break-even versus Finalsite: 3-6 maanden. Break-even versus lopend WordPress-onderhoud: jaar één.

En hier is wat de WordPress-kostkolom niet vastlegt: de IT-personeelstijd. Die 2-3 IT-medewerkers die 10-15 uur per week aan websitebranden doorbrengen? Dat is $30-50K in salaristoewijzing die naar letterlijk alles anders zou kunnen gaan. Chromebook-beheer. Cyberbeveiliging. Eigenlijk eens een nacht goed slapen.

De bouwkosten van $60-100K voor het Next.js-platform zijn een eenmalige investering. Je bent de eigenaar. Geen jaarlijkse licentie. Geen per-schooltarief. Geen vendorlock-in. Een 46e school toevoegen? Het is een nieuwe vermelding in de CMS, geen verkoopgesprek.

Hoe de migratie er werkelijk uitziet

We gaan niet doen alsof dit triviaal is. Het migreren van 45 schoolwebsites is een project. Hier is hoe het uiteenvalt:

Weken 1-3: Ontdekking en content-audit

  • Inventaris van alle bestaande content op 45 sites
  • Identificeer wat werkelijk actueel is versus wat verlaten is
  • Kaart de informatiestructuur in kaart
  • Interviews met IT-staf, docenten en ouders over pijnpunten

Weken 4-8: Platformbouw

  • Multi-tenant Next.js-applicatie met headless CMS-integratie
  • Docentenportal met Supabase Auth
  • Componentenbibliotheek met ingebakken toegankelijkheid
  • i18n-setup met next-intl
  • CI/CD-pipeline met automatische toegankelijkheidstests

Weken 9-12: Content-migratie en training

  • Geautomatiseerde content-migratiehalfautomatische scripts (WordPress REST API → headless CMS)
  • Handmatige content-beoordeling en opruiming
  • Docententraining (30-minuut sessies -- als het langer duurt, moet de UX worden aangepast)
  • Zachte lancering van ouderportal

Weken 13-14: Lancering

  • DNS-switch
  • Redirection mapping (elke oude URL krijgt een 301)
  • Monitoring en ondersteuning

Totale timeline: 14 weken. Dat is één semester. Je kunt lanceren over de winter- of zomervakantie wanneer het verkeer het laagst is.

Het sleutelinzicht: je bouwt niet 45 websites opnieuw. Je bouwt één website die 45 scholen bedient. Dat is een orde-van-grootte afname in complexiteit.

Als je district deze soort migratie verkent, hebben we dit werk eerder gedaan. Neem contact op en we kunnen de details voor je districtgrootte en behoeften doorlopen. Je kunt ook onze prijspagina raadplegen voor benaderde bereiken op projecten als deze.

Veelgestelde vragen

Hoeveel kost het herontwerpen van een website van een schooldistrict? Het hangt van de aanpak af. Vendorplatforms zoals Finalsite kosten $135.000-$360.000 per jaar voor een district met 45 scholen. Het onderhouden van een bestaande WordPress Multisite kost $30.000-$50.000 per jaar in IT-tijd, hosting en ondersteuning voor ontwikkelaars. Een aangepaste multi-tenant Next.js-build loopt $60.000-$100.000 als eenmalige investering met ongeveer $540/jaar in hosting. Over drie jaar is de aangepaste build de goedkoopste optie met grote marges -- en je bent eigenaar van het platform.

Is WordPress Multisite goed voor schooldistricten? Het was een redelijke keuze in 2014-2016, maar het is een aansprakelijkheid geworden. De plugin-uitbreiding, beveiligingsoppervlak, slechte mobiele prestaties en onvermogen om toegankelijkheid over 50 sites af te dwingen maken het een slechte pasvorm voor moderne K-12-vereisten. Elke site in het netwerk kan in verschillende richtingen afdrijven, en met 2-3 IT-medewerkers die alles anders in het district beheren, heeft niemand tijd om het onderhouden. Districten met WordPress Multisite vanaf 2016 dragen aanzienlijke technische schuld.

Wat zijn de ADA-nalevingsvereisten voor websites van schooldistricten? Het Department of Justice stelde in 2024 regels op die vereisen dat websites van staat- en lokale overheden -- inclusief openbare schooldistricten -- voldoen aan WCAG 2.1 Level AA-normen. Grotere entiteiten hebben deadlines vanaf april 2026. Niet-naleving kan resulteren in rechtszaken met schikkingen variërend van $30.000 tot meer dan $100.000 in juridische kosten en herstel. De belangrijkste uitdaging voor districten is dat naleving geen eenmalige oplossing is -- elk stuk content dat wordt toegevoegd, moet naleving behouden, daarom is het inbouwen van toegankelijkheidshandhaving in het platform zelf de enige duurzame benadering.

Hoe handel je meerdere talen op een schoolwebsite af? Met een Next.js-applicatie met next-intl is internationalisering ingebouwd in de routeringsstructuur. Elke taal krijgt haar eigen URL-voorvoegsel (/es/, /vi/, /ar/), wat beter is voor SEO en toegankelijkheid dan een Google Translate-widget. Content-vertaling voor 5 talen kost ongeveer $110 met behulp van vertalings-API's met beoordeling door native speakers. Vergelijk dat met WPML op WordPress op $199/jaar per site ($9.950/jaar voor 50 sites), en de besparingen zijn dramatisch. Nog belangrijker, de vertalingen zijn nauwkeurig, correct opgemaakt en breken de paginalay-out niet.

Kunnen docenten hun eigen pagina's bijwerken zonder IT-ondersteuning? Ja -- dat is het hele punt van de docentenportal. Docenten authenticeren met hun Google-account van het district, zien een vereenvoudigde editor voor hun klassenpagina, en kunnen hun syllabus bijwerken, taken plaatsen, aankondigingen toevoegen en contactgegevens bijwerken. Row-Level Security zorgt ervoor dat ze alleen hun eigen content kunnen bewerken. Geen IT-tickets, geen 3-weken achterstand, geen opgeven en alles in Google Classroom plaatsen. Als de bewerkingsinterface langer dan 30 minuten training vereist, beschouwen we dat als een UX-falen en ontwerpen we het opnieuw.

Hoe lang duurt het om een schooldistrictwebsite te migreren? Voor een district met 45 scholen verwacht je een 14-weken timeline: 3 weken voor ontdekking en content-audit, 5 weken voor platformbouw, 4 weken voor content-migratie en training, en 2 weken voor lancering. Het beste moment om te lanceren is over winter- of zomervakantie wanneer websiteverkeer het laagst is. Content-migratie is gedeeltelijk geautomatiseerd met de WordPress REST API om content uit de nieuwe headless CMS te extraheren, maar handmatige beoordeling en opruiming is noodzakelijk omdat veel van de oude content verouderd is.

Wat is beter voor schoolwebsites: Finalsite of een aangepaste build? Finalsite heeft zin voor districten met absoluut nul technische capaciteit en budget voor lopende licenties. Voor districten die kunnen investeren in een eenmalige build, kost een aangepast multi-tenant Next.js-platform minder over drie jaar ($61-101K versus $405K-$1.08M), presteert beter (Lighthouse 95+ versus 35-62), biedt volledig eigendom van content en infrastructuur, en biedt flexibiliteit voor aangepaste integraties met SIS, LMS en andere districtsystemen. De afweging is dat je een ontwikkelingpartner nodig hebt voor de initiële build en lopende functiesontwikkeling.

Waarom zijn schooldistrictwebsites zo langzaam op mobiel? De meeste districtwebsites draaien WordPress met 20+ plugins, elk voegend JavaScript en CSS toe aan elke pagina-load. De server-rendered pagina's vereisen een databasequery voor elk verzoek. Afbeeldingen zijn vaak niet geoptimaliseerd. Er is geen CDN, of de CDN is verkeerd geconfigureerd. Voeg een gedeelde hostingomgeving toe en je kijkt naar 3-5 seconde laadtijden. Op een mobiele verbinding op het schoolplein is het nog erger. Een statisch gegenereerde Next.js-site serveerd vooraf gebouwd HTML vanuit edge-servers wereldwijd, typisch laden in minder dan een seconde. Dat is van belang wanneer een ouder een sneeuwdagaankondiging om 6 uur 's ochtends op hun telefoon controleert.

Zijn schooldistricten eigenaar van hun website als ze een vendor als Finalsite gebruiken? Nee. Je content leeft in hun CMS, gestructureerd volgens hun gegevensmodel, gehost op hun infrastructuur. Als je besluit te gaan, begin je in wezen opnieuw. Er is geen schone export van je content, sjablonen of configuratie. Deze lock-in is opzettelijk -- het is wat het terugkerende inkomstenmodel laat werken. Met een aangepaste build met behulp van een headless CMS zoals Sanity of Payload ben jij eigenaar van elk stuk content, elke regel code en elke implementatieconfiguratie. Je kunt hostingproviders wisselen, je front-end-framework wijzigen of ontwikkeling in-house brengen zonder iets kwijt te raken.

Je districtwebsite is de voordeur voor 10.000 families. Als die voordeur niet op een telefoon opengaat, hun taal niet spreekt en docenten hun eigen pagina's niet kan laten bijwerken -- faalt het iedereen die het zou moeten dienen.