Hoe Versnelt U Uw Website Echt

• Waarom zijn we van Laravel naar Next.js overgestapt?
• Onze Eerste Lighthouse Audit in Next.js Was Een Les
• Hoe We de JavaScript Bundelgrootte Verminderden met Betere Scriptbeheer?
• Next.js Afbeeldingsoptimalisatie: WebP, CDN en Priority Functie
• 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 sites hebben verschillende trajecten. Dit is onze ervaring, logica, reis en resultaten. Hier is wat we in 2026 hebben gedaan om onze site te versnellen.

Als u meer gepersonaliseerd advies voor uw website wilt, sluit u dan aan bij onze gemeenschap.

Een versie van dit artikel vertelt dat we een groot plan hadden, het perfect uitvoerden en een perfect geoptimaliseerde site lanceerden. Dat was niet wat er werkelijk gebeurde.

Wat er eigenlijk gebeurde, was dat we een groeiende codebase overnamen, voor het eerst in lange tijd een Lighthouse audit deden, een score van 34 op mobiel zagen en een lange en ongemakkelijke discussie voerden over hoe we daar waren gekomen.

Waarom zijn we van Laravel naar Next.js overgestapt?

Overstappen van Laravel naar Next.js was niet onze eerste ingeving, maar werd na verloop van tijd de meest voor de hand liggende keuze. Onze marketingwebsite begon als een Laravel applicatie. Blade templates, server-side gegenereerde HTML, een beetje jQuery. Het was redelijk voor onze schaal destijds. Maar naarmate het product groeide; met de behoefte aan meertalige ondersteuning, prijsvergelijkingspagina's die live data ophalen, een blog met echt verkeer, complexe authenticatiestromen, werd de oplossing die ooit "redelijk" was, een "stilaan dure structuur".

Het echte probleem was niet de prestaties. Het probleem was de snelheid. Elke front-end wijziging raakte PHP. Zelfs een tekstbewerking vereiste een backend-deployment. Een nieuwe sectie aan een pagina toevoegen betekende dat gegevens van controllers, via view composers, naar Blade-bestanden moesten stromen. Mensen die de front-end moesten beheren (ontwerpers, marketeers, productieteam) konden er niet aan zonder dat een engineer tussenbeide kwam.

We zijn overgestapt naar Next.js 15 met de App Router. Niet omdat het de gemakkelijkste weg was, maar omdat het ons alles bood onder één dak: server-side rendering, statische generatie, incrementele revalidatie en een fatsoenlijk componentmodel. De beslissing was juist. De uitvoering had echter nog steeds ruwe kantjes die we proberen glad te strijken.

Onze Eerste Lighthouse Audit in Next.js Was Een Les

Onze eerste Lighthouse audit op de nieuwe Next.js site bracht niet de verwachte verbetering. Toen we de nieuwe site voor het eerst lanceerden, verwachtten we een verbetering ten opzichte van Laravel. Dat gebeurde niet meteen, althans niet onmiddellijk.

In sommige categorieën was de score slechter. Dit was verwarrend totdat we de oorzaak begrepen: overstappen naar een modern framework maakt uw site niet automatisch snel. Het biedt u betere tools. Die tools correct gebruiken is een ander verhaal.

We ontdekten dat het eerste wat onze site vertraagde render-blocking resources waren. Het was niet JavaScript, daar waren we voorzichtig mee. Het probleem was subtieler: er waren geen browser hints voor externe domeinen waar we data van ophaalden. Onze afbeeldingen stonden op "$static.plusclouds.com$". Onze API was "$apiv4.plusclouds.com$". Geen van beiden had een preconnect hint in de documentkop. Dus bij elke paginalading parseerde de browser de HTML, zag de aanvraag naar een extern domein en begon dan vanaf nul met DNS-resolutie en TCP-handshake.

Twee regels die we aan de root layout toevoegden, losten dit op:

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

Het lijkt bijna te simpel. Maar preconnect hints zijn een van die dingen waarvan de kosten van het niet hebben exponentieel toenemen bij elke paginalading, voor elke bezoeker. De browser begint nu deze verbindingen op te zetten voordat hij de eerste afbeelding of API oproep tegenkomt. Dus als u uw site wilt versnellen, is een van de dingen waar u op moet letten preconnect hints.

