How to Actually Make Your Website Fast

• Waarom We Van Laravel Naar Next.js Zijn Gemigreerd
• Onze Eerste Lighthouse Audit op Next.js Was Nederig
• Hoe We de JavaScript Bundelgrootte Verminderden met Betere Scriptbeheer
• Next.js Afbeeldingsoptimalisatie: WebP, CDN, en de Priority Eigenschap
• Next.js Renderstrategie: 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 deze post waarin we je vertellen dat we een groot plan hadden, het vlekkeloos uitvoerden, en een perfect geoptimaliseerde site lanceerden. Dat is niet wat er gebeurde.

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

Waarom We Van Laravel Naar Next.js Zijn Gemigreerd

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 perfect redelijk voor de schaal waarop we zaten. Maar naarmate het product groeide met meerdere talen, prijspagina's die live data ophalen, een blog met echt verkeer, complexe auth flows; wat ooit "perfect redelijk" was, werd "stilaan 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 implementatie. Het toevoegen van een nieuwe paginasectie betekende dat data door controllers stroomde, door view composers, naar beneden in Blade bestanden. De mensen die de frontend zouden moeten beheren (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 Nederig

Onze eerste Lighthouse audit op de nieuwe Next.js site leverde niet de verbetering op die we verwachtten. Toen we de nieuwe site opzetten en voor de eerste keer 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 waar we van ophaalden hadden geen browser hints. Onze afbeeldingen stonden op "$static.plusclouds.com$". Onze API was "$apiv4.plusclouds.com$". Geen van beide had een preconnect hint in de documentkop. Dus bij elke paginalading zou de browser HTML parsen, 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 simpel. Maar preconnect hints zijn een van die dingen waar de kosten van het niet hebben ervan zich opstapelen over 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 Bundelgrootte Verminderden met Betere Scriptbeheer

Het verminderen van de JavaScript bundelgrootte 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 chatwidget daar, een third-party 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 verzonden, niet enige doordachte overweging van wat de pagina daadwerkelijk 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 iconenbibliotheken importeerden terwijl ze twee iconen gebruikten. We hadden hulpfuncties 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 dragen ze bij aan een betekenisvol grotere JavaScript bundel. We gingen methodisch door de codebase: elk third-party 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 teruggezet naar servercomponenten. De bundelgrootte daalde, en daarmee de tijd voordat de pagina interactief werd.

De scriptbundelregel die we hebben vastgesteld 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 Eigenschap

Next.js afbeeldingsoptimalisatie — inclusief formaatconversie, CDN-levering, en de priority eigenschap, was het duurste onderdeel op elke pagina, en we hebben het meer dan eens verkeerd gedaan. 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 via imgproxy op onze CDN. Elke afbeelding wordt aangepast aan de werkelijk benodigde afmetingen, geserveerd in het juiste formaat voor de aanvragende browser, en in de cache opgeslagen 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 verlaagt de bestandsgroottes met 60 tot 80 procent. We hadden een 1,3MB PNG op onze homepage hero en merkten het niet totdat Lighthouse het voor de vierde opeenvolgende audit markeerde. Die afbeelding zou rond de 200KB in WebP moeten wegen. De CDN kan dat niet oplossen; alleen het bronbestand converteren kan dat.

Het andere dat we langer verkeerd deden dan we zouden moeten hebben: de priority eigenschap 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 worden geladen. 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 eigenschap. De LCP-verbetering is onmiddellijk en meetbaar.

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

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

Server-gerenderd bij elk verzoek, statisch gegenereerd bij buildtijd, 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, prijsklassen, functiedocumentatie) veranderen niet per minuut. Ze gebruiken nu generateStaticParams gecombineerd met ISR en een revalidatietijd van een uur. Bij buildtijd wordt elke lokale combinatie vooraf gerenderd naar statische HTML. Een gebruiker die een productpagina bezoekt, krijgt een gecachte file 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 blogindex, live prijzen, alles wat gebruikersspecifiek is) gebruiken korte revalidatietijden of dynamische rendering met caching op componentniveau. Het resultaat is dat de overgrote meerderheid van ons verkeer wordt geserveerd vanaf statische HTML, en de server doet alleen echt werk wanneer de inhoud daadwerkelijk is veranderd.

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

SEO gestructureerde gegevens, hreflang tags, en OpenGraph metadata zijn onzichtbaar voor gebruikers maar van belang voor alles, 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. Organization 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 antwoordboxen.

De hreflang situatie was rommeliger. We ondersteunen vier lokale en onze alternatieve links waren op zijn best inconsistent, op zijn slechtst ontbrekend. We bouwden een gedeelde buildAlternates() functie die correcte hreflang tags genereert vanuit een enkel padargument en op elke pagina draait. 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 afbeeldingsafmetingen 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 onder 2,5 seconden op de meeste pagina's. TTFB is onder 100ms voor statisch geserveerde inhoud.

We zijn 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 is dat je afmaakt, het is een set van standaarden die je vaststelt. priority op elke hero afbeelding voordat de PR wordt samengevoegd. preconnect toegevoegd op dezelfde dag dat een nieuw extern domein wordt geïntroduceerd. Gestructureerde gegevens geschreven naast de pagina-inhoud, 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 opgehoopte beslissingen en begin je standaard snel te verzenden.

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.