PWA vs. nativ in der Praxis: Wie man in beiden Fällen Leistung liefert

Die Diskussion „PWA oder nativ“ endet bei den meisten Artikeln zum Zeitpunkt der Entscheidung. Doch für diejenigen, die bauen, ist die Entscheidung erst der Anfang. Die Wahl der richtigen Plattform und deren schlechte Ausführung führt zum gleichen Ergebnis wie die Wahl der falschen: ein langsames Produkt, das der Benutzer aufgibt.

Ich habe schnelle PWAs und sehr langsame PWAs gesehen. Ich habe gesehen, dass native Apps flüssig waren und native Apps hängen blieben. Die Plattform übernimmt keine Leistungsgarantie; Ausführungsgarantien. Und jeder Ansatz hat seine eigenen Fehlerquellen, seine eigenen Fallstricke und seine eigenen Pflegepraktiken.

Dieser Text richtet sich an diejenigen, die sich bereits entschieden haben und nun liefern müssen. Anstatt PWA und nativ in der Zusammenfassung zu vergleichen, werde ich mich damit befassen, wie man die Leistung jedes einzelnen in der Praxis aufrechterhält, wo jeder dazu neigt, hängen zu bleiben und was zu tun ist, damit die Geschwindigkeit den Benutzer erreicht und bleibt.

Leistung ist das, was der Benutzer fühlt, nicht das, was die Grafik zeigt

Vor jeder Technik lohnt es sich, das Wesentliche in Einklang zu bringen. Für den Benutzer ist die Leistung kein Maßstab. Es ist das Gefühl, dass die App reagiert. Es geht darum, etwas Nützliches schnell zu sehen, es zu berühren und eine Antwort zu erhalten, und nicht darauf zu warten, dass der Bildschirm eingefroren ist.

Diese Unterscheidung verändert die Art und Weise, wie wir arbeiten. Die Optimierung interner Kennzahlen, die der Benutzer nicht bemerkt, ist Verschwendung. Was bleibt, ist die Optimierung der Zeit bis zur ersten nützlichen Interaktion, die flüssigen Reaktionen und das Fehlen von Abstürzen.

Sowohl in PWA als auch in Native ist die Wahrnehmung der Herrscher. Die Techniken ändern sich, aber das Ziel ist dasselbe: Das Produkt soll überall dort, wo der Benutzer hinschaut, schnell aussehen. Wer das anstrebt und nicht die schöne Zahl, liefert bessere Ergebnisse.

In der Praxis Leistung in einer PWA liefern

Die Achillesferse von PWA ist das Gewicht des Internets. Da es im Browser ausgeführt wird, beansprucht alles, was Sie laden, Skripte, Stile, Bibliotheken, seinen Tribut an der Öffnungszeit. Der häufigste Fehler besteht darin, Abhängigkeiten anzuhäufen, bis die App langsamer wird, ohne dass jemand merkt, wann das passiert ist.

Die erste Übung besteht darin, die App schlank zu halten. Laden Sie nur das, was für den ersten Bildschirm erforderlich ist, und verschieben Sie den Rest. Brechen Sie den Code, damit der Benutzer nicht sofort herunterlädt, was er erst später verwendet. Jedes Kilobyte, das beim anfänglichen Laden verloren geht, wird als wahrgenommene Geschwindigkeit angezeigt.

Die zweite besteht darin, den Service-Worker-Cache zu beherrschen. Dadurch wird PWA bei nachfolgenden Besuchen sofort geöffnet und funktioniert offline. Aber ein schlecht konfigurierter Cache stellt alte Inhalte bereit oder verhindert das Eintreffen von Updates. Definieren Sie in der Praxis Strategien nach Ressourcentyp, aggressiv für das, was sich nicht ändert, validiert für das, was sich ändert, und testen Sie das Update bei jeder Lieferung, um den Benutzer nicht an eine alte Version zu binden.

Die dritte besteht darin, mit realen Daten und unter realen Bedingungen zu messen: langsame Verbindung, bescheidenes Gerät. Was auf dem Rechner des Entwicklers fliegt, kann auf dem Handy des Nutzers kriechen. Die Leistung von PWA bleibt erhalten, wenn die Messung in den Lieferstrom gelangt, nicht wenn man sich auf den Druck verlässt.

In der Praxis Leistung in einer nativen Sprache liefern

Native hat zwar einen deutlichen Leistungsvorteil, aber dadurch entsteht ein falsches Sicherheitsgefühl. Die Falle ist hier nicht das Ladegewicht, sondern der sorglose Umgang mit Geräteressourcen: Speicher, Akku, Arbeit am Hauptthread.

