Warum immonika.de so schnell lädt

Warum Performance zählt

Google bewertet die Ladezeit einer Seite als Ranking-Faktor. Aber wichtiger noch: Nutzer erwarten, dass eine Seite in unter zwei Sekunden vollständig geladen ist. Bei Immobilienportalen mit vielen Bildern und Kartenansichten ist das oft eine echte Herausforderung.

Wir haben uns entschieden, keine Kompromisse einzugehen. Jede Seite auf immonika.de soll so schnell laden, als käme sie aus dem lokalen Cache – auch beim ersten Besuch.

Statische Seitengenerierung

Anders als viele Portale, die Seiten bei jedem Aufruf dynamisch aus einer Datenbank zusammenbauen, generiert immonika.de die wichtigsten Seiten im Voraus als fertige HTML-Dateien.

Das bedeutet: Der Webserver muss bei einem Seitenaufruf oft keine Datenbank mehr befragen, kein Template rendern und keinen Application-Server mehr kontaktieren. Er liefert einfach eine fertige bereits zuvor gecachte Datei aus. Das ist so schnell, wie es nur geht.

Damit können wir mehr als 50% der sonst üblichen Ladezeit sparen und schonen gleichzeitig noch die Unterhaltskosten sowie die Umwelt durch den geringeren Energieverbrauch.

CSS-Splitting: Critical Path zuerst

CSS blockiert das Rendering einer Seite. Solange der Browser das Stylesheet nicht geladen hat, sieht der Nutzer nichts. Deshalb teilen wir unser CSS in zwei Dateien:

• prio.css – Enthält nur die Styles, die für den sichtbaren Bereich beim ersten Laden benötigt werden (Above-the-Fold). Diese Datei wird synchron geladen und ist bewusst klein gehalten.
• style.css – Enthält alle weiteren Styles. Diese Datei wird asynchron nachgeladen, sodass sie das initiale Rendering nicht blockiert.

Der Trick dabei: Die Haupt-CSS-Datei wird mit media="print" geladen und erst nach dem Laden auf media="all" umgeschaltet. So behandelt der Browser sie als nicht-blockierend, wendet die Styles aber sofort an, sobald sie verfügbar sind.

Font-Strategie ohne externe Requests

Viele Webseiten laden Schriftarten von Google Fonts – ein externer Request, der nicht nur die Ladezeit erhöht, sondern auch datenschutzrechtlich problematisch ist. Bei immonika.de hosten wir alle Fonts selbst.

Wir verwenden die Schriftfamilie Source Sans 3 im modernen WOFF2-Format. Die Schriftdateien werden per <link rel="preload"> vorab geladen, noch bevor der Browser sie im CSS entdeckt. Das verhindert den gefürchteten Flash of Unstyled Text (FOUT) und sorgt dafür, dass Text sofort in der richtigen Schrift erscheint.

Nur die tatsächlich benötigten Schriftschnitte (Regular und Bold, jeweils mit Italic-Variante) werden geladen – kein unnötiger Ballast durch Dutzende Schriftgewichte.

Bildoptimierung bei Exposees

Immobilienbilder sind der größte Posten beim Seitengewicht. Ein einzelnes hochauflösendes Foto kann mehrere Megabyte groß sein. Unsere Strategie:

• Serverseitige Komprimierung – Beim Import werden alle Bilder automatisch auf eine web-optimierte Größe skaliert und komprimiert
• Lazy Loading – Bilder unterhalb des sichtbaren Bereichs werden erst geladen, wenn der Nutzer zu ihnen scrollt
• Dimensionsangaben – Jedes Bild hat explizite Breiten- und Höhenangaben im HTML, um Layout-Shifts beim Laden zu vermeiden

So bleibt die initiale Ladezeit kurz, auch wenn ein Exposee zwanzig oder mehr Bilder enthält.

Karten ohne Cloud-Dienste

Kartenansichten sind auf Immobilienportalen unverzichtbar. Die meisten Portale nutzen dafür Google Maps oder ähnliche Cloud-Dienste – mit allen Konsequenzen für Datenschutz und Ladezeit.

immonika.de setzt auf MapLibre GL JS mit selbst gehosteten Vektor-Kacheln. Die Kartendaten liegen auf unserem eigenen Server, die Rendering-Engine läuft komplett im Browser des Nutzers. Kein externer Request, keine Tracking-Cookies, keine Abhängigkeit von einem Cloud-Anbieter.

Die Kacheln und Glyphen werden per <link rel="preload"> vorab geladen, sodass die Karte beim Scrollen sofort sichtbar ist. Der Kartenstil wird als lokale JSON-Datei ausgeliefert – auch hier kein externer Request.

Fazit

Performance ist keine einmalige Optimierung, sondern eine Grundhaltung. Bei immonika.de fließt sie in jede Entscheidung ein – von der Architektur über die Font-Auswahl bis zur Kartenintegration.

Das Ergebnis: Seiten, die in Bruchteilen einer Sekunde laden. Ohne Kompromisse beim Funktionsumfang und ohne externe Abhängigkeiten. Weil schnelle Seiten bessere Seiten sind – für unsere Makler und ihre Interessenten.