Offline-Modus für Webanwendungen: Außendienst ohne Netz

Eine Webanwendung kann auch dort funktionieren, wo es kein Netz gibt – im Keller, auf der Baustelle, im Lager oder auf dem Land. Voraussetzung ist, dass der Offline-Modus als Teil des Arbeitsprozesses geplant wird und nicht als Zusatz kurz vor dem Start. Technisch besteht er aus einem Service Worker, der die Anwendung auf dem Gerät speichert, einer lokalen Datenbank im Browser für Datensätze in Bearbeitung und einer Warteschlange ausgehender Änderungen, die die Anwendung nach der Rückkehr der Verbindung an den Server sendet.

Über den Erfolg entscheiden jedoch die Regeln: welche Daten die Mitarbeitenden im Außendienst dabeihaben, was ohne Server erledigt werden darf, wie lange nicht gesendete Datensätze auf dem Telefon bleiben dürfen und was passiert, wenn das Büro denselben Datensatz zwischenzeitlich ändert. Der Artikel richtet sich an Inhaber und Führungskräfte, die eine Anwendung für Servicetechniker, Vor-Ort-Besichtigungen, Inventuren oder Prüfungen planen und überlegen, wie ein Offline-Modus für Webanwendungen aussehen sollte.

Beispiel: Kesselprüfungen in Kellern ohne Empfang

Illustratives Beispiel, das Unternehmen ist fiktiv. Ein Serviceunternehmen prüft Gasheizkessel, oft in Heizräumen und Kellern ohne Mobilfunkempfang. Der Techniker notiert die Befunde heute auf Papier, tippt sie abends ins System ab und schickt Fotos über einen privaten Messenger.

Zielzustand: Morgens lädt die Anwendung im Firmen-WLAN den Tagesplan, die Adressen, die Gerätehistorie und die Protokollformulare herunter. Vor Ort füllt der Techniker das Protokoll aus, hängt Fotos an, und der Kunde unterschreibt auf dem Display. Der Datensatz wird mit dem Status „Wartet auf Senden“ auf dem Telefon gespeichert. Sobald der Empfang zurück ist, sendet die Anwendung ihn, der Server bestätigt den Eingang, und der Status wechselt auf „Gesendet“. Hat das Büro den Auftrag zwischenzeitlich storniert, sieht der Techniker einen Konflikt zur Klärung und kein stilles Überschreiben seiner Arbeit.

Was der Offline-Modus können muss – und was nicht

Die erste Entscheidung ist keine technische. Legen Sie für jede Aufgabe fest, ob sie vollständig offline, als Entwurf mit Bestätigung durch den Server oder nur online erledigt wird. Alles, was einen einzigen verbindlichen Stand braucht – Rechnungsnummernkreise, Lagerbestand, Preise –, bleibt auf dem Server.

Aufgabe	Offline	Warum
Tagesplan und Gerätehistorie anzeigen	Ja, aus vorab geladenen Daten	Der Techniker braucht den Kontext auch ohne Empfang
Protokoll ausfüllen, Fotos und Unterschrift anhängen	Ja, lokal gespeichert und später gesendet	Der Hauptgrund für den Offline-Modus
Neuen Auftrag vor Ort anlegen	Ja, als Entwurf mit vorläufiger Kennung	Die Auftragsnummer vergibt erst der Server
Rechnung ausstellen oder Ware reservieren	Nein, nur Unterlagen vorbereiten	Nummernkreise und Lagerbestand steuert der Server
Preisliste oder Berechtigungen ändern	Nein	Diese Daten sollen eine einzige verlässliche Quelle haben

Jedes „Ja“ in der Tabelle bedeutet zusätzliche Entwicklung und zusätzliche Tests. In den Offline-Modus gehören daher nur Aufgaben, die tatsächlich ohne Empfang erledigt werden.

Technische Bausteine und ihre Grenzen

Service Worker und die gespeicherte Anwendung

