Hoe u uw website daadwerkelijk snel kunt maken

• Waarom We Gemigreerd Zijn van Laravel naar Next.js
• Onze Eerste Lighthouse Audit op Next.js Was Vernederend
• Hoe We de JavaScript Bundle Grootte Verminderden met Betere Scriptbeheer
• Next.js Afbeeldingsoptimalisatie: WebP, CDN, en de Priority Prop
• Next.js Rendering Strategie: Statische Generatie, ISR, en Dynamische Rendering
• SEO Gestructureerde Gegevens, hreflang, en OpenGraph in Next.js
• Resultaten: Lighthouse Score Boven 90, LCP Onder 2,5s, TTFB Onder 100ms

Iedereen wil een snelle website, maar verschillende websites hebben verschillende trajecten. Dit is onze ervaring, onze redenatie, ons traject en onze resultaten. Hier is wat we deden om onze website sneller te maken in 2026.

Word lid van onze community als je meer gepersonaliseerd advies wilt voor jouw website specifiek.

Er is een versie van dit bericht waarin we je vertellen dat we een groots plan hadden, het vlekkeloos uitvoerden en een perfect geoptimaliseerde site leverden. Dat is niet wat er gebeurde.

Wat er eigenlijk gebeurde, is dat we een groeiende codebase erfden, onze eerste Lighthouse audit in een tijdje uitvoerden, een score van 34 op mobiel zagen, en een lang, ongemakkelijk gesprek hadden over hoe we daar terechtkwamen.

Waarom We Gemigreerd Zijn van Laravel naar Next.js

Migreren van Laravel naar Next.js was niet onze eerste instinct, maar het werd de voor de hand liggende keuze. Onze marketing site begon als een Laravel applicatie. Blade templates, server-gerenderde HTML, een vleugje jQuery. Het was volkomen redelijk voor de schaal waarop we ons bevonden. Maar naarmate het product groeide met meerdere talen, prijs pagina's die live data ophalen, een blog met echt verkeer, complexe auth flows; wat ooit "volkomen redelijk" was, werd "stilletjes duur om te onderhouden."

Het echte probleem was niet de prestaties. Het was de snelheid. Elke frontend wijziging raakte PHP. Een tekstwijziging betekende een backend deployment. Het toevoegen van een nieuwe paginasectie betekende dat gegevens door controllers stroomden, door view composers, naar Blade bestanden. De mensen die eigenaar zouden moeten zijn van de frontend (ontwerpers, marketeers, productie) konden het niet aanraken zonder een engineer in de lus.

We migreerden naar Next.js 15 met de App Router. Niet omdat het het gemakkelijkste pad was, maar omdat het ons server-side rendering, statische generatie, incrementele revalidatie, en een goed componentmodel gaf, allemaal in één framework. De beslissing was juist. De uitvoering had ruwe randen die we nog steeds gladstrijken.

Onze Eerste Lighthouse Audit op Next.js Was Vernederend

Onze eerste Lighthouse audit op de nieuwe Next.js site leverde niet de verbetering die we verwachtten. Toen we de nieuwe site voor het eerst draaiden, verwachtten we een verbetering ten opzichte van Laravel. Die kregen we niet, althans niet onmiddellijk.

De score was slechter in sommige categorieën. Dat was verwarrend totdat we begrepen waarom: migreren naar een modern framework maakt je site niet automatisch snel. Het geeft je betere tools. Die tools correct gebruiken is een apart probleem.

Het eerste dat we opmerkten dat onze site vertraagde, waren render-blocking resources. Niet JavaScript, daar waren we voorzichtig mee geweest. Het probleem was subtieler: externe domeinen waarvan we fetchten hadden geen browser hints. Onze afbeeldingen leefden op "$static.plusclouds.com$". Onze API was "$apiv4.plusclouds.com$". Geen van beide had een preconnect hint in de document head. Dus bij elke paginalading zou de browser HTML parseren, een verzoek naar een extern domein tegenkomen, en dan beginnen met de DNS-resolutie en TCP-handshake vanaf nul.

Twee regels in de root layout losten het op:

<link rel="preconnect" href="https://static.plusclouds.com" />
<link rel="preconnect" href="https://apiv4.plusclouds.com" />

Het klinkt bijna te eenvoudig. Maar preconnect hints zijn een van die dingen waarbij de kosten van het niet hebben ervan zich opstapelen bij elke enkele paginalading, voor elke enkele bezoeker. De browser begint nu die verbindingen tot stand te brengen voordat het zelfs de eerste afbeelding of API oproep tegenkomt. Dus, preconnect hints zijn iets om op te letten als je je website sneller wilt maken.

