Bundle-Größe: Die Diät für Ihr JavaScript

„Die Seite ist auf meinem MacBook Pro schnell.“ Das ist der gefährlichste Satz im Frontend-Engineering. Ihr MacBook Pro verfügt über einen M3 Max-Chip. Es analysiert 1 MB JavaScript in 50 ms. Ihr Benutzer hat ein Samsung Galaxy A15 für 200 US-Dollar. Es analysiert dasselbe 1 MB in 2,5 Sekunden. Während dieser 2,5 Sekunden ist der Hauptthread eingefroren. Der Benutzer klickt auf „In den Warenkorb“. Es passiert nichts. Sie gehen.

Im Jahr 2025 ist die Netzwerkgeschwindigkeit (4G/5G) selten der Engpass für den E-Commerce. CPU ist der Engpass. Und die Metrik, die dies verfolgt, ist Interaction to Next Paint (INP). Um INP zu beheben, müssen Sie die JavaScript-Nutzlast reduzieren.

Bei Maison Code Paris setzen wir strenge Budgets durch: <100 KB Initial Load.

Warum Maison Code darüber spricht

Bei Maison Code Paris fungieren wir als das architektonische Gewissen unserer Kunden. Wir übernehmen oft „moderne“ Stacks, die ohne grundlegendes Verständnis für Skalierung gebaut wurden.

Wir diskutieren dieses Thema, weil es einen kritischen Wendepunkt in der technischen Reife darstellt. Die korrekte Implementierung unterscheidet ein fragiles MVP von einer widerstandsfähigen Plattform auf Unternehmensniveau.

1. Die Kosten der Importe: Baumschütteln

Beim Tree Shaking (Dead Code Elimination) werden ungenutzte Exporte aus Ihrem Bundle entfernt. Aber es funktioniert nicht von Zauberhand. Sie müssen Code schreiben, der „Shakeable“ ist.

Die Fassfeilenfalle

Entwickler lieben „Barrel Files“ („index.ts“, das alles exportiert). Sie zerstören Tree Shaking.

Schlechtes Muster: „Typoskript // Komponenten/index.ts

• aus ’./Button’ exportieren; export * aus ’./Carousel’; // Riesige 50-KB-Komponente
• aus ’./Table’ exportieren;

// App.tsx import { Button } from ’./components’; „ In vielen Bundler-Konfigurationen (insbesondere bei älteren Webpacks) wird beim Importieren von „Button“ aufgrund von Einschränkungen bei der Erkennung von Nebenwirkungen auch „Carousel“ in das Bundle einbezogen.

Fix: Direkte Importe oder sorgfältige „sideEffects: false“-Konfiguration in „package.json“.

Die Bibliotheksfalle (Lodash)

import { map } from 'lodash'; ruft die gesamte 70-KB-Bibliothek ab. Verwenden Sie „lodash-es“ oder bestimmte Importe: „import map from ‚lodash/map‘;“. Noch besser: Verwenden Sie native Array-Methoden. [].map() kostet 0 Bytes.

2. Code-Splitting: Lazy Loading Routen

Warum den „Admin Dashboard“-Code an einen Kunden senden, der gerade ein Hemd kauft? Wir verwenden Routenbasiertes Code-Splitting.

In Next.js (App Router) geschieht dies automatisch für „page.tsx“-Dateien. Im Vite/React Router müssen Sie „lazy()“ verwenden.

„tsx import { lazy, Suspense } from ‘react’;

// Dieser dynamische Import erstellt einen separaten Chunk (z. B. Settings.chunk.js) const SettingsPage = lazy(() => import(’./pages/Settings’));

Funktion App() { zurück ( <Route path=”/” element={} /> <Route path=“/settings” element={ <Suspense fallback={}> } /> ); } „

Aufteilung auf Komponentenebene

Ist Ihr „3D Model Viewer“ schwer? Laden Sie es nicht beim Laden der Seite. Laden Sie es bei Interaktion.

„tsx const ModelViewer = Dynamic(() => import(’./ModelViewer’), { ssr: false });

Funktion ProductPage() { const [show3D, setShow3D] = useState(false);

zurück ( <> <button onClick={() => setShow3D(true)}>In 3D anzeigen {show3D && } </> ); } „ Das schwere JS wird nur heruntergeladen, wenn der Benutzer tatsächlich danach fragt.

3. Das Aufblähen visualisieren

Sie können nicht reparieren, was Sie nicht sehen können. Wir verwenden „@next/bundle-analyzer“ (oder „rollup-plugin-visualizer“). Führen Sie es vor jeder Bereitstellung aus.

Sie werden Schrecken finden:

• Three.js im Homepage-Bundle?
• Moment.js-Gebietsschemas? (Verwenden Sie die API „date-fns“ oder „Intl“).
• Faker.js in Produktion? (Es sollte eine DevDependency sein).

Normalerweise reduzieren wir die Bundle-Größe um 30 %, indem wir einfach nicht verwendete Abhängigkeiten löschen, die im Visualizer gefunden werden.

4. Skripte von Drittanbietern: Die „Partytown“-Lösung

Sie haben Ihren Anwendungscode auf 50 KB optimiert. Perfekt. Dann fügt das Marketingteam GTM (Google Tag Manager) hinzu. GTM injiziert:

• Facebook-Pixel (40 KB)
• TikTok-Pixel (50 KB)
• Hotjar (70 KB)
• Klaviyo (40 KB)
• Gorgias (200 KB)

Plötzlich wird Ihr Hauptthread durch 500 KB Marketingskripte blockiert. Die Lösung ist Off-Main-Thread-Architektur.

Wir nutzen Partytown. Es führt Skripts von Drittanbietern in einem Web Worker aus. Es leitet den DOM-Zugriff (z. B. „document.cookie“) vom Worker über synchrones XHR (Atomic Wait) an den Hauptthread weiter.

„tsx //layout.tsx (Next.js) import { Validation } from ’./Partytown’;

„ **Ergebnis**: Das Facebook-Pixel läuft in einem Hintergrundthread. Es berechnet Tracking-Daten, ohne dass Ihre Schaltfläche „In den Warenkorb“ einfriert. INP verbessert sich dramatisch.

5. Moderne Formate: Versand ohne Code

Polyfills sind veraltet

Unterstützen Sie Internet Explorer 11? Nein. Stoppen Sie den Versand von Polyfills für „Promise“, „Map“, „Set“, „fetch“. Setzen Sie Ihr „Browserliste“-Ziel auf „Standard, nicht IE 11“. Dadurch werden ca. 30 KB an Altmüll entfernt.

Brotli-Komprimierung

Gzip ist gut. Brotli ist besser. Brotli (br) komprimiert JavaScript ~20 % besser als Gzip. Stellen Sie sicher, dass in Ihrem CDN (CloudFront/Vercel) Brotli aktiviert ist.

6. Bildoptimierung: Die verborgene Nutzlast

JavaScript ist der CPU-Engpass, aber Bilder sind der Bandbreiten-Engpass. Wenn Sie ein 2 MB großes PNG über eine 4G-Verbindung laden, verzögert sich der JS-Download. Strategie:

1. Format: AVIF verwenden. Es ist 30 % kleiner als WebP.
2. Lazy Loading: „` für alles unterhalb der Falte.
3. Abmessungen: Legen Sie immer „Breite“ und „Höhe“ fest, um Layoutverschiebungen (CLS) zu verhindern.
4. CDN: Verwenden Sie Cloudinary oder Imgix, um die Größe im Handumdrehen zu ändern. image.jpg?w=400&q=auto

7. Strategie zum Laden von Schriftarten

Schriftarten blockieren das Rendern. Wenn Ihre OTF-Dateien 100 KB groß sind, ist der Text 2 Sekunden lang unsichtbar (FOIT). Fix:

1. Selbsthoster: Verwenden Sie keine Google Fonts. Die DNS-Suche erwischt Sie.
2. Teilmenge: Entfernen Sie Glyphen, die Sie nicht verwenden (z. B. kyrillische Zeichen).
3. Display Swap: font-display: swap;. Zeigen Sie sofort die Ersatzschriftart an.
4. Vorab laden: „` nur für die Schriftart „Überschrift“.

8. Die „Importkosten“ DX

Entwickler sind faul. Wenn sie eine Bibliothek importieren können, werden sie es tun. Installieren Sie die Erweiterung Import Cost in VS Code. Während der Eingabe wird die Größe des Imports inline angezeigt.

import { format } from 'date-fns'; // 14 KB (komprimiert) Diese sofortige Feedbackschleife lässt Entwickler zweimal überlegen, bevor sie eine Abhängigkeit hinzufügen.

8. Die Zukunft: Wiederaufnahmefähigkeit (Qwik)

Der grundlegende Fehler von React ist Hydratation. Hydration bedeutet: „Laden Sie den HTML-Code herunter. Laden Sie dann den JS herunter. Führen Sie dann den JS aus, um Ereignis-Listener anzuhängen.“ Es handelt sich um doppelte Arbeit. Frameworks wie Qwik führen Wiederaufnahmefähigkeit ein. Es gibt keine Flüssigkeitszufuhr. Der Ereignis-Listener wird in den HTML-Code serialisiert: „`. Der JS für den Click-Handler wird nur heruntergeladen, wenn der Benutzer tatsächlich klickt. Wenn sie nie klicken, laden Sie 0 KB JS herunter. Dies ist das „O(1)-JavaScript“-Ideal. Wir beobachten dies genau für 2026.

9. React Server Components (RSC)

Next.js App Router verwendet RSC. Mit RSC können Sie Abhängigkeiten vom Server aufrechterhalten. Vor RSC: import { format } from 'date-fns' -> Client-Bundle erhöht sich um 20 KB. Nach RSC: import { format } from 'date-fns' -> Läuft auf dem Server. Rendert HTML. Client-Bundle erhöht sich um 0 KB. Strategie: Verschieben Sie alle umfangreichen Formatierungen, Datenabrufe und Markdown-Verarbeitungen auf Serverkomponenten. Behalten Sie Client-Komponenten nur für Interaktivität bei (useState, useEffect). „Blattknoten“ sollten Client-Komponenten sein. „Containerknoten“ sollten Serverkomponenten sein.

9. Die 100-KB-Budgetregel

Wir haben eine strenge Regel: Sie können keine PR zusammenführen, die das ursprüngliche Bundle über 100 KB hinaus erweitert. Wir setzen dies per CI durch. Die Prüfung der Paketgröße schlägt fehl:

„Fehler: Das Hauptpaket ist 105 KB groß. Das Limit liegt bei 100 KB.“ Dies erzwingt ein Gespräch. „Brauchen wir diese Bibliothek wirklich? Können wir sie lazy laden?“ Wenn Sie es nicht erzwingen, wird das Paket unendlich wachsen. Jede KB muss um ihr Leben kämpfen.

10. Fazit

Leistung ist kein „nice to have“. Es handelt sich um Einnahmen. Amazon hat herausgefunden, dass 100 ms Latenz sie 1 % des Umsatzes kosten. Überhöhte JavaScript-IS-Latenz. Behandeln Sie Ihr Bundle-Size-Budget wie ein Finanzbudget. Wenn Sie diesen Wert überschreiten, müssen Sie ihn „zurückzahlen“, indem Sie den Code löschen.

---

Ist Ihre Website umfangreich?

Zeigt Ihr Lighthouse-Performance-Score „Nicht verwendetes JavaScript reduzieren“ an?

Mein Paket prüfen. Lesen Sie mehr über Core Web Vitals und Edge Computing.

Leistung ist kein „nice to have“. Es handelt sich um Einnahmen. Amazon hat herausgefunden, dass 100 ms Latenz sie 1 % des Umsatzes kosten. Überhöhte JavaScript-IS-Latenz. Behandeln Sie Ihr Bundle-Size-Budget wie ein Finanzbudget. Wenn Sie diesen Wert überschreiten, müssen Sie ihn „zurückzahlen“, indem Sie den Code löschen.

Ist Ihre Website umfangreich?

Zeigt Ihr Lighthouse-Performance-Score „Nicht verwendetes JavaScript reduzieren“ an?

Mein Paket prüfen. Beauftragen Sie unsere Architekten.