Worden uw bestanden efficiënt afgeleverd?

Overdrachtsgrootte is één belangrijk deel van de prestaties: overbodige bytes schrappen helpt, het zichtbaarst op trage verbindingen – terwijl latentie, de reactietijd van de server, kettingen van verzoeken en rekenwerk in de browser er net zo veel toe kunnen doen. Uw assets (de bestanden van uw website) efficiënt afleveren – kleinere bestanden, gecomprimeerd onderweg, gecachet dicht bij de bezoeker – blijft een van de goedkoopste winsten die er zijn, zolang u weet wat het wel en niet oplevert.

Eerst opschonen, dan minificeren

Minificeren gebruikt syntaxisbewuste tools om de veilige delen van een bestand te strippen of te herschrijven – onnodige witruimte, de meeste opmerkingen en in JavaScript sommige lokale namen – met als doel het gedrag te behouden. Het is een mechanische laatste stap; rommel minificeren levert nog steeds rommel op, dus ruim eerst op:

• Verwijder CSS-regels, scripts en dode opmaak waarvan tests aantonen dat ze ongebruikt zijn – coverage-tools (die meten welke code echt gebruikt wordt) leveren het bewijs, maar controleer dynamische sjablonen, plug-in-hooks en zeldzame gebruikersroutes vóór u schrapt, en test daarna formulieren, toetsenbordgebruik en responsieve lay-outs. „Ziet er ongebruikt uit” en „is ongebruikt” zijn twee verschillende dingen.
• Gooi trackingfragmenten weg van diensten die u echt niet meer gebruikt.
• Waar een bibliotheek maar één kleine functie levert, vergelijk haar kosten met een paar regels eigen code – maar houd de bibliotheek als ze gewicht draagt op het vlak van toegankelijkheid, compatibiliteit of beveiliging dat u zelf slechter zou nabouwen.

Minificeer daarna met een tool, zodat het herhaalbaar en omkeerbaar blijft: bewaar een leesbare broncode en genereer een geminificeerde build (esbuild, Terser of Lightning CSS; de meeste bundlers doen het automatisch), met behoud van verplichte licentieopmerkingen. Minificeer nooit met de hand. En weeg moeite tegen opbrengst af – op een piepkleine website is een paar KB CSS besparen misschien geen build-pijplijn waard.

Comprimeer en gebruik moderne HTTP

Schakel Gzip of Brotli in voor comprimeerbare tekstantwoorden – dit Apache-voorbeeld met mod_deflate schakelt Gzip in; Brotli heeft een eigen module en configuratie nodig:

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/css application/javascript text/javascript image/svg+xml
</IfModule>

Laat de leveringslaag de codering onderhandelen, controleer Content-Encoding op het openbare antwoord, en comprimeer al gecomprimeerde formaten (JPEG, PNG, WebP, archieven) niet opnieuw. Lever via HTTP/2 of HTTP/3 waar beschikbaar – hun multiplexing schaft de wachtrij per verbinding van HTTP/1.1 af, al blijven bandbreedte, prioritering en serverwerk gewoon gelden – en controleer het protocol op de openbare URL, want een proxy kan met uw eigen server een ander protocol spreken. Stel caching-headers in zodat terugkerende bezoekers ongewijzigde bestanden hergebruiken, en geef geschikte externe scripts defer mee zodat ze het inlezen van de HTML niet blokkeren – en houd ook hun uitvoering licht, want defer stelt het werk uit, het maakt het niet kleiner.

Breng bytes dichterbij met een CDN

Compressie pakt de grootte aan; een CDN (een netwerk van servers verspreid over de wereld) pakt de afstand aan. Een CDN cachet geschikte bestanden op verspreide locaties en stuurt elke bezoeker naar een geschikte – vaak echte latentiewinst voor een ver publiek, waarbij cache-hits uw eigen server ontlasten. De werkelijke winst hangt af van de routering, het cache-hitpercentage en de snelheid van uw eigen server.

Het overwegen waard wanneer bezoekers geografisch verspreid zijn, de belasting van uw server reëel is of u de veerkrachtfuncties nodig hebt – en de volledige afweging, inclusief privacy, TLS naar uw eigen server en de DNS-verhuizing, heeft een eigen gids: een proxy-CDN ziet de verzoeken van uw bezoekers (een beslissing over gegevensverwerking), heeft ook een versleutelde en geverifieerde verbinding naar uw server nodig, en een DNS-verhuizing moet alle bestaande records meenemen, e-mailrecords inbegrepen. Controleer wat er echt gecachet wordt – proxyen is geen cachen – en begin met statische bestanden met versienamen; cache HTML alleen waar die openbaar en voor iedereen identiek is. Voor de bestanden met versienamen mag u agressief cachen:

Cache-Control: public, max-age=31536000, immutable

Alleen voor openbare bestanden waarvan de naam mee verandert met de inhoud. Pas dit nooit overal toe – op HTML, winkelwagens, account- of beheerderspagina’s kan public ertoe leiden dat een gedeelde cache de pagina van de ene bezoeker aan een andere serveert, en immutable op een bestand zonder versienaam maakt correcties bijna onbezorgbaar. HTML blijft kort gecachet of wordt opnieuw gecontroleerd, zodat nieuwe bestandsverwijzingen de bezoekers bereiken.

Verstuur minder, verstuur het gecomprimeerd en serveer het dicht bij de bezoeker – dat is efficiënte levering.

Wat u moet doen

1. Verwijder ongebruikte CSS, JS en dode opmaak op basis van coverage-bewijs, test het resultaat en voeg dan een minificatiestap aan de build toe.
2. Zet Gzip of Brotli aan voor tekstantwoorden en controleer de openbare Content-Encoding.
3. Lever HTTP/2/3 (gecontroleerd op de openbare URL) en geef statische bestanden met versienamen een lange cachetijd – alleen die.
4. Geef geschikte externe scripts defer mee en houd hun uitvoering goedkoop; voeg piepkleine bestanden samen waar dat zinvol is.
5. Overweeg een CDN bij een verspreid publiek of echte serverbelasting – gemeten, en met het huiswerk rond privacy en TLS gedaan; sla het over waar een nabije eigen server al goed levert.
6. Meet de laadtijd vóór en na, zodat u de winst kunt zien.