Die erste Vorgehensweise besteht darin, die Fließfähigkeit der Schnittstelle zu schützen. In nativer Ausführung führt jede schwere Operation im Thread, der den Bildschirm zeichnet, zu einem sichtbaren Absturz. Bei intensiver Arbeit, Verarbeitung, Datenzugriff und Netzwerk muss dieser Thread beendet werden, damit die Schnittstelle weiterhin reagieren kann. Hier kommt es fast immer zu Abstürzen beim Scrollen und Tippen.

Die zweite besteht darin, sich um Speicher und Ressourcen zu kümmern. Native Apps, die Speicher verlieren oder Ressourcen beanspruchen, verschlechtern sich mit der Nutzung und werden langsamer, je länger sie geöffnet sind. In der Praxis erfordert dies Disziplin bei der Freigabe dessen, was nicht verwendet wird, und beim Testen der App in langen Sitzungen, nicht nur in Schnellstarts.

Die dritte besteht darin, das Gerät zu respektieren. Übermäßiger Akku- und Datenverbrauch fällt im Kurztest zwar nicht auf, zerstört im realen Einsatz aber den Ruf der App und führt zur Deinstallation. Das Messen des Verhaltens der App im Laufe der Zeit auf verschiedenen Geräten unterscheidet die native App, die in der Demo gut aussieht, von der nativen App, die die Lebensqualität des Benutzers aufrechterhält.

Der Fehler, der sie beide untergeht

Beiden Ansätzen ist eine Falle gemeinsam, die eher kulturell als technisch ist: die Leistung bis zum Ende aufzuschieben.

Teams, die Geschwindigkeit als letzte Anpassung betrachten, nachdem das Produkt fertig ist, stellen fest, dass schlechte Leistung normalerweise in der Architektur und nicht in den Details liegt. Sie können das, was erstellt wurde, nicht „später optimieren“, ohne an die Geschwindigkeit zu denken. Die Gewinne in letzter Minute sind gering; Die strukturellen Probleme sind groß.

Die Praxis, dies zu vermeiden, besteht darin, Leistung als kontinuierliches Kriterium einzubeziehen. Messen Sie frühzeitig, legen Sie eine akzeptable Belastungs- und Reaktionsobergrenze fest und behandeln Sie Leistungsrückgänge als Mangel und nicht als optionale Verbesserung. Sowohl bei PWA als auch bei Native bleibt die Geschwindigkeit erhalten, auf die von Anfang an geachtet wurde, Lieferung für Lieferung.

Ein weiterer gemeinsamer Fehler besteht darin, nicht unter realen Bedingungen zu messen. Das Entwicklergerät ist leistungsstark und verfügt über ein gutes Netzwerk. Nicht der Benutzer. Leistung, die nur im Umfeld derer existiert, die sie erschaffen, ist eine Illusion.

Leistung als Disziplin, nicht als Wunder

Die Lektion, die für PWA und nativ gilt, ist dieselbe: Leistung ist kein Effekt der Plattform, sondern das Ergebnis sorgfältiger und kontinuierlicher Ausführung. Die beste Technologieauswahl, die ohne Disziplin umgesetzt wird, führt zu einem langsamen Produkt. Eine bescheidene und sorgfältig ausgeführte Entscheidung kann zu einem hervorragenden Erlebnis führen.

In PWA liegt der Schwerpunkt der Disziplin auf Gewicht und Cache. Im Nativen, im Ressourcenverbrauch und in der Fluidität. In beiden Fällen ist der Feind die Selbstgefälligkeit: Man geht davon aus, dass es schnell ist, weil es für Sie schnell ist, und stellt spät fest, dass es für den Benutzer nicht schnell ist.

Diejenigen, die für andere Menschen bauen, müssen messen, wie sie das Produkt erleben, und nicht, wie es in der kontrollierten Entwicklungsumgebung erscheint. Diese Bescheidenheit, auf dem schlechtesten Gerät und der schlechtesten Verbindung zu testen, ist es, was die Produkte, die Menschen verwenden, von denen unterscheidet, die sie deinstallieren.

Die Entscheidung zwischen PWA und nativer Materie. Aber genauso wichtig ist die Umsetzung, und hier entscheiden die meisten Produkte über Sieg oder Niederlage. Leistung ist tägliche Arbeit und es gibt keine Plattform, die diese Arbeit ersetzen kann.