Ein Service Worker ist ein Skript, das in einem eigenen Thread läuft. Bei der Installation kann er Seiten, Stylesheets, Skripte und Bilder der Anwendung in einem lokalen Cache speichern und anschließend ihre Anfragen abfangen – entweder zuerst aus dem Cache oder zuerst aus dem Netz mit dem Cache als Rückfallebene. Laut dem MDN-Leitfaden zum Offline- und Hintergrundbetrieb hängt die passende Strategie von der jeweiligen Anwendung ab. Für eine Außendienstanwendung empfehlen wir, die Benutzeroberfläche selbst mit klarer Versionierung aus dem Cache auszuliefern und die Auftragsdaten in einer lokalen Datenbank zu halten, die die Anwendung bei jeder Verbindung vom Server aktualisiert.

Lokale Datenbank: IndexedDB statt localStorage

localStorage speichert nur Schlüssel-Wert-Paare als Zeichenketten und ist laut der MDN-Dokumentation zu Speicherkontingenten auf 5 MiB pro Ursprung (Origin) begrenzt. Für Fotos und eine Änderungswarteschlange reicht das nicht. Für größere strukturierte Daten ist IndexedDB gedacht, für Dateien das ursprungsprivate Dateisystem (OPFS).

Kontingente und Löschung des Speichers

Daten werden standardmäßig im „Best-Effort“-Modus gespeichert, also ohne Garantie auf Dauerhaftigkeit: Sie bleiben erhalten, solange der Ursprung unter seinem Kontingent liegt, auf dem Gerät genug Platz ist und der Nutzer sie nicht löscht. Wird der Platz knapp, löscht der Browser die Daten der am längsten nicht genutzten Ursprünge – immer alle Daten eines Ursprungs auf einmal, nie nur einen Teil (MDN).

Die Kontingente sind hoch, aber keine Garantie. Chromium-basierte Browser erlauben einem Ursprung bis zu 60 % der gesamten Speicherkapazität, Firefox im Best-Effort-Modus den kleineren Wert von 10 % des Speichers oder 10 GiB und Safari ab Version 17 etwa 60 % des Speichers (MDN). Berechnet wird jedoch die Gesamtkapazität, nicht der freie Platz, und laut dem WebKit-Blogbeitrag zur Speicherrichtlinie handelt es sich um eine Obergrenze ohne Garantie. Die Anwendung muss daher den Fehler QuotaExceededError behandeln.

Safari löscht zudem bei aktiviertem Schutz vor websiteübergreifendem Tracking per Skript erzeugte Daten, wenn der Nutzer in den letzten sieben Tagen der Browsernutzung nicht mit der Website interagiert hat. Vor der Löschung bei Platzmangel schützt dauerhafter (persistenter) Speicher, den die Anwendung über navigator.storage.persist() anfordert. Firefox fragt den Nutzer, Safari und die meisten Chromium-basierten Browser entscheiden automatisch anhand der bisherigen Interaktion, und WebKit berücksichtigt auch, ob die Website vom Home-Bildschirm gestartet wird. Laut einer Untersuchung des Chrome-Teams, auf die MDN verweist, löschen Browser die Daten regelmäßig besuchter Websites nur sehr selten. Betrachten Sie das Telefon trotzdem als Zwischenspeicher und nicht als Ort, an dem Unternehmensdaten verbleiben sollen.

Verbindungsstatus und Hintergrundsynchronisierung

Die Eigenschaft navigator.onLine ist nicht zuverlässig: Eine Verbindung mit einem lokalen Netzwerk gilt in der Regel als online, auch wenn dieses Netzwerk keinen Internetzugang hat. MDN rät daher, auf dieser Grundlage keine Funktionen zu deaktivieren, sondern nur darauf hinzuweisen, dass der Nutzer möglicherweise offline ist. Betrachten Sie einen Datensatz erst dann als gesendet, wenn der Server den Eingang bestätigt hat.

