Websites herunterladen, die Firebase nutzen

Über Firebase

Eine Erkennung von Firebase sagt für einen Eintrag in der Kategorie Databases etwas Ungewöhnliches aus, denn sie bedeutet, dass die Website ein laufendes Backend hat. Der Anbieter Google LLC verkauft Authentifizierung, eine Dokumentendatenbank, Cloud-Funktionen, Dateispeicher und Analytics als ein Paket, das aus clientseitigem JavaScript erreichbar ist, sodass eine Seite Nutzerkonten führen und Daten in Echtzeit synchronisieren kann, ohne dass jemand einen Server aufsetzt. Die Erkennung ist direkt und nicht abgeleitet, denn das SDK wird an den Browser ausgeliefert, und sein Konfigurationsobjekt steht samt Projektkennung in der Seite.

Stand Oktober 2026 erfassen wir die Plattform auf 151.582 Websites. Der Bestand ist kein zufälliger Ausschnitt des Webs. Für Firebase entscheiden sich Entwickler, die eine Anwendung ausliefern wollen, ohne Infrastruktur zu betreiben. Auf der Liste finden sich deshalb überdurchschnittlich viele Produkt-Startups, Begleit-Websites zu Mobile-Apps, interne Tools und Agenturen, die interaktive Frontends bauen, und vergleichsweise wenige Visitenkarten-Websites und Publisher, weil diese mit einer Echtzeitdatenbank nichts anfangen können. Für die kommerzielle Recherche ergibt sich daraus eher ein Teamprofil als ein Unternehmensprofil, denn eine Website auf dieser Plattform hat meist ein kleines Entwicklerteam, kein eigenes Betriebspersonal und eine feste Vorliebe dafür, verwaltete Dienste einzukaufen, statt sie selbst zu betreiben, was in wenigen Worten den Käufer der meisten heute verkauften Entwickler-Tools beschreibt.

An den Versionsdaten wird der Eintrag interessant. Auf den Websites, bei denen wir eine Build-Kennung auslesen können, haben wir 384 verschiedene Releases des SDK im Einsatz gesehen, am häufigsten derzeit Version 9.0.0. Eine breite Versionsstreuung bei einer Bibliothek, die ein einziger Anbieter veröffentlicht, verrät, wie sie ausgeliefert wird: beim Build fest in ein Bundle eingebunden und dann vergessen, statt von einem Endpunkt geladen, der sich laufend selbst aktualisiert. Die Websites liefern weiter das Release aus, mit dem sie gebaut wurden, und die modulare Neufassung, die den Import-Stil veränderte, hat die installierte Basis in zwei Epochen geteilt, die in freier Wildbahn bis heute nebeneinander bestehen.

Die geografische Verteilung ist so stark konzentriert, dass es für jeden ins Gewicht fällt, der einen Markt beziffern will. Von 151.582 Websites insgesamt verorten wir 133.607 in den USA, und bei den Endungen führt .com. Die Konzentration ist teils real, weil der Schwerpunkt der Plattform im amerikanischen Startup-Ökosystem liegt, und teils ein Artefakt davon, wo weltweit tätige Unternehmen ihre Domain registrieren lassen, sodass man die Länderzahl eher als Eigenschaft der Domain lesen sollte denn als Beleg dafür, wo sich die Nutzer befinden.

Die Vorbehalte sind konkret. Firebase Hosting kann eine Website ausliefern, deren Autor die Datenbank nie anrührt, und das SDK kann auf einer Seite eingebunden sein, die nur Analytics aufruft. Eine Erkennung beweist also, dass die Plattform angebunden ist, aber nicht, welche ihrer Produkte die Hauptlast tragen. Bundler, die umbenennen und per Tree Shaking kürzen, können den Fingerprint verbergen, was die Zahl zu einer Untergrenze statt zu einer Vollerhebung macht. Außerdem kann ein Projekt auf serverseitige Aufrufe umsteigen, während alte Marketingseiten das Skript weiter laden, was veraltete Treffer erzeugt.

Genau aus diesen Gründen ist der Blick auf den gesamten Bestand mehr wert als eine Einzelabfrage. Die Prüfung einer Domain bestätigt, ob diese Domain das SDK lädt. Ein Export liefert, was eine Einzelabfrage nicht erreicht: wie groß die installierte Basis ist, wie sie sich auf die beobachteten Builds verteilt, in welchen Ländern und Endungen sie sich konzentriert, welche Zahlungs-, Analytics- und Framework-Entscheidungen mit ihr einhergehen und ob der Bestand zwischen einer Aktualisierung und der nächsten wächst oder zu konkurrierenden Backends abwandert.