Akzeptable Lasten für Webseiten
Datum
🧭 1. Richtwerte für Übertragungsvolumen
💻 WLAN / Desktop-Nutzer (Deutschland)
-
Durchschnittliche Breitbandverbindung: 50–100 Mbit/s
→ also theoretisch 6–12 MB/s. -
Praktisch sind 1–3 MB pro Seite (also HTML + CSS + JS + Medien) kein Problem.
-
Wenn deine Seite künstlerisch ist (große Bilder, Videos), kann sie bis 10 MB haben, wenn sie sich schnell aufbaut (Lazy Loading etc.).
📱 Mobile Nutzer
-
Viele sind noch auf LTE oder 5G, aber nicht immer stabil.
-
Zielgröße: unter 2 MB pro Seite, ideal 1 MB oder weniger für Hauptinhalte.
-
Große Medien (Video, Galerie etc.) sollten on demand nachgeladen oder als Vorschau-Bilder (Posterframes, Thumbnails) eingebunden werden.
🎞️ 2. Vergleich der Medientypen – Last und Verhalten
| Medium | Datenlast | Läuft als Loop? | Caching | Bemerkung |
|---|---|---|---|---|
| GIF-Animation | Hoch (ineffizient) | Ja, endlos | schwach | Nicht mehr zeitgemäß. Kein Kompressionsvorteil. 2 s können schnell >1 MB sein. |
| APNG (Animated PNG) | Mittel | Ja | gut | Bessere Qualität als GIF, aber nicht überall ideal unterstützt. |
| SVG-SMIL / CSS / JS-Animation | Sehr gering | Ja | gut | Ideal für Logos, Vektoren, Text. Läuft flüssig und ist verdammt leichtgewichtig, meist < 100 KB. |
| MP4 (H.264) | Mittel–hoch | Ja | sehr gut | Optimale Allround-Lösung für Bewegtbild. 720p mit 1 Mbit/s ist top für Web. |
| WebM (VP9/AV1) | gering–mittel | Ja | sehr gut | Moderne, effizientere Alternative zu MP4, aber Safari-Unterstützung eingeschränkt. |
| Sozi / SVG-Präsentation | sehr gering | abhängig von Interaktion | gut | Text + Vektoren = sehr leicht. Nur bei eingebetteten Bildern steigt die Last. |
| Canvas/WebGL | variabel | Echtzeitberechnung | nicht direkt | Eher für interaktive Experimente, kann aber GPU-lastig werden. |
🌀 3. Lastverhalten bei Loops
🎞️ MP4/WebM
→ Lädt einmal (Browser cached), dann läuft endlos aus Cache.
💡 Kein dauerhafter Netzwerkstrom – es sei denn, preload=„none“ gesetzt oder Cache deaktiviert.
🖼️ GIF / APNG
→ Wird ständig neu decodiert, aber nicht neu geladen.
💡 Last auf CPU/GPU, nicht auf Netzwerk.
⚠️ Nachteil: hoher Speicherverbrauch, ineffiziente Kompression.
🕹️ SVG-SMIL / CSS / JS
→ Vektorbasiert, extrem klein.
💡 Die Animation wird lokal berechnet. Kein neuer Download.
⚙️ Gut, solange du keine eingebetteten Bitmap-Bilder einfügst.
🪄 Sozi-Animationen
→ Technisch gesehen: SVG + JS-Transformationen.
💡 Datenlast gering, aber CPU-lastig bei komplexen Zoom-/Pan-Szenen oder eingebetteten Bildern.
📉 Bei eingebetteten PNGs/JPGs hängt es stark von der Bildgröße ab — 5 MB SVG mit eingebetteten JPGs ist keine Seltenheit.
⚖️ 4. Strategien für deine Seite
-
YouTube-Videos → immer über iframe
→ keine Last auf deinem Server, adaptive Streaming übernimmt YouTube. -
Sozi-Animationen → einzeln laden, nicht alle parallel
→ evtl. mitloading=„lazy“oder Klick-Trigger. -
SVG-Animationen → bevorzugen, wenn stilistisch passt
→ SMIL oder CSS reicht völlig, und du behältst Kontrolle über Farbe & Rhythmus. -
GIF → vermeiden, stattdessen:
-
MP4 (mit Autoplay+Loop+Muted)
-
oder Lottie/Bodymovin (JSON-basiert, ultraleicht)
-
-
Bilder optimieren
-
WebP oder AVIF, 1200 px Breite ≈ 150–300 KB
-
Lazy Loading aktivieren
-
💡 Bonus: Dateigrößen, an denen du dich orientieren kannst
| Medium | Zielgröße | Bemerkung |
|---|---|---|
| Einzelbild | 150–300 KB | für 1200 px Breite |
| Kurze SVG-Animation | < 150 KB | perfekt |
| 5 s MP4-Loop | 400–800 KB | sehr gut |
| 20 s MP4-Clip | 1–2 MB | akzeptabel |
| YouTube-Video | – | ausgelagert, ideal |
| Sozi-Animation | 0.2–2 MB | abhängig von eingebetteten Bildern |
← Älter Neuer →