Mit der Background Synchronization API lässt sich das Senden an den Service Worker übergeben und aufschieben, bis eine stabile Verbindung besteht. MDN kennzeichnet sie jedoch als eingeschränkt verfügbar, und sie funktioniert nur in einem sicheren Kontext (HTTPS). Die Anfrage kann nur bei geöffneter Anwendung registriert werden, der Browser kann den Versuch nur begrenzt oft wiederholen und bricht zu lange Vorgänge ab, wobei der nächste Versuch von vorn beginnt (MDN). Die Hintergrundsynchronisierung ist also nur eine Zugabe. Die Grundlage sollte das Senden beim Öffnen der Anwendung, nach Wiederherstellung der Verbindung und über eine Schaltfläche „Jetzt senden“ sein – in kleinen Paketen, die sich gefahrlos wiederholen lassen.

Einführung in sieben Schritten

Erfassen Sie die Arbeit im Außendienst. Klären Sie, wo und wie lange Mitarbeitende keinen Empfang haben, welche Geräte sie nutzen (firmeneigene oder private, iPhone oder Android) und wie viele Datensätze und Fotos täglich entstehen.
Legen Sie den Offline-Umfang fest. Entscheiden Sie für jede Aufgabe anhand der Tabelle: vollständig offline, Entwurf zur Bestätigung oder nur online.
Bereiten Sie das Datenmodell vor. Jeder Datensatz erhält schon auf dem Gerät eine eindeutige Kennung (zum Beispiel eine UUID), eine Version und einen Synchronisierungsstatus. Der Server muss ein wiederholtes Senden erkennen und darf kein Duplikat anlegen.
Bauen Sie die ausgehende Warteschlange. Eine Änderung wird zuerst in die lokale Datenbank und die Warteschlange geschrieben und erst danach gesendet – in der Reihenfolge ihrer Entstehung, in Paketen und mit Wiederholungen. Fotos werden erst hochgeladen, wenn der Server den eigentlichen Datensatz angenommen hat.
Kümmern Sie sich um den Speicher. Fordern Sie dauerhaften Speicher an, überwachen Sie die geschätzte Nutzung über navigator.storage.estimate(), verkleinern Sie Fotos vor dem Speichern auf die Auflösung, die der Prozess wirklich braucht, und löschen Sie lokale Kopien nach der Bestätigung durch den Server.
Zeigen Sie den Synchronisierungsstatus. Bei jedem Datensatz soll sichtbar sein, ob er auf das Senden wartet, gesendet wurde oder einen Konflikt hat. Vor dem Abmelden muss die Anwendung warnen, und eine abgelaufene Anmeldung darf weder die Arbeit stoppen noch die Warteschlange löschen.
Testen Sie unter realen Bedingungen. Probieren Sie den Flugmodus, WLAN ohne Internet, das Schließen der Anwendung während des Sendens, vollen Speicher und das Ausrollen einer neuen Version mit nicht gesendeten Daten aus – auf iPhone und Android.

Konflikte: Wer gewinnt, wenn sich ein Datensatz an zwei Stellen geändert hat?

Ein Konflikt entsteht, wenn ein Techniker einen Datensatz offline bearbeitet und jemand anderes ihn zwischenzeitlich auf dem Server ändert. Die Regel „der letzte Schreibvorgang gewinnt“ ist am einfachsten zu programmieren, verwirft aber stillschweigend die Arbeit einer Person. Legen Sie die Regeln deshalb vorab je Datentyp fest.

Situation	Empfohlene Regel	Kompromiss
Der Techniker ergänzt das Protokoll, das Büro korrigiert die Kontaktdaten des Kunden	Feldweise zusammenführen, jedes Feld hat einen Verantwortlichen	Die Zuständigkeit für Felder muss genau festgelegt sein
Das Büro hat den Auftrag storniert, der Techniker hat ihn inzwischen ausgeführt	Nicht überschreiben, sondern als Konflikt zur Entscheidung der Disposition markieren	Jemand muss Konflikte regelmäßig klären
Zwei Techniker haben denselben Datensatz bearbeitet	Die Änderung auf Basis der aktuellen Version annehmen, die andere als Konflikt zurückgeben	Der zweite Techniker muss seine Änderung prüfen
Fotos, Notizen und Unterschriften	Nur hinzufügen, nie überschreiben	Mehr gespeicherte Daten, aber nichts geht verloren
Preislisten und Stammdaten	Der Server ist die einzige Quelle, das Gerät liest sie nur	Offline kann auf dem Gerät eine ältere Version liegen