Hoe We de JavaScript Bundelgrootte Verminderden met Betere Scriptbeheer

Het verminderen van de JavaScript bundelgrootte met beter scriptbeheer was een stille maar zeer effectieve winst in onze overgang. In de Laravel-tijd hadden scripts zich organisch opgestapeld. Hier een analysetool, daar een chatwidget, een derde partij pixel toegevoegd tijdens een marketingcampagne en nooit verwijderd. Elk was toegevoegd als een synchrone of uitgestelde script tag, en de volgorde van toevoeging weerspiegelde de volgorde waarin functies werden uitgerold; wat de pagina echt nodig had, werd nauwelijks overwogen.

Toen we naar Next.js gingen, namen we enkele van deze gewoonten mee, maar met beter scriptbeheer. Een component dat twee pictogrammen gebruikte, importeerde de hele pictogrammenbibliotheek. Helperfuncties die alleen in een specifieke tak nodig waren, werden bovenaan het bestand geïmporteerd. We hadden client componenten gemarkeerd als 'use client' zonder enige interactie, alleen omdat iemand er niet zeker van was.

Elk van deze is een klein element. Maar samen vormen ze een aanzienlijk grotere JavaScript bundel. We hebben de codebase systematisch doorgelicht: elk derde partij script werd beoordeeld of het in de < head > moest staan of kon worden uitgesteld. Elke grote import werd gecontroleerd op daadwerkelijke gebruik.

Componenten die geen browser API's nodig hadden, werden terug omgezet naar server componenten. De bundelgrootte nam af en daarmee ook de tijd die de pagina nodig had om interactief te worden.

De regel die we hebben aangenomen voor het scriptpakket om de site sneller te maken, is deze: Niets wordt geïmporteerd totdat het nodig is, niets dat op de server kan draaien, draait in de browser, en niets wordt geladen in de < head > tenzij het een zichtbare render blokkeert.

Als u wilt dat meer potentiële klanten naar uw snelle website worden geleid, bekijk dan ons AI-gestuurde verkoopautomatiseringshulpmiddel.

Next.js Afbeeldingsoptimalisatie: WebP, CDN en Priority Functie

Next.js afbeeldingsoptimalisatie — inclusief formaatconversie, levering via CDN en de priority functie — was het duurste item op elke pagina en we hebben het meerdere keren verkeerd gedaan. Iedereen knikt bij afbeeldingsoptimalisatie, maar gaat dan een 3,7MB JPEG direct uit Figma uploaden. Dat deden wij ook. Meer dan eens.

Onze aangepaste afbeeldingsloader stuurt al het productieverkeer via imgproxy op onze CDN. Elke afbeelding wordt opnieuw geschaald naar de werkelijk benodigde afmetingen, geleverd in een formaat dat geschikt is voor de aanvragende browser en aan de rand gecached. Een mobiele bezoeker met een scherm van 390px downloadt nu niet langer de 1600px versie van dezelfde afbeelding. De loader handelt dit allemaal transparant af; de ontwikkelaar schrijft een gewone < Image > tag en de CDN doet de rest.

Maar formaatconversie is een apart probleem van levering. Een JPEG geleverd vanaf een snelle CDN is nog steeds een JPEG. Hero achtergronden en grote marketingafbeeldingen omzetten naar WebP vermindert de bestandsgrootte met 60% tot 80%. Onze homepage hero had een PNG van 1,3MB en we merkten het niet totdat Lighthouse het in vier opeenvolgende audits aanstipte. Die afbeelding zou ongeveer 200KB moeten zijn in WebP. Een CDN kan dat niet oplossen; alleen het bronbestand omzetten kan dat.

Een ander ding dat we lange tijd verkeerd deden: de priority functie in Next.js afbeeldingen. Het framework laadt afbeeldingen standaard lui; dit is het juiste gedrag voor afbeeldingen onderaan de pagina. Maar de Grootste Inhoudelijke Verf (meestal de hero afbeelding) mag nooit lui geladen worden. priority toevoegen vertelt Next.js om die afbeelding vooraf te laden en niet te behandelen als optionele inhoud. Slechts één eigenschap. De LCP verbetering is onmiddellijk en meetbaar.

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

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

Server-side gerenderd bij elke aanvraag, statisch gegenereerd bij build-time, statisch gegenereerd met periodieke revalidatie: dit zijn verschillende tools voor verschillende problemen en de verkeerde gebruiken kan leiden tot echte prestatieproblemen.