Hoe We de JavaScript Bundle Grootte Verminderden met Betere Scriptbeheer

Het verminderen van de JavaScript bundle grootte met beter scriptbeheer was een van de stillere maar meest impactvolle overwinningen in onze migratie. In het Laravel tijdperk hadden scripts zich organisch opgestapeld. Analytics hier, een chat widget daar, een derde partij pixel toegevoegd tijdens een marketingcampagne die nooit werd verwijderd. Elk was een synchrone of uitgestelde script tag, en de volgorde waarin ze werden toegevoegd weerspiegelde de volgorde waarin functies werden geleverd, niet enige doordachte overweging van wat de pagina eigenlijk nodig had om te renderen.

Toen we naar Next.js verhuisden, namen we enkele van die gewoonten mee met beter scriptbeheer. We hadden componenten die hele icon libraries importeerden terwijl ze twee iconen gebruikten. We hadden utility functies geïmporteerd bovenaan bestanden die alleen nodig waren in een specifieke tak. We hadden client componenten gemarkeerd met 'use client' die helemaal geen interactiviteit hadden; ze waren gewoon zo geschreven toen iemand het niet zeker wist.

Elk van deze zijn kleine elementen. Collectief voegen ze zich op tot een betekenisvol grotere JavaScript bundle. We gingen methodisch door de codebase: elk derde partij script werd geëvalueerd of het in de < head > moest staan of kon worden uitgesteld. Elke grote import werd gecontroleerd op daadwerkelijk gebruik.

Componenten die geen browser API's nodig hadden, werden terug omgezet naar server componenten. De bundle grootte daalde, en daarmee de tijd voordat de pagina interactief werd.

De script bundle regel die we vaststelden om de site sneller te maken is deze: niets wordt geïmporteerd totdat het nodig is, niets draait in de browser dat op de server kan draaien, en niets laadt in de < head > tenzij het een zichtbare render zou blokkeren.

Als je meer leads wilt verwijzen naar je snelle website, bekijk dan onze ai tool die het verkoopproces automatiseert.

Next.js Afbeeldingsoptimalisatie: WebP, CDN, en de Priority Prop

Next.js afbeeldingsoptimalisatie — inclusief formaatconversie, CDN levering, en de priority prop, was het duurste onderdeel op elke pagina, en we deden het meer dan eens verkeerd. Iedereen knikt bij afbeeldingsoptimalisatie en gaat dan terug naar het uploaden van een 3,7MB JPEG direct vanuit Figma export. We deden precies dat. Meerdere keren.

De aangepaste afbeeldingsloader die we bouwden, leidt al het productie verkeer door imgproxy op onze CDN. Elke afbeelding wordt aangepast aan de werkelijk benodigde afmetingen, geserveerd in het juiste formaat voor de verzoekende browser, en gecached aan de rand. Een mobiele bezoeker op een 390px scherm downloadt niet langer een 1600px versie van dezelfde afbeelding. De loader handelt dit allemaal transparant af; de ontwikkelaar schrijft een normale < Image > tag en de CDN doet de rest.

Maar formaatconversie is een apart probleem van levering. Een JPEG geserveerd vanaf een snelle CDN is nog steeds een JPEG. Het converteren van hero achtergronden en grote marketingafbeeldingen naar WebP vermindert de bestandsgrootte met 60 tot 80 procent. We hadden een 1,3MB PNG op onze homepage hero en merkten het niet op totdat Lighthouse het voor de vierde opeenvolgende audit markeerde. Die afbeelding zou ongeveer 200KB in WebP moeten wegen. De CDN kan dat niet oplossen; alleen het bronbestand converteren kan dat.

Het andere dat we langer dan we zouden moeten hebben verkeerd deden: de priority prop op Next.js afbeeldingen. Het framework laadt afbeeldingen standaard lui, wat het juiste gedrag is voor afbeeldingen onder de vouw. Maar het Largest Contentful Paint element (bijna altijd de hero afbeelding) mag nooit lui geladen worden. Het toevoegen van priority vertelt Next.js om die afbeelding vooraf te laden en te stoppen met het behandelen als optionele inhoud. Het is één prop. De LCP verbetering is onmiddellijk en meetbaar.

Next.js Rendering Strategie: Statische Generatie, ISR, en Dynamische Rendering

Het kiezen van de juiste Next.js rendering strategie (statische generatie, ISR, of dynamische rendering) is een van de belangrijkste architectonische beslissingen in het framework, en het heeft echte prestatiegevolgen.

Server-gerenderd bij elk verzoek, statisch gegenereerd bij build tijd, statisch gegenereerd met periodieke revalidatie: dit zijn verschillende tools voor verschillende problemen, en het gebruik van de verkeerde heeft echte prestatiegevolgen.

Onze productpagina's (server specificaties, prijstiers, functiedocumentatie) veranderen niet per minuut. Ze gebruiken nu generateStaticParams gecombineerd met ISR en een revalidatietijd van één uur. Bij build tijd wordt elke lokale combinatie vooraf gerenderd naar statische HTML. Een gebruiker die een productpagina bezoekt, krijgt een gecached bestand geserveerd vanaf de CDN rand in minder dan 100ms. Er is geen server, geen database query, geen Node.js proces dat wakker wordt.

Pagina's die wel verse data nodig hebben (de blog index, live prijzen, alles wat gebruikersspecifiek is) gebruiken korte revalidatietijden of dynamische rendering met caching op componentniveau. Het resultaat is dat de overweldigende meerderheid van ons verkeer wordt geserveerd vanaf statische HTML, en de server alleen echt werk doet wanneer de inhoud daadwerkelijk is veranderd.

TTFB op de meeste pagina's is nu consequent onder 100ms. Op de oude Laravel setup was het zelden onder 400ms. Dat is niet het framework dat magie doet, het is een gevolg van bewust besluiten, voor elke pagina, welke rendering strategie zinvol is.

SEO gestructureerde gegevens, hreflang tags, en OpenGraph metadata zijn onzichtbaar voor gebruikers maar van belang voor alles wat er verder toe doet, en we hadden er bijna geen toen we migreerden. Optimaliseren voor Google's generatieve AI functies vereist goed gestructureerde, doorzoekbare inhoud met de juiste schema markup.

We voegden FAQPage JSON-LD toe aan product- en functiepagina's. SoftwareApplication schema voor onze tools. BreadcrumbList voor navigatiehiërarchie. Organisatie schema in de root layout. Deze worden gelezen door zoekcrawlers en steeds meer door de AI-systemen die beslissen of je inhoud wordt opgenomen in gegenereerde samenvattingen en antwoordvakken.

De hreflang situatie was rommeliger. We ondersteunen vier lokale en onze alternatieve links waren op zijn best inconsistent, op zijn slechtst afwezig. We bouwden een gedeelde buildAlternates() functie die correcte hreflang tags genereert vanuit een enkel padargument en draait op elke pagina. Het is het soort ding dat aanvoelt als huishoudelijk werk totdat je je realiseert dat verkeerde of ontbrekende hreflang tags je internationale zoekprestaties actief schaden.

OpenGraph metadata was vergelijkbaar, sommige pagina's hadden het, sommige niet, de afbeeldingsdimensies waren inconsistent. Het centraliseren ervan via Next.js's generateMetadata API en het toevoegen van metadataBase aan de root layout betekende dat we er niet meer per pagina over nadachten en het overal standaard goed deden.

Resultaten: Lighthouse Score Boven 90, LCP Onder 2,5s, TTFB Onder 100ms

Na de migratie is onze Lighthouse score op mobiel consequent boven de 90. CLS is onder 0,05. LCP is op de meeste pagina's onder 2,5 seconden. TTFB is onder 100ms voor statisch geserveerde inhoud.

We zijn nog niet klaar. Er zijn nog steeds afbeeldingen die WebP zouden moeten zijn maar dat niet zijn, pagina's die statisch gegenereerd zouden kunnen worden maar standaard dynamische rendering gebruiken, en gestructureerde gegevens die specifieker zouden kunnen zijn. De lijst is korter dan het was, maar bereikt nooit nul.

De eerlijke les uit dit alles is dat prestaties geen project zijn dat je afmaakt, het is een set van standaarden die je vaststelt. priority op elke hero afbeelding voordat de PR wordt samengevoegd. preconnect toegevoegd dezelfde dag dat een nieuw extern domein wordt geïntroduceerd. Gestructureerde gegevens geschreven naast de paginainhoud, niet achteraf toegevoegd. Imports gecontroleerd voordat ze bundelgewicht worden.

Wanneer die dingen gewoonten zijn in plaats van checklists, stop je met het doorbrengen van sprints om te herstellen van opgestapelde beslissingen en begin je standaard snel te leveren.

Word lid van onze community als je meer gepersonaliseerd advies wilt voor jouw website specifiek.

Bekijk onze servers om snelle, intelligente infrastructuur te ontgrendelen vanuit één enkel paneel. Onze gratis functies zoals geautomatiseerde back-ups en herstel, geplande gezondheidscontroles en directe schaalvergroting helpen om je website beter te laten functioneren. Voel je vrij om ze te bekijken.