Bewahren Sie bei einem Konflikt beide Versionen mit Autor und Zeitpunkt auf. Sonst lässt sich ein Streit darüber, was der Techniker vor Ort tatsächlich erfasst hat, im Nachhinein nicht klären.

Webanwendung (PWA) oder native App?

Eine Webanwendung hat eine Codebasis für alle Geräte, wird über einen Link verteilt, und eine neue Version spielen Sie ohne App-Stores auf dem Server ein. Sie akzeptieren jedoch die Regeln des Browsers: Best-Effort-Speicher, sofern der Browser keinen dauerhaften Modus gewährt, eine eingeschränkte Hintergrundsynchronisierung und einen Service Worker, den der Browser beendet, wenn er es für angebracht hält. Eine native App kann Daten in einem eigenen Speicher außerhalb des Browsers ablegen, sodass diese Kontingente und Löschregeln für sie nicht gelten. Sie bedeutet jedoch Entwicklung für iOS und Android sowie Verteilung über App-Stores oder über eine Verwaltung der Firmengeräte.

Eine Webanwendung reicht meist aus, wenn es um Formulare, Checklisten, Fotos und Unterschriften geht und sich die Geräte mindestens einmal täglich verbinden.
Eine native App sollten Sie in Betracht ziehen, wenn Mitarbeitende ganze Tage ohne Verbindung arbeiten, große Datenmengen wie Karten oder Videos auf dem Gerät brauchen oder Daten im Hintergrund gesendet werden müssen, ohne dass die Anwendung geöffnet ist.

Entscheiden Sie vor der Entwicklung. Ein Wechsel des Ansatzes mitten im Projekt bedeutet, Speicherung und Synchronisierung neu zu bauen – also den Kern des Offline-Modus.

Häufige Fehler

Offline-Modus erst nach dem Start. Ein Datenmodell ohne lokale Kennungen und Versionen lässt sich nachträglich nur schwer umbauen.
Verlassen auf navigator.onLine. WLAN ohne Internet sieht wie eine Verbindung aus, und Datensätze bleiben hängen.
Daten in localStorage. Nur Text und geringe Kapazität – für Fotos und die Warteschlange ungeeignet.
Das Telefon als einzige Kopie. Nicht gesendete Datensätze liegen tagelang auf dem Gerät, obwohl der Browser alle Daten der Website auf einmal löschen kann.
Unsichtbarer Synchronisierungsstatus. Der Techniker weiß nicht, was gesendet wurde, und meldet sich ab oder löscht die Browserdaten.
Neue Version ohne Migration. Das Update kann die nicht gesendete Warteschlange nicht lesen oder löscht sie.
Privates Surfen. Daten werden beim Beenden des privaten Modus in der Regel gelöscht – nutzen Sie ihn daher nicht für die Arbeit im Außendienst.

Checkliste vor dem Livegang

Die Aufgabentabelle (offline, Entwurf, nur online) ist von Außendienst und Büro abgestimmt.
Jeder Datensatz hat eine lokale eindeutige Kennung, eine Version und einen Synchronisierungsstatus.
Der Server erkennt wiederholtes Senden und legt kein Duplikat an.
Datensätze und Fotos liegen in IndexedDB oder OPFS, nicht in localStorage.
Die Anwendung fordert dauerhaften Speicher an, überwacht dessen Nutzung und kommt mit vollem Speicher zurecht.
Den Erfolg des Sendens bestätigt der Server, nicht der Verbindungsstatus im Browser.
Die Synchronisierung funktioniert auch ohne Background Synchronization API.
Konfliktregeln sind schriftlich festgehalten und getestet, und jemand ist für die Klärung von Konflikten zuständig.
Weder Abmeldung noch abgelaufene Anmeldung löschen nicht gesendete Daten ohne Warnung.
Auf den Geräten liegen nur die Daten für aktuelle Aufträge, und die Telefone haben eine Bildschirmsperre.

Häufig gestellte Fragen

Funktioniert eine Offline-Webanwendung auch auf dem iPhone?

Ja. Safari unterstützt die Storage API seit Version 17 vollständig, und eine zum Home-Bildschirm hinzugefügte Web-App hat dieselben Kontingente wie im Browser. WebKit berücksichtigt bei einer Anfrage nach dauerhaftem Speicher, ob die Website als Web-App vom Home-Bildschirm geöffnet wird (WebKit). Wir empfehlen daher, die Anwendung zum Home-Bildschirm hinzuzufügen und mindestens einmal täglich zu synchronisieren. In der EU können auf iOS ab Version 17.4 auch Browser mit einer anderen Engine laufen, für die deren eigene Speicherregeln gelten (MDN).

Wie viele Daten kann die Anwendung auf dem Telefon speichern?

Das hängt vom Browser und vom Gerät ab. Die Obergrenzen sind hoch, werden aber aus der Gesamtkapazität des Speichers berechnet, nicht aus dem freien Platz – die tatsächliche Grenze kann also ein volles Telefon sein. Die Anwendung sollte die geschätzte Nutzung überwachen, Fotos verkleinern und lokale Kopien nach der Bestätigung durch den Server löschen.

Was passiert, wenn der Techniker die Anwendung vor dem Senden schließt?

In IndexedDB gespeicherte Datensätze bleiben auf dem Gerät, und die Anwendung sendet sie beim nächsten Öffnen. Unterstützt der Browser die Background Synchronization API und wurde die Anfrage bei geöffneter Anwendung registriert, kann er sie auch nach dem Schließen senden. Diese Funktion ist jedoch nicht überall verfügbar, und der Browser begrenzt Anzahl und Dauer der Versuche – deshalb sollte der Techniker immer sehen, was noch auf das Senden wartet.

Brauchen wir wegen des Offline-Modus eine native App?

Für Formulare, Fotos und Unterschriften mit täglicher Synchronisierung meist nicht. Eine native App sollten Sie bei Tagen ohne Verbindung, großen Datenmengen auf dem Gerät oder dem Bedarf, Daten im Hintergrund zu senden, in Betracht ziehen. Treffen Sie die Entscheidung vor Beginn der Entwicklung.

So starten Sie

Wenn Ihre Mitarbeitenden im Außendienst keine Papiere mehr abtippen und keine Fotos mehr per Messenger schicken sollen, beginnen Sie mit der Aufgabentabelle und einem echten Arbeitstag im Außendienst. Sehen Sie sich an, wie wir individuelle Webanwendungen entwickeln, oder schreiben Sie uns über die Kontaktseite. Wir helfen Ihnen, den Offline-Umfang festzulegen, Synchronisierung und Konfliktregeln zu entwerfen und die Anwendung unter den Bedingungen zu testen, unter denen Sie sie einsetzen werden. Sollen die Protokolle weiter in ein ERP- oder CRM-System fließen, übernehmen wir auch die API-Integration. Weitere praxisnahe Anleitungen finden Sie in unserem Blog.

Quellen

Speicherkontingente und Kriterien für die Datenlöschung – MDN Web Docs (auf Englisch)
Offline- und Hintergrundbetrieb progressiver Web-Apps – MDN Web Docs (auf Englisch)
Background Synchronization API – MDN Web Docs (auf Englisch)
Die Eigenschaft navigator.onLine – MDN Web Docs (auf Englisch)
Aktualisierte Speicherrichtlinie in WebKit – WebKit-Blog (auf Englisch)