Wie lässt sich die Performance-Einbuße durch die hohe Dateigröße des Foundation-Frameworks minimieren?

Melden

Das Foundation-Framework von Zurb ist mächtig, aber in der Standardausführung tatsächlich sehr schwerfällig (große Dateigröße). Um die Performance-Einbußen zu minimieren, gibt es mehrere bewährte Strategien, die von der Art der Einbindung bis zur automatisierten Nachbearbeitung reichen.

Hier sind die effektivsten Methoden:

1. Selektiver Import via Sass (Wichtigster Schritt)

Anstatt die vorab kompilierte foundation.min.css zu verwenden, solltest du Foundation über Sass einbinden. So kannst du gezielt nur die Komponenten laden, die du wirklich benötigst.

  • Vorgehensweise: In deiner Haupt-Sass-Datei kommentierst du die Komponenten aus, die du nicht nutzt (z. B. Slider, Progress-Bars oder spezielle Button-Typen).

  • Beispiel:

    // In deiner app.scss
@import 'foundation';

@include foundation-global-styles;
@include foundation-grid;
@include foundation-typography;
@include foundation-button;
// @include foundation-orbit; <-- Weglassen, wenn kein Slider genutzt wird

2. PurgeCSS verwenden

PurgeCSS ist ein Tool, das deinen HTML-Code (und ggf. JavaScript) scannt und alle CSS-Regeln aus dem Framework entfernt, die im Projekt nicht vorkommen. Dies ist oft die effektivste Methode, um die Dateigröße um bis zu 90 % zu reduzieren.

  • Integration: Es lässt sich in Build-Tools wie Webpack, Vite, Gulp oder via PostCSS einbinden.
  • Ergebnis: Eine massive Reduktion, da Frameworks wie Foundation viele Klassen für Sonderfälle mitliefern.

3. Modulares JavaScript

Ähnlich wie beim CSS solltest du auch beim JavaScript nicht das gesamte foundation.js-Paket laden.

  • Vorgehensweise: Nutze ES6-Imports, um nur die benötigten Plugins zu laden.

  • Beispiel:

    import { Foundation } from 'foundation-sites/js/foundation.core';
import { Tabs } from 'foundation-sites/js/foundation.tabs';

Foundation.plugin(Tabs, 'Tabs');

    Dadurch können moderne Bundler wie Webpack oder Rollup "Tree Shaking" betreiben und ungenutzten Code beim Build entfernen.

4. Critical CSS Strategie

Um die gefühlte Ladezeit (First Contentful Paint) zu verbessern, solltest du "Critical CSS" einsetzen.

  • Konzept: Trenne das CSS, das für den Bereich "Above the Fold" (sichtbarer Bereich ohne Scrollen) nötig ist, vom Rest.
  • Umsetzung: Das kritische CSS wird inline im <head> platziert, während die große Foundation-Datei asynchron (z.B. mit rel="preload" oder am Ende des Bodys) geladen wird.

5. Kompression: Brotli oder Gzip

Stelle sicher, dass dein Webserver (Nginx, Apache) die Dateien komprimiert ausliefert.

  • Brotli: Bietet eine deutlich bessere Kompressionsrate als Gzip (oft 20-30 % kleiner). Foundation-Dateien profitieren aufgrund der vielen Text-Wiederholungen extrem davon.

6. CDN mit HTTP/2 nutzen

Wenn du Foundation nicht selbst hosten willst, nutze ein CDN.

  • Vorteil: CDNs nutzen HTTP/2 (oder HTTP/3), was das gleichzeitige Laden von Ressourcen beschleunigt. Zudem haben Nutzer die Datei eventuell schon von einer anderen Website im Browser-Cache.
  • Nachteil: Du kannst hier kein Tree Shaking oder PurgeCSS anwenden. Daher ist die Sass-Methode (Punkt 1) für maximale Performance meist überlegen.

7. Umstieg auf das XY-Grid (statt Float-Grid)

Falls du noch eine ältere Version oder das alte Float-Grid nutzt: Das modernere XY-Grid von Foundation ist flexibler und oft effizienter. Achte beim Kompilieren darauf, nur ein Grid-System zu aktivieren, nicht beide gleichzeitig.

Zusammenfassung der Best Practice:

Der "Königsweg" sieht heute so aus:

  1. Sass-Imports nutzen, um Grobauswahl zu treffen.
  2. PurgeCSS im Produktions-Build drüberlaufen lassen (entfernt den Rest).
  3. JavaScript modular einbinden.
  4. Datei mit Brotli komprimieren.

Mit diesen Schritten lässt sich die CSS-Last von Foundation oft von über 100 KB auf unter 15-20 KB (gzipped) reduzieren.

0