Onze productpagina's (server specificaties, prijsniveaus, functie documentatie) veranderen niet elke minuut. We gebruiken nu generateStaticParams met ISR en een herbevestigingsvenster van één uur. Bij build-time worden ze vooraf gerenderd als statische HTML voor elke taalcombinatie. Wanneer een gebruiker een productpagina bezoekt, wordt een gecached bestand van minder dan 100 ms geleverd vanaf de CDN edge. Geen server, geen database query, geen Node.js proces dat wakker wordt.

Pagina's die verse data vereisen (blog homepage, live prijsvergelijking, alles wat gebruikersspecifiek is) gebruiken dynamische rendering met korte revalidatievensters of caching op componentniveau. Het resultaat is dat het overgrote deel van ons verkeer wordt bediend vanuit statische HTML en de server doet alleen echt werk wanneer de inhoud daadwerkelijk verandert.

TTFB is nu consequent onder de 100 ms voor de meeste pagina's. In de oude Laravel setup kwam het zelden onder de 400 ms. Dit is geen magie van het framework; het is het resultaat van bewust beslissen welke rendering strategie logisch is voor elke pagina.

SEO gestructureerde gegevens, hreflang tags en OpenGraph metadata zijn onzichtbaar voor gebruikers maar essentieel voor alles en waren bijna afwezig toen we verhuisden. Optimaliseren voor Google's generatieve AI-functies vereist goed gestructureerde, crawlbare inhoud met de juiste schema markup.

We hebben FAQPage JSON-LD toegevoegd aan product- en functiepagina's. Voor onze tools gebruikten we het SoftwareApplication schema. We voegden BreadcrumbList toe voor de navigatiehiërarchie. In het hoofdlay-outbestand staat het Organization schema. Deze worden gelezen door zoekmachines en AI-systemen die beslissen of ze uw inhoud in gegenereerde samenvattingen en antwoordvakken tonen.

De hreflang situatie was nog ingewikkelder. We ondersteunen vier lokale talen en onze alternatieve links waren op zijn best inconsistent, op zijn slechtst afwezig. We hebben een gemeenschappelijke buildAlternates() functie gemaakt die de juiste hreflang tags genereert vanuit één route argument en op elke pagina werkt. Dit is het soort ding dat aanvoelt als huishoudelijk werk totdat je je realiseert dat onjuiste of ontbrekende hreflang tags actief schadelijk zijn voor je internationale zoekprestaties.

OpenGraph metadata was vergelijkbaar, aanwezig op sommige pagina's, afwezig op andere, met inconsistente afbeeldingsafmetingen. Dit centraliseren via de generateMetadata API van Next.js en metadataBase toevoegen aan de root layout stelde ons in staat om niet meer pagina-voor-pagina te denken, maar het overal standaard correct te doen.

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

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

Het is nog niet voorbij. Er zijn nog steeds afbeeldingen die WebP zouden moeten zijn maar dat niet zijn, pagina's die dynamisch worden gerenderd terwijl ze statisch zouden kunnen worden gegenereerd, en gestructureerde gegevens die specifieker zouden kunnen zijn. De lijst is korter dan voorheen, maar wordt nooit nul.

De eerlijke les uit dit alles is: prestaties zijn geen project dat je afmaakt, het is een set van standaarden die je opbouwt. Elke hero afbeelding heeft priority voordat de PR wordt samengevoegd. preconnect op de dag dat een nieuw extern domein wordt toegevoegd. Gestructureerde gegevens worden samen met de pagina-inhoud geschreven, niet achteraf toegevoegd. Imports worden gecontroleerd voordat ze bundelgewicht worden.

Wanneer deze gewoonten ingesleten raken, stop je met het besteden van sprints aan het corrigeren van cumulatieve beslissingen en begin je standaard snel te verzenden.

Als u meer gepersonaliseerd advies voor uw website wilt, sluit u dan aan bij onze gemeenschap.

Bekijk onze servers om snel en slim gebruik te maken van infrastructuur vanuit één paneel. Gratis functies zoals automatische back-ups en herstel, geplande gezondheidscontroles en onmiddellijke schaalvergroting helpen uw website beter te presteren. Bekijk hier.

::cta:altyapı::