Blog

In den letzten Jahren hat sich im Bereich der App-Entwicklung viel getan. Passé sind die Tage, wo Apps zwingend separat für jedes zu unterstützende Betriebssystem entwickelt werden mussten. Hybride Apps sind der neue Trend. Aus gutem Grund: Die hybride Entwicklung spart Unmengen an Zeit, Kosten und anderen Ressourcen. Die absolute Mehrheit an Apps, die unsere App-Agentur verlässt, wird in React Native entwickelt. Viele Kunden fragen uns: Was ist das überhaupt, womit ihr meine App in einem Bruchteil der sonst üblichen Zeit umsetzen konntet? Wir geben Ihnen einen Überblick samt Vor- und Nachteilen. REACT NATIVE KURZ ERKLÄRT Achtung, hier wird es etwas technisch – wir halten uns der Verständlichkeit halber aber kurz. React Native ist ein Framework (quasi ein Baukasten) für die Entwicklung von hauptsächlich, aber nicht ausschließlich, Smartphone-Apps. Es basiert auf dem UI-Framework React und erweitert dieses, wie der Name verrät, um die Möglichkeit, native Apps für verschiedene Betriebssysteme zu entwickeln. Während "echte" native Apps direkt für ein bestimmtes Betriebssystem entwickelt werden, werden React Native Apps "universell" entwickelt. Der geschriebene Code wird dann in eine native iOS- bzw. Android-App eingepackt. Über eine sogenannte Bridge (Brücke), welche ebenfalls in der von React Native generierten nativen App enthalten ist, kann der eingepackte Code dann direkt mit dem Betriebssystem kommunizieren. So ist es möglich, Software- und Hardware-Funktionen nutzen zu können, auf die reine Web Apps zum Beispiel keinen Zugriff haben. UI-Elemente werden direkt über die native App gerendert und müssen nicht über die Brücke kommunizieren. Dadurch genießen React Native Apps eine herausragende Performance, welche sich vor nativen Apps nicht verstecken muss. WER VERWENDET REACT NATIVE? Die Chance ist hoch, dass auf Ihrem Smartphone mindestens eine App (eher weitaus mehr) installiert ist, die in React Native entwickelt wurde. React und React Native werden in erster Linie vom Internet-Riesen Meta entwickelt, haben beide jedoch eine unfassbar große Open-Source Community. Unter anderem die Apps von Facebook selbst, Amazon inkl. Kindle, Microsoft Office, Pinterest uvm. wurden in React Native entwickelt. Einen Überblick über weitere Apps können Sie im Showcase auf der Webseite von React Native [https://reactnative.dev/showcase] sehen. Auch das ist jedoch nur ein winzig kleiner Auszug. Sie nutzen vermutlich mehr Apps, die in React Native entwickelt wurden, als Sie vielleicht denken – und werden den Unterschied zu nativen Apps nicht spüren können. DER TURBO FÜR IHR APP-PROJEKT Der große Vorteil von React Native (wie im Übrigen auch von anderen, ähnlichen Frameworks wie Flutter) liegt somit darin, dass eine App nur einmal entwickelt werden muss. Was sich banal anhört, hat große Auswirkungen auf den zeitlichen Aufwand und das Budget. Der universelle React Native Code kann dann als native App für alle möglichen Betriebssysteme exportiert werden. In den meisten Fällen sind das iOS und Android. Es ist jedoch genauso möglich, mit React Native zum Beispiel Web Apps, Anwendungen für macOS und Windows, ja selbst den Apple TV zu entwickeln. Alles mit einer einzigen Codebasis. Zugegeben: Hier und da müssen geräte- und betriebssystemspezifische Anpassungen und Optimierungen vorgenommen werden. Nicht alles, was auf iOS reibungslos funktioniert, läuft auch auf Android direkt rund. Der Aufwand dafür ist im Vergleich zur Entwicklung zwei separater Apps für jedes Betriebssystem so marginal, dass er nahezu vollständig vernachlässigt werden kann. Am Ende ist es damit also möglich, eine App für iOS, Android, macOS, Windows und das Web zum Preis und mit dem Zeitaufwand von einer App entwickeln zu lassen. OPEN-SOURCE UND DAS ÖKOSYSTEM Ein weiterer Punkt, mit dem React Native trumpfen kann, ist die dahinterstehende Gemeinschaft. Während React Native eine solide Basis bildet, gibt es unzählige Libraries von ehrenamtlichen Open-Source Entwicklern, mit welchen Apps noch schneller und effizienter umgesetzt werden können, ohne das Rad an jeder Ecke neu erfinden zu müssen. Die App benötigt eine Navigation mit einer Tabbar am unteren Bildschirmrand? Klar, hat schonmal jemand gelöst. Die App soll Zugriff auf Kamera und GPS haben? Allein dafür gibt es mehrere Hände voll frei zugänglicher Module. Hier liegen jedoch gleichzeitig zwei gefährliche Fallen: Man könnte einerseits in Verlegenheit kommen, sich durch die Unmengen an Open-Source Libraries zu wühlen und die eigene App mit für den Nutzer völlig unrelevanten Funktionen und UI-Elementen voll kleistern. Nicht nur zehrt das an der Performanz der App, auch ist für den Nutzer dadurch nichts gewonnen und die App wird komplexer, als sie es sein müsste. Die viel größere Gefahr liegt jedoch in der Auswahl der zu verwendenden Module: Es muss beachtet werden, dass diese schlussendlich nur ehrenamtlich weiter entwickelt werden. Es hält einen Maintainer ("Betreuer") einer Open-Source Library nichts davon ab, die Weiterentwicklung von heute auf morgen einzustellen. Soll die eigene App aber weiterhin weiter entwickelt werden, bedeutet das in der Regel, dass das betroffene Modul ausgetauscht oder mit eigenem Code ersetzt werden muss. Dadurch ergibt sich zum Teil doppelte Arbeit. Es ist daher ungemein wichtig, eine erfahrene und auf React Native spezialisierte Agentur an der Hand zu haben, die sich mit dem Ökosystem rund um React Native auskennt und weiß, welche Module in welchem Umfang genutzt werden können, ohne sich langfristig unter Umständen selbst ein Bein zu stellen. EXPO – REACT NATIVE AUF SPEED Besonders hervorzuheben im Ökosystem von React Native ist Expo [https://expo.dev]. Es gibt quasi keine App, die unsere Agentur verlässt, die nicht mindestens ein Modul von Expo verwendet, oder gar vollintegriert in das eigene Ökosystem von Expo ist. Expo ist ein Urgestein in der React Native Community und treibt die Weiterentwicklung dessen seit Jahren aktiv voran. Inzwischen ist ein komplett eigenes System aus Frameworks, Modulen und Tools entstanden, die die Arbeit mit React Native enorm vereinfachen. Auch hier gilt: Die App muss auf die Kamera zugreifen? Da gibt's ein Modul von Expo für. Zugriff auf den Nutzerstandort benötigt? Kein Problem, Expo hat da eine Library. Lange Zeit hatte die Verwendung von Expo-Modulen jedoch den Nachteil, dass man sich dadurch selbst in das System von Expo "einsperrte" (Vendor Lock-in). Die Verwendung derer Module war nämlich nur möglich, wenn man auch die Toolkits von Expo verwendete, was wiederum zur Folge hatte, dass man die Toolkits von React Native selbst nicht mehr verwenden konnte. Auch konnte man, wenn man Expo verwendete, sehr viele Libraries von anderen Anbietern nicht mehr nutzen, was auch hieß, dass einige Software- und Hardware-Funktionen wie In-App Käufe überhaupt nicht implementiert werden konnten, wenn man auf Expo setzte. In eher unerfahrenen Kreisen von App-Entwicklern ist Expo daher immer noch etwas in Verruf. Das jedoch völlig grundlos: Spätestens seit November 2021 und dem Release der Expo Application Services (EAS) gibt es diesen Vendor Lock-in nämlich nicht mehr. Alle Expo-Module und selbst die Toolkits von Expo können problemlos verwendet werden, ohne sich dadurch selbst einzusperren. Auch die Verwendung von Libraries anderer Anbieter ist bei der gleichzeitigen Verwendung von Expo kein Problem mehr. Gleichzeitig ist das Kompilieren (also das Verpacken des Codes in eine lauffähige App) und Verteilen von React Native Apps dank Expo EAS um ein Vielfaches einfacher geworden. Heutzutage gilt: Alles, was in React Native umgesetzt werden kann, kann auch in Expo umgesetzt werden – dank der umfassenden Toolsets aber schneller, komfortabler und effizienter. Wer an einer etwas technischeren Erklärung von EAS Interesse hat, bekommt den Unterschied zum vorherigen Workflow in diesem Beitrag von Expo [https://blog.expo.dev/expo-managed-workflow-in-2021-5b887bbf7dbb] gut erklärt. WIE ZUKUNFTSSICHER IST REACT NATIVE? Bei all den Vorteilen fragen Sie sich vielleicht, ob das Ganze denn zukunftssicher ist. Am Ende ist React Native schließlich nur eine weitere Ebene Ihrer App, die womöglich irgendwann einmal wegfallen könnte. Auch hier trumpft React Native mit dem starken Rückhalt durch die Open-Source Gemeinde. Selbst wenn sich Meta einmal dazu entschließen sollte, React Native nicht weiter zu entwickeln, ist die Chance enorm hoch, dass ein anderes Entwickler-Team diese Rolle übernimmt. Es sind inzwischen zahlreiche Geschäftsmodelle rund um React Native entstanden, nicht zuletzt auch die oben genannten Expo Application Services, weshalb auch eine Menge Geld im System hängt. Es ist daher nahezu ausgeschlossen, dass React Native von heute auf morgen verschwindet bzw. nicht mehr weiter entwickelt wird. Und allein der Gedanke, dass Meta die Lust verliert, React Native weiter zu entwickeln, ist ziemlich fernab: Am Ende hat wohl auch Meta kaum Lust, einen großen Teil ihrer eigenen Apps, die selbst auf React Native basieren, komplett neu zu bauen. Mit einer App, die in React Native entwickelt wurde, setzen Sie also auf eine zukunftssichere Option, die Entwicklung Ihrer App nicht nur schneller und effizienter, sondern auch kostengünstiger macht. NACHTEILE UND LIMITATIONEN Nachdem wir in diesem Artikel bislang von React Native geschwärmt haben, ist es nur fair, auch Nachteile aufzuzeigen, und wo eine native App vielleicht die sinnvollere Option ist. Eines vorab: Wenn Sie einen Entwickler beauftragen, der Ihnen von React Native abrät, weil man damit Funktion X oder Y nicht umsetzen könne, weil dies nur mit einer nativen App möglich sei, hat dieser leider ein grundlegendes Fehlverständnis von React Native. React Native ist wie am Anfang dieses Artikels beschrieben nicht nur eine hübsch verpackte Web App. Selbst wenn es mal kein fertiges Modul für eine bestimmte Funktion geben sollte, ist es möglich, diese Funktion nativ für die gewünschten Betriebssysteme zu entwickeln und den nativen Code dann über die Bridge mit dem universellen Hybrid-Code kommunizieren zu lassen. Es muss also nach wie vor keine komplett eigene App für jedes Betriebssystem entwickelt werden, sondern es muss nur die gewünschte Funktion an sich separat entwickelt werden. Die Geschäftslogik, die auf dieser nativen Funktion basiert, befindet sich dann im universellen Code, der nur einmal zu entwickeln ist. Damit das möglich ist, bedarf es aber zwingend einem Entwickler bzw. einer Agentur, die sich tiefgreifend mit React Native auskennt und auf die Entwicklung damit spezialisiert ist. Ein eher unerfahrener Entwickler wird nämlich nur auf quelloffene Module setzen können, nicht aber sein eigenes, natives Modul entwickeln können, falls es mal keine vorgefertigte Lösung gibt. Dadurch wird er Ihnen schnell dazu raten, einfach die ganze App nativ zu entwickeln. Ein teurer Fehler. Nichtsdestotrotz gibt es auch Situationen, in denen eine native App doch mehr Sinn macht. Diese sind jedoch so selten, dass wir sie unserer Agenturhistorie an zwei Händen abzählen können. Hauptsächlich geht es in diesen Situationen um die benötigte Performanz der App. Ist diese auf Höchstleistung angewiesen, fällt React Native aus dem Raster. Die Chance ist jedoch hoch, dass Sie denken, Ihre App benötige mehr Performanz, als tatsächlich notwendig. Eine Geschwindigkeit, die React Native nicht mehr bieten kann, wird eigentlich nur von Apps benötigt, die komplexe 3D-Visualisierungen, Augmented Reality, Videobearbeitungen oder Ähnliches können sollen, sowie von 3D-basierten Videospielen. Wir beraten Sie dazu im Hinblick auf Ihr App-Projekt gerne in einem unverbindlichen Erstgespräch.

Möchten Sie eine mobile App an potentielle Endnutzer vertreiben, führt in aller Regel kein Weg am Apple App Store und Google Play Store vorbei. Doch was bedarf es eigentlich alles, um eine App in den beiden größten App Stores listen und vertreiben zu dürfen? Und: Was kostet das Ganze? Das, und noch vieles mehr, erklären wir Ihnen in diesem Artikel. DAS APP STORE DUOPOL Wenn Sie eine App auf Ihr Smartphone herunterladen möchten, sei es ein iPhone oder ein Android-Gerät, ist die Chance hoch, dass Sie den App Store bzw. Google Play Store öffnen. Abseits von kleineren Storefronts bestimmter Smartphone-Hersteller wie Huawei haben diese beiden großen Stores nämlich seit jeher faktisch ein Duopol auf den App-Markt. An ihnen führt beim Herunterladen einer Mobile App quasi kein Weg vorbei. Auf Android-Geräten gibt es zwar theoretisch die Möglichkeit, Apps direkt aus dem Internet (außerhalb des Google Play Stores oder anderer geschlossener Ökosysteme) zu beziehen und zu installieren, das geht jedoch mit einer Öffnung von Sicherheitsbeschränkungen auf dem Gerät einher. Und auch wenn sich Apple derzeit aufgrund neuer EU-Vorschriften auf eine ähnliche Öffnung von iOS vorbereitet, landen die meisten Nutzer doch immer wieder im App Store. Sprich: Möchten Sie eine App für Endnutzer veröffentlichen und bestenfalls mit dieser Geld verdienen, sind Sie an die beiden großen App Stores gebunden. ANFORDERUNGEN UND GUIDELINES Sowohl Apple als auch Google stellen umfassende Anforderungen an zu veröffentlichende Apps. Möchten Sie eine App veröffentlichen, sind Sie also durch die Marktsituation nicht nur an die beiden großen Player gebunden, sondern haben sich auch an deren Spielregeln zu halten. Beide Konzerne prüfen jede einzelne App bei Neuveröffentlichung sowie quasi jedem eingereichten Update genau. Erfahrungsgemäß ist Google weitaus nachlässiger bei diesen Prüfungen, Apple hingegen weitaus strikter, wodurch es insbesondere im Apple App Store auch mal zwei oder gar drei Anläufe brauchen kann, bis eine App akzeptiert wird. Nicht zuletzt deshalb weist der Google Play Store fast doppelt so viele Apps wie der App Store auf [https://de.statista.com/statistik/daten/studie/208599/umfrage/anzahl-der-apps-in-den-top-app-stores/]. Das heißt aber nicht, dass Google den Entwicklern einen Freifahrtschein an die Hand gibt. Auch hier müssen bestimmte Richtlinien eingehalten werden, um keine (womöglich sogar dauerhafte) Ablehnung der App zu gefährden. Daher sollte der Entwicklungs- und Veröffentlichungsprozess einer App bestenfalls durch eine in diesem Bereich erfahrene Agentur erfolgen. Zur Einordnung: Die App Store Review Guidelines von Apple [https://developer.apple.com/app-store/review/guidelines] schlagen mit nahezu 15.000 Wörtern zu Buche und umfassen jedes kleinste Detail von Design-Anforderungen über technische Gepflogenheiten bis hin zu konzeptionellen Einschränkungen. Insbesondere bei der ersten, eigenen App ist es leicht, über eine der zahlreichen Regeln zu stolpern. Die Guidelines müssen nicht nur während der Entwicklung und Veröffentlichung beachtet werden, sondern bereits in die Konzeptionierung der App einfließen. WAS KOSTET DIE VERÖFFENTLICHUNG? Ohne Frage: Der Design- und Entwicklungsprozess ist bei einer App natürlich mit den höchsten Kosten verbunden. Nichtsdestotrotz sollten Sie bei Ihren Kalkulationen die Kosten für die Veröffentlichung in den beiden App Stores nicht außer Acht lassen. Auch hier unterscheiden sich die Ansätze von Apple und Google stark. Während Google auf eine einmalige Registrierungsgebühr von 25 USD für Entwickler setzt, womit sämtliche Veröffentlichungen im Google Play Store und andere Annehmlichkeiten abgegolten sind, greift Apple tiefer in die Tasche. Bei Apple wird eine jährliche Gebühr von 99€ fällig, um das App Store Konto aktiv zu halten. Wird die Gebühr nicht weitergezahlt, wird das Konto und damit die Platzierung der eigenen App im App Store deaktiviert. Nur bei der Registrierungsgebühr bleibt es jedoch leider nicht – zumindest, wenn Sie planen, mit Ihrer App Geld zu verdienen. Hier greifen sowohl Apple als auch Google erneut in die Taschen der Entwickler. Während Google an einer mehr oder weniger festen Gebühr von 30% auf alle In-App-Käufe festhält, bietet Apple auf Antrag die Möglichkeit, die Gebühren (welche sonst ebenfalls 30% betragen) bis zu einem Höchstumsatz von 1 Millionen USD auf "nur" 15% reduziert zu bekommen (hierzu gleich mehr). Auch hier gibt es in beiden Stores diverse Sonderregelungen, beispielsweise bei Erreichen einer bestimmten Mindestdauer eines Abonnements. Insbesondere bei Apple gibt es für bestimmte Unternehmensformen und -größen Möglichkeiten, die Registrierungsgebühr und/oder die Gebühren für In-App-Käufe erlassen oder reduziert zu bekommen. Dies trifft beispielsweise auf gemeinnützige Organisationen zu. Auch hier sollten Sie sich bestenfalls von einer erfahrenen Agentur beraten lassen, da die Formulare zum Teil (vermutlich bewusst) schwer auffindbar sind und der Prozess langwierig ist. Wir haben diesen Vorgang bereits bei mehreren Kunden erfolgreich begleitet – sprechen Sie uns also gerne an. LASSEN SICH DIE GEBÜHREN UMGEHEN? Während die Registrierungsgebühren (bis auf einige Ausnahmen, wie oben beschrieben) quasi in Stein gemeißelt sind, da die App sonst nun mal nicht an interessierte Nutzer kommt, könnte man meinen, die Gebühren für In-App-Käufe ließen sich leicht umgehen. Nicht wenige Publisher sind auf die Idee gekommen, einfach eigene Abrechnungssysteme – seien das Kreditkarten, PayPal, oder sonstige – in die App einzubauen und die Gebühren in Höhe von 30% zu umgehen. Hier stößt man leider nur in aller Regel wieder auf die App Guidelines beider Stores. Für die allermeisten App-Arten ist das Implementieren eigener Abrechnungssysteme zum "Schutze der Nutzer" (sic!) nicht erlaubt. Hiervon ausgenommen sind bestimmte Geschäftsmodelle wie Liefer-Apps. Vielleicht ist Ihnen, wenn Sie Spotify nutzen, schonmal aufgefallen, dass Sie in deren App kein Premium-Abonnement erwerben können. Wegen eben dieser Vorschrift und der hohen Gebühren hat Spotify diese Funktion nämlich bewusst aus der eigenen App entfernt. Möchten Nutzer ein Premium-Abonnement erwerben, muss dies über die Webseite von Spotify geschehen. Die Richtlinien des App Stores gehen hier sogar so weit, dass es untersagt ist, Nutzer darauf hinzuweisen, dass ein Abonnement auf der Webseite erworben werden kann. Diese Praxis ist derzeit auf EU-Ebene heißes Gesprächsthema und wird früher oder später seitens Apple und Google vermutlich gelockert werden müssen. Bis dahin gilt jedoch: Sind Sie nicht gerade Spotify und können es sich aufgrund Ihrer Marktposition erlauben, Ihre Produkte nur außerhalb der App zu vertreiben, würden wir von einem solchen Schritt abraten. Die verlorene Menge zahlender Nutzer wird größer sein als mögliche Gewinnsteigerungen durch das Umgehen der Gebühren. WAS PASSIERT NACH DER VERÖFFENTLICHUNG? Mit der erfolgreichen Veröffentlichung der App ist die Arbeit noch nicht getan: Sowohl Apple als auch Google erneuern ihre Richtlinien regelmäßig und setzen auch bestehenden Apps Fristen, um diese einzuhalten. Eine dauerhafte App-Wartung ist für jedes ernstzunehmende App-Projekt daher unerlässlich. Auch müssen Apps müssen auf neue Betriebssystemversionen, Bildschirmgrößen usw. aktualisiert werden. Als erfahrene und vor allem rein auf App-Entwicklung spezialisierte Agentur betreuen wir Sie bei diesem Prozess selbstverständlich von A bis Z und zeigen Ihnen in einem unverbindlichen Erstgespräch die dahingehenden Herausforderungen bei Ihrem Projekt auf. Sind Sie also auf der Suche nach einer professionellen App-Agentur in Frankfurt oder remote, sprechen Sie uns gerne an.

Vielleicht haben Sie mittlerweile auch einen Reflex wie wir entwickelt: Jedes Mal, wenn Sie eine neue Webseite öffnen, wandert Ihr Mauszeiger ganz automatisch in die Mitte, um das Wegdrücken des unter einer tiefen Hassliebe leidenden Cookie-Banners vorzubereiten. Umso verwunderter waren Sie vielleicht, als Sie auf unsere Webseite stießen. Wo ist denn nun eigentlich unser Cookie-Banner? Die Antwort ist keine Fehlfunktion Ihres Browsers oder ein unterbewusstes und vergessenes Wegdrücken des Banners: Wir haben keinen Cookie-Banner. Aber wie ist das möglich? Ein Exkurs in die Entwicklung des Datenschutzes im Internet und weshalb Abmahnanwälte bei uns wenig Chance haben (und wie diesen auch bei Ihrer Webseite die Lust vergehen kann). COOKIES: WIESO, WESHALB, WARUM Mit Auftreten des Phänomens "Web 2.0" wurde gefühlt auf wöchentlicher Basis eine neue Methode entwickelt, Webseiten-Besucher möglichst effektiv in ihrem Surfverhalten zu tracken. Das reicht von der Erfassen der IP-Adresse über skurrile Methoden, Nutzer über Browsereigenschaften wie die Bildschirmauflösung zu "fingerprinten" bis eben zum Speichern einer kleinen Datenmenge auf dem Computer des Nutzers: dem Cookie. Über die Jahre ist die Verwendung solcher Trackingmaßnahmen jedoch ausgeufert und (zumindest in der Europäischen Union) schlussendlich, zurecht, in einem harten, gesetzlichen Vorgehen gegen diese geendet: Der europäischen Datenschutzgrundverordnung (DSGVO) und dem deutschen Bundesdatenschutzgesetz (BDSG). Auch wenn das Effektivwerden dieser gesetzlichen Änderungen einen langen Vorlauf hatte, fühlte es sich dann am 25. Mai 2018 plötzlich doch so an, als wäre über Nacht die Sintflut über das Internet hereingebrochen. Mit der DSGVO und der plötzlichen Verwunderung darüber, dass personenbezogene Daten einem rechtlichen Schutz unterliegen, mussten neue, datenschutzfreundliche Methoden her, um Analyse zu betreiben. Dachte der eine oder andere vielleicht zumindest. Die Realität sah nämlich ganz anders aus: Rechtliche Grauzonen wie das (inzwischen gekippte) "US-EU Privacy Shield" oder eben die Cookie-Banner entstanden, um die invasiven Tracking-Methoden weiterhin aufrecht zu erhalten. TRACKING AUF DATENSPARSAM Auch vor Inkrafttreten der DSGVO haben wir auf unserer Webseite bereits auf die Verwendung von Tools verzichtet, die bekanntermaßen eher sorglos mit Daten von Nutzern umgingen. Dazu gehörten insbesondere Google Analytics, welches mit neuer Rechtsprechung inzwischen tatsächlich auch in der Praxis immer mehr Boden in der EU verliert. Wie aber bekommen wir es hin, so ganz ohne Cookies und damit Cookie-Banner auszukommen? DEN STATUS QUO ANALYSIEREN Wenn keine Cookies oder andere invasive Tracking-Mechanismen verwendet werden, benötigt man keinen Banner. So weit, so selbstverständlich. Dies betrifft übrigens nur technisch nicht unbedingt notwendige Cookies. Technisch zwingend notwending sind jedoch ohnehin nur die wenigsten Cookies (darunter zählen z.B. Cookies, welche den Inhalt eines Warenkorbs speichern). Die Reichweite von Cookies ist jedoch vielen nicht so genau bewusst: So gut wie jedes Drittanbieter-Tool, welches Sie auf Ihrer Webseite einbinden, speichert Cookies auf dem Rechner des Nutzers und/oder funkt nachhause. Oft handelt es sich hierbei sogar um US-Unternehmen, womit die Übertragung der Daten insbesondere nach dem Ungültigwerden des "Privacy Shields" umso problematischer ist. Das muss jedoch nicht sein: Es gibt genügend datenschutzfreundliche Alternativen für so gut wie jedes Problem. Der erste Schritt muss hierbei jedoch sein, den aktuellen Status bzw. die aktuell durch die eigene Webseite gespeicherten Cookies zu analysieren. Hierzu können Sie entweder browsereigene Funktionalitäten (den "Web-Inspektor") nutzen oder aber auf Tools wie PrivacyScore [https://privacyscore.org/] zurückgreifen. Notieren Sie sich sämtliche Cookies und Verbindungen zu Drittanbietern und analysieren bzw. recherchieren Sie, woher diese stammen. DATENSPARSAME ALTERNATIVEN Nachdem Sie wissen, wohin Ihre Webseite überall nachhause telefoniert und welche Daten auf dem Rechner des Nutzers alle gespeichert werden (und v.a. wieso), können Sie diese Drittanbieter durch andere Anbieter ersetzen, welche sich dem Schutz personenbezogener Daten zugeschworen haben. Eines vorab: Der große Nachteil (oder Vorteil?) hierbei ist allerdings, dass viele dieser Tools kostenpflichtig sind. Wo kein Geld mit Daten Ihrer Nutzer verdient werden kann, muss nunmal anders Geld verdient werden. Viele dieser Tools sind jedoch open-source und können zum Teil kostenfrei auf eigenen Servern gehostet werden (was nochmal eine ganze Ecke datenschutzfreundlicher ist!), was jedoch ein technisches Verständnis oder immerhin eine gute IT-Abteilung (ebenfalls sinnvollerweise mit technischem Verständnis) erfordert. Nachfolgend listen wir Ihnen einige der Tools und Methoden auf, welche wir nutzen, um so datensparsam wie möglich zu agieren und gänzlich auf lästige Cookie-Banner verzichten zu können. GOOGLE ANALYTICS Machen wir uns nichts vor: Der Elefant im Raum ist immer noch Google Analytics. Viel zu gewöhnt sind wir an dieses mächtige Werkzeug bereits. Leider ist es unter allen Tools, die man auf seine Webseite so einbinden kann, auch jenes, welches am sorglosesten mit den Daten der Nutzer umgeht. Verschiedenste Rechtsurteile haben inzwischen auch dafür gesorgt, dass der Einsatz von Google Analytics in der EU in der Praxis unmöglich ist. Eine datenschutzfreundliche Alternative, welche wir verwenden, ist das Tool Simple Analytics der niederländischen, gleichnamigen Firma. Simple Analytics verzichtet gänzlich auf das Setzen von Cookies. Beim Öffnen der Webseite wird ein Skript von Simple Analytics abgerufen (von europäischen Servern), welches die Aufgabe übernimmt, den Nutzer während seines Website-Besuchs zu tracken. Dabei wird jedoch insbesondere auch auf das Tracken der IP-Adresse oder anderen personenbezogenen Daten verzichtet. Das Tracking läuft gänzlich über den HTTP-Referrer. Um nicht gänzlich in technische Details zu verschwinden, können Sie bei Interesse hier mehr erfahren [https://docs.simpleanalytics.com/what-we-collect]. Eine weitere Alternative ist unter anderem Matomo, welches auch auf eigenen Servern gehostet werden kann. GOOGLE MAPS Google Maps war lange Zeit die einzige Verbindung zu einem Drittserver, die auf unserer Webseite erfolgte. Leider gibt es hier noch immer keine datenschutzfreundliche, aber zugleich einfach zu implementierende Alternative. Auf unserer alten Webseite verwendeten wir daher die OpenStreetMap. Das Problem? Grundsätzlich kommt diese zwar ohne das Setzen von Cookies aus, der Abruf der Kartendaten erfolgt jedoch trotzdem von OpenStreetMap-Servern, denen Fastly CDN (ein Content Delivery Network), welches auf amerikanischen Servern betrieben wird, vorgeschaltet ist. Auch ist die Datenschutzerklärung von OpenStreetMap selbst nicht rechtskonform. Die Verwendung der OpenStreetMap im Auslieferungszustand ist datenschutzrechtlich insofern nicht rechtens. Daher haben wir uns hier mit einem kleinen Trick beholfen, welchen wir auch für andere Drittanbieterdienste verwenden: Wir haben einen sogenannten HTTP Proxy zwischen die Verbindung von Ihrem Browser und den OpenStreetMap-Servern geschaltet. Bei Abruf der Karte fragt Ihr Browser die Kartendaten also nicht direkt bei OpenStreetMap an, sondern auf unserem Server. Unser Server leitet die Anfrage dann an OpenStreetMap weiter. OpenStreetMap kann daher nur den Zugriff über die IP-Adresse unseres Servers sehen. Ihre IP-Adresse bleibt verborgen. Zwar kann OpenStreetMap grundsätzlich auch datenschutzkonform mittels dem eigenen Hosten eines so genannten "Tile Servers" betrieben werden. Die Installation und Wartung eines solchen Servers ist jedoch so unverschämt kompliziert, dass sich das für die meisten Anwender nicht lohnen dürfte. Hier bleibt insofern in Zukunft zu hoffen, dass sich der Markt hierhingehend noch etwas öffnet und einfach zu verwendende, "out of the box" datenschutzkonforme Optionen hinzukommen. ZOOM & CO. Zoom, Microsoft Teams, Google Meet... na, kräuseln sich bei Ihnen auch schon die Nackenhaare? Viele dieser Videokonferenz-Tools werden von US-Unternehmen betrieben und sind insofern datenschutzrechtlich nicht unbedingt die besten Optionen. Dabei gibt es, ganz anders als bei Kartendiensten, zahlreiche datenschutzfreundliche Alternativen auf dem Markt. Eine beliebte Option ist unter anderem Jitsi Meet, da diese vollständig open-source ist und auf eigener Hardware bereitgestellt werden kann. Mittels ein paar kleinen, zusätzlichen Konfigurationen wie dem Deaktivieren der Gravatar-Einbindung werden damit keinerlei Verbindungen zu Drittservern mehr hergestellt. Selbst im Auslieferungszustand erfüllt Jitsi jedoch bereits die geltenden Datenschutzvorschriften. Wer lieber auf eine Cloud-Lösung setzt, könnte an der europäischen Videokonferenzsoftware Whereby gefallen finden. GOOGLE FONTS Zugegebenermaßen vielleicht etwas am Thema vorbei, da keine Cookies per se gespeichert werden, aber hinsichtlich der immer noch weiten Verbreitung mindestens genauso wichtig: Google Fonts. Grundsätzlich ist die Verwendung der hübschen, von Google zur Verfügung gestellten Schriftarten auch datenschutzrechtlich kein Problem. Wir verwenden mit "Inter" immerhin auch eine (welche Ihnen gerade das Lesen dieses Textes ermöglicht!). Das Problem, welches auf vielen Webseiten weiterhin besteht und in den letzten Wochen zu einer regelrechten Abmahnwelle geführt hat [https://www.e-recht24.de/google-fonts-scanner], ist die Einbindung der Fonts per Link-Tag zu den Servern von Google. Statt dessen müssen die Fonts zwingend lokal eingebunden werden, das heißt, auf dem selben Server gehostet werden wie der Rest Ihrer Webseite. Die Einbindung ist nicht allzu kompliziert und wird durch nützliche Tools wie den "Google Web Fonts Helper" [https://gwfh.mranftl.com/fonts] noch weiter vereinfacht.

Als moderne Digitalagentur versuchen wir stets, uns weiter fortzubilden und mit unserer Umwelt zu wachsen. Eine Technologie, die in den letzten Jahren rasant an Fahrt aufgenommen hat und inzwischen jedem ein Begriff sein dürfte, ist die Künstliche Intelligenz (KI / AI), bzw. um genau zu sein, Machine Learning. Unlängst ist diese Technologie in zahlreiche Branchen eingedrungen und macht Arbeitsabläufe einfacher, effizienter und kostengünstiger. Vor kurzem hatten wir die Möglichkeit, ein ML-Projekt für einen Kunden von Grund auf zu entwickeln und in der Praxis zu testen. Ein Erfahrungsbericht. WAS IST MACHINE LEARNING ÜBERHAUPT? Machine Learning ist eine Disziplin im breiteren Feld der "künstlichen Intelligenz". Bisher war es in der Softwareentwicklung so, dass ein Entwickler Regeln geschrieben hat, mit welcher ein Computer Eingaben verwerten und Ergebnisse ausgeben konnte. Im Vorfeld bekannt waren auf dem "klassischen Weg" daher stets die Eingaben und die Regeln. Die Ausgaben waren Unbekannte in der Gleichung. Machine Learning stellt dieses Konzept etwas auf den Kopf: Anstatt dem Computer Eingaben und Regeln zu geben, belassen wir die Regeln als Unbekannte und geben dem Computer somit nur noch die Eingaben - mitsamt dazugehörigen Ausgaben. Das hört sich vielleicht zunächst etwas komisch an, ist aber, zumindest oberflächlich, leicht erklärt. Wir füttern ein Machine Learning Modell mit tausenden von Eingabe-Ausgabe-Kombinationen (Trainingsdaten), woraufhin der Computer die Regeln, wie er von einer Eingabe auf eine dazugehörige Ausgabe kommt, selbst "erlernt". Dazu betrachtet er die Trainingsdaten in zahlreichen Durchläufen (auch "Epochen" genannt) und verändert dabei immer ein wenig die Gewichtung der Verbindungen zwischen den einzelnen Neuronen, die im KI-Modell definiert wurden. Damit funktioniert ein Machine Learning Modell ähnlich zum menschlichen Gehirn, nur sehr viel kleiner und weniger komplex. Ein KI-Modell kann daher nicht eigenständig denken oder gar empathisch werden. Statt dessen kann es nur innerhalb der vordefinierten Grenzen, also der gegebenen Trainingsdaten, lernen und handeln. Wenn im Training alles richtig läuft, kann ein optimales KI-Modell dann aus den gegebenen Trainingsdaten generalisieren, also die gelernten Regeln auf neue, noch nicht gesehene Eingaben, anwenden und zu schlüssigen Ergebnissen kommen. Damit das funktioniert, sind zahlreiche Komponenten essentiell, unter anderem die Qualität als auch Quantität der Trainingsdaten, die Aufbereitung dieser, die Anzahl der Epochen, die Hyperparameter (hierzu kommen wir später noch) und vieles mehr. FUSSBALL IST REINER ZUFALL! ODER? Vor einiger Zeit kam ein Interessent mit einer klaren Aufgabenstellung zu uns in die Agentur: "Entwickelt eine Fußball-Formel!". Okay, zugegeben: Vielleicht nicht ganz so im Wortlaut, aber Ziel des Projektes war es, Gewinnwahrscheinlichkeiten im Fußball für eine internationale Sportplattform zu berechnen. Das Prinzip dürfte einigen bereits aus dem Bereich der Sportwetten bekannt vorkommen. Sportwettenanbieter (Buchmacher) berechnen für jedes Spiel, auf welches auf ihrer Plattform gewettet werden kann, Wahrscheinlichkeiten für unterschiedlichste Spielereignisse, beispielsweise den Gewinner des Spiels oder die Anzahl der Tore. Buchmacher setzen hierfür auf eine Vielzahl an Algorithmen. Das Prinzip des Machine Learnings hingegen ist noch recht neu. Die Frage, die der Kunde mit diesem Projekt erörtern und beantworten wollte, war daher: "Kann ein Machine Learning Modell den Buchmacher schlagen?". Nach agilem Verfeinern der Projektanforderungen sowie dem Sammeln von tausenden Datensätzen aus vergangenen Spielen unterschiedlichster Fußballligen, u.a. der Bundesliga, legten wir also mit der Umsetzung los. DAS ERSTE TEST-MODELL Um uns mit den Daten vertraut und erste Gehversuche zu machen, haben wir uns direkt an ein erstes Test-Modell gesetzt. Bevor es aber an die eigentliche Entwicklung des Machine Learning Modells gehen kann, ist es zunächst wichtig, die Trainingsdaten so aufzubereiten, dass ein neuronales Netzwerk mit diesen überhaupt arbeiten kann. Für das erste Modell haben wir die folgenden Datenpunkte als Eingabeparameter verwendet: * Heim-Team-ID * Auswärts-Team-ID * Arena-ID * Saison (Jahr) * Spielrunde * Wochentag * Abendspiel * Heim-Team Ligapunkte * Auswärts-Team Ligapunkte Dies stellt unserer Ansicht nach eine solide Basis dar, um erste, sehr einfache Vorhersagen über den Spielausgang treffen zu können. Die IDs (Identifier) wie für die Teams und die Arena wurden "one-hot encoded". Würden wir diese nicht entsprechend enkodieren, könnte ein ML-Modell diese gegebenenfalls als einfache, numerische Werte betrachten und so falsche Schlussfolgerungen ziehen. Daher ist es wichtig, diese klar voneinander zu trennen, was in der Praxis oft durch eine One-Hot-Encoding geschieht, womit die Datenwerte in ein eindimensionales Array aus Nullen und Einsen überführt werden, in welchen jeweils genau ein Wert eine Eins ist, und alle anderen Werte eine Null. Andere Werte wie die Spielrunde oder die Ligapunkte haben wir hingegen als numerische Werte belassen. Auch haben wir für dieses Modell der Einfachheit halber alle Datensätze, in welchen einer oder mehrere dieser Datenpunkte gefehlt haben, entfernt. So ist garantiert, dass das ML-Modell mit möglichst "puren" und einfachen Daten lernt. ENTWERFEN DES MODELLS Im nächsten Schritt ging es um die Konzeption des eigentlichen ML-Modells. Auch hier haben wir uns für den ersten Prototypen auf ein möglichst einfaches Modell beschränkt, um dieses im Nachhinein bestmöglich optimieren und feinjustieren zu können. Für die Entwicklung des Modells wurde das bekannte Framework Tensorflow von Google verwendet sowie das darauf aufbauende bzw. abstrahierende Framework Keras. Mit Keras ist es sehr einfach, simple Modelle mit "vorgefertigten" Netzwerkschichten zu entwerfen. Um nicht zu sehr ins Technische auszuschweifen, sei an dieser Stelle gesagt, dass wir nach einigen Versuchen bei einem Modell mit einem eingehenden Flatten-Layer (welcher die Kombination aus one-hot-encoded und numerischen Werten in ein simples, eindimensionales Array konvertiert), zwei unsichtbaren Dense-Layern mit dazugehörigen Dropouts sowie einem Ausgangs-Layer gelandet sind. ERGEBNISSE UND AUSWERTUNG Zu unserem Glück begann mit Fertigstellung des ersten Prototypen gerade die neue Saison der Fußball-Bundesliga. Ein perfekter Moment, um die KI direkt live auszuprobieren. Nachdem jeder in der Agentur persönliche Wetten getroffen hat, durfte die KI an die Reihe. Zunächst war ein zugegebenermaßen eher einfaches Spiel an der Reihe: Eintracht Frankfurt gegen den FC Bayern München. Die KI prognostizierte einen Gewinn der Münchner zu 66%. Hätten die Münchner stattdessen den Heimvorteil gehabt, progonostizierte die KI eine Gewinnchance von über 75%. Schlüssig - und am Ende tatsächlich richtig. Die Bayern gewannen das Spiel 1:6. Interessant war, dass die prognostizierte Gewinnchance der Münchner mit voranschreitenden Spieltagen immer weiter stieg. Ein Zeichen dafür, dass der KI zu Beginn der Saison noch wichtige Daten fehlen, um wirklich überzeugende Vorhersagen zu treffen. Die grafische Auswertung anhand der Testdaten (also Datensätze, welche die KI im Trainingsprozess nicht gesehen hat, sondern welche nur für die Auswertung des Modells verwendet werden) war hingegen eher ernüchternd, wenn auch absolut den Erwartungen entsprechend:   Zu erkennen ist hier, dass die Präzision der Vorhersagen der KI bei rund 50% konvergiert. Somit liegt die Präzision definitiv weit höher als die reine Zufallswahrscheinlichkeit von 33% bei drei möglichen Spielausgängen (Heimsieg, Unentschieden, Auswärtssieg). Mit 50% kann jedoch noch kein Krieg gegen die Wettquoten der Buchmacher gewonnen werden. DAS ZWEITE MODELL "JARVIS" Also zurück an die Blaupausen. Basierend auf unseren Erfahrungen mit dem ersten Modell wurde dieses feinjustiert, auch wurden die verwendeten Datenpunkte angepasst und die Aufbereitung der Daten etwas modifiziert. Da es sich bei diesem Modell um das beim Kunden produktiv eingesetzte Modell handelt, können wir an dieser Stelle natürlich nicht allzuviele Details verraten. Jedoch haben wir die Datenpunkte beispielsweise um die Startaufstellungen sowie zahlreiche Details zu den jeweiligen Spielern ergänzt. Das Modell hat somit Gelegenheit, auch die einzelnen Aufstellungen zu betrachten und gegeneinander zu vergleichen. Das Alter der Datensätze wurde zusätzlich begrenzt, sodass keine Datensätze aus sehr alten Saisons, beispielsweise 2011, mehr ins Training einfließen. Abschließend haben wir die Hyperparameter des Modells feinjustiert. Die optimalen Hyperparameter, also beispielsweise der verwendete Optimizer, die Anzahl der versteckten Layer im Modell, oder auch die verwendete Loss-Funktion, sind Gegenstand zahlreicher Diskussionen in Entwickler-Communities und der Wissenschaft und für jedes Modell individuell. Eine beliebte und einfache Möglichkeit, diese zu optimieren, ist über einen automatischen Tuner wie "KerasTuner". Bei der Verwendung von KerasTuner wird das Modell mit immer verschiedenen Hyperparametern trainiert, welche wiederum über bestimmte Algorithmen stets angepasst werden. So werden die optimalen Rahmenbedingungen für die Funktionalität des Modells geschaffen. Nach erfolgreicher Erweiterung der verwendeten Datenpunkte sowie Feinjustierung der Hyperparameter konnte das Modell vollends überzeugen. Unser bestes Modell konnte eine Präzision (Accuracy) auf den Validierungsdaten von über 71% erreichen. Somit ist dieses Modell rund 42% besser als unser erstes Modell - ein voller Erfolg. Mit 71% wurde darüberhinaus etwas anderes geschafft: Die Gewinnwahrscheinlichkeit des Favoriten einiger, ausgewählter Buchmacher lag durchgehend bei knapp unter 71%. Somit konnte unser Modell bessere Werte als die von Buchmachern verwendeten Algorithmen erreichen. Natürlich mussten wir der künstlichen Intelligenz daraufhin auch einen Namen geben: Sie wurde liebevoll Jarvis getauft, angelehnt an die künstliche Intelligenz von Tony Stark in den "Iron Man" Filmen. TAKEAWAYS UND FAZIT An diesem praktischen Projekt kann gesehen werden, welche Erfolge bereits mit einfachen KI-Modellen in komplizierten Märkten erreicht werden können, und welche Dimensionen mittels der Optimierung der verwendeten Trainingsdaten und Hyperparameter erreicht werden können. Die Entwicklung von Machine Learning Modellen wird unser Agenturleben in den nächsten Jahren immer stärker begleiten - wir sind darauf vorbereitet.

Es ist längst kein Industriegeheimnis mehr, dass Google verschiedene Faktoren für das Ranking von Webseiten in ihrer Suche einsetzt und einer davon die Geschwindigkeit der jeweiligen Webseite ist. Doch was genau bedeutet es eigentlich, wenn man über die Geschwindigkeit einer Webseite, oder auch den "PageSpeed" dieser, spricht? In diesem Field Guide möchten wir Ihnen einen Einblick in die Web Vitals von Google geben, wie diese zum Ranking in der Suche beitragen und in welchem Maß und auch erste Tipps zur Optimierung der Web Vitals Ihrer Webseite mit auf den Weg geben. WAS SIND CORE WEB VITALS? Um die Core Web Vitals optimieren zu können, muss man erst einmal verstehen, worum es sich dabei eigentlich genau handelt. Zunächst: Oft werden "Web Vitals" und "Core Web Vitals" synonym verwendet, teilweise auch in Fachartikeln. Ganz korrekt ist dies jedoch nicht – bei den Core Web Vitals handelt es sich um eine Teilmenge der Web Vitals. Die Core Web Vitals bestehen aus nur drei Metriken der eigentlichen Web Vitals, welche laut Google für jede Webseite gemessen und optimiert werden sollten. Im weiteren Verlauf dieses Artikels werden wir uns daher selbstverständlich mit diesen Messwerten auseinandersetzen, jedoch auch mit anderen Daten der breiteren Web Vitals, die unserer Ansicht nach mindestens genauso wichtig sind. Aber zurück zum Ursprung: Bereits seit einiger Zeit stand Google in Verdacht, die Ladegeschwindigkeit einer Webseite als Rankingfaktor zu nehmen. Im Jahr 2021 hat Google dann ein Update für ihren Rankingalgorithmus heraus gebracht, in welchem erstmals ganz offiziell von solch einem Faktor die Rede war. Google wollte fortan die Seiten nach "Web Vitals" ranken. Eine Menge an vordefinierten Messwerten, welche die Geschwindigkeit und im engeren Sinn auch die Bedienbarkeit einer jeden Webseite messen, gewichten und auswerten können. Das Prinzip ist einfach zu verstehen: Google hat ein bestimmtes Bild davon, wie eine Webseite aufgebaut zu sein hat. Allerdings können sie den Inhalt und den Aufbau der Webseiten, die in der Suche angezeigt werden, nicht beeinflussen. Sehr wohl aber die Reihenfolge, in welcher sie angezeigt werden. Wenn Sie also planen, auf einen der Topränge in der Google-Suche für ein heißes Keyword zu kommen, werden Sie an der Optimierung Ihrer Web Vitals nicht vorbei kommen. In diesem Artikel werden wir uns hauptsächlich mit den nachfolgenden Web Vitals auseinander setzen: 1. Largest Contentful Paint (LCP). Diese Core-Metrik wertet aus, wie lang Ihre Webseite benötigt, um das größte Element im initialen Viewport dieser anzuzeigen. Das "größte Element" wird dabei mittels verschiedener Faktoren ermittelt. Google stellt jedoch Tools zur Verfügung, mit welchen sie einsehen können, was der Ansicht von Google nach das größte Element ist – und wo entsprechend Optimierungsbedarf besteht. 2. Cumulative Layout Shift (CLS). Diese Kennzahl ist ebenfalls in den Core Web Vitals enthalten und lässt sich leicht an einem Ihnen sicher schon einmal begegneten Beispiel erklären: Sie laden eine Webseite, auf der Sie vielleicht schon einmal waren. Sie wissen daher, dass es in der Mitte einen Button gibt, auf welchen Sie drücken müssen. Sie versuchen diesen noch während des Ladevorgangs zu betätigen – erwischen ihn jedoch einfach nicht, da sich das Layout der Webseite während des Ladevorgangs noch verschiebt. Für den Nutzer sehr ärgerlich, weshalb Google dies in die Berechnung des Performance-Scores mit einfließen lässt. 3. First Contentful Paint (FCP). Dieser Messwert ist zwar nicht in den Core Web Vitals enthalten (sondern nur in der Obermenge Web Vitals), ist unserer Ansicht nach jedoch einer der häufigsten Bruchstellen der Performance einer Webseite, weswegen wir uns dieser auch widmen müssen. Hier wird ausgewertet, wie lange es dauert, bis überhaupt irgendwas (soll heißen, etwas für den Nutzer sinnvolles) auf der Webseite angezeigt wird. Diese Metrik hängt natürgemäß stark vom Time To First Byte (TTFB) ab (ebenfalls nicht in den Core Web Vitals enthalten), welchem wir uns auch noch kurz widmen werden. 4. First Input Delay (FID). Diese Metrik ist wieder in den Core Web Vitals enthalten. Sie misst die Zeitspanne, die von der ersten Interaktion des Nutzers mit der Webseite (beispielsweise ein Klick auf einen Link) vergeht, bis es tatsächlich im Browser zu einer Reaktion auf diese Interaktion kommt. Der FID ist daher die Kernmetrik, die misst, wie responsiv die Webseite auf Nutzerinteraktionen ist. Es gibt innerhalb der Obermenge Web Vitals noch einige Messwerte mehr, welche jedoch einen kleineren Einfluss auf den Score haben, oder aber sehr selten zu Problemen führen, weshalb wir uns in diesem Artikel nur auf die oberen vier (bzw. fünf) Metriken beschränken werden. EIN PAAR RANDBEMERKUNGEN Die obigen Messwerte und ihr Gewicht innerhalb der Berechnung des Performance-Scores sind nicht in Stein gemeißelt. Google aktualisiert ihre Algorithmen regelmäßig, und so auch die (Core) Web Vitals. Dadurch können sich auch die benötigten Optimierungen immer wieder ändern. Wenn Sie daher nicht gerade SEO hauptberuflich ausführen, kann es schwierig sein, aktuell zu bleiben. Eine Digitalagentur, welche sich mit Core Web Vitals tiefgreifend auseinandergesetzt hat, kann Ihre Webseite nachhaltig optimieren. Bei Kuatsu haben wir bereits viel Zeit in die Optimierung von Kundenprojekten als auch unserer eigenen Webseite (mehr dazu gleich!) investiert. Falls Sie also Ihre Zeit lieber in das Voranbringen Ihres Unternehmens stecken und das Optimieren der Core Web Vitals einem professionellen Anbieter überlassen möchten, sprechen Sie uns gerne an.. Darüber hinaus sollten Sie beachten, dass Google die Web Vitals immer doppelt berechnet: Einmal für Mobilgeräte und einmal für Desktops. Die Desktop-Scores liegen im Prinzip immer höher als die Mobile-Scores, da Google bei der Berechnung letzterer auch eine künstliche Drosselung der Netzwerkgeschwindigkeit auf langsames 4G- oder gar 3G-Niveau vornimmt. Dabei sind die Mobile Scores eigentlich wichtiger als die Desktop Scores: Weltweit kommen laut einer Datenerhebung von StatCounter bereits mehr als 57% aller Seitenaufrufe von Mobilgeräten – Tendenz steigend. Die Optimierung Ihrer Webseite sollte daher stets primär auf Mobilgeräte ausgerichtet sein. Auf einem grünen Desktop-Score sollten Sie sich daher nicht zwangsweise ausruhen. WAS SIND MEINE WEB VITAL SCORES? Bevor es an die Optimierung geht, sollte man natürlich erstmal den Status quo analysieren um zu sehen, wo Optimierungen gerade am meisten benötigt werden. Dabei führen mehrere Wege nach Rom. GOOGLE PAGESPEED INSIGHTS Der einfachste Weg, an den Performance-Score der eigenen Webseite zu kommen, führt über die Google PageSpeed Insights [https://pagespeed.web.dev/]. Hier muss nur die URL zur zu prüfenden Seite eingegeben werden, und die Server von Google übernehmen die Messung. Hierbei gilt es jedoch zu beachten, dass bei der Messung über die PageSpeed Insights nicht nur die aktuelle Messung in einer kontrollierten Umgebung ("Lab Data") in den Score mit einfließt, sondern auch "Field Data". Google bezieht hier also die Erfahrungen von echten Nutzern mit ein, welche Ihre Webseite aufgerufen haben (beispielsweise über Google Chrome). Die Web Vitals lassen sich daher auch nicht austricksen, indem man bei einer kontrollierten Messung einfach sämtliche Bilder und Skripte entfernt. Google bezieht die Daten für die Scores auch von echten Sitzungen. Auch sollten Sie beachten, dass bei einer Messung über die PageSpeed Insights gegebenenfalls auch Ihr Serverstandort eine entscheidende Rolle spielt. Da die Messung über Googles Server erfolgt, kann es sein, dass erst eine sehr lange Verbindung zu Ihrem Server aufgebaut werden muss, was einige Scores natürlich katastrophal in den Keller ziehen kann. PageSpeed Insights misst von einem aus vier verschiedenen Standorten, basierend auf Ihrem aktuellen Standort: 1. Nordwesten der USA (Oregon) 2. Südwesten der USA (South Carolina) 3. Europa (Niederlande) 4. Asien (Taiwan) Die Abdeckung ist daher nicht schlecht, aber wenn Ihr Server beispielsweise in Australien steht, kann die Verbindung durchaus einige Zeit in Anspruch nehmen. Selbst aus den Niederlandern zu einem Rechenzentrum in Frankfurt vergeht bereits einige Zeit. Sie sehen also: Sie sollten sich nicht nur auf die PageSpeed Insights verlassen, da die Messung darüber nicht unbedingt die Erfahrungen echter Nutzer widerspiegelt. LIGHTHOUSE Lighthouse ist ein Open-Source Tool, welches direkt von Google bereitstellt wird, und neben den Web Vitals auch zahlreiche andere wichtige Metriken zu Ihrer Webseite erfasst, unter anderem die Barrierefreiheit oder On-Page SEO. Lighthouse läuft lokal auf Ihrem Rechner, simuliert jedoch eine kontrollierte Umgebung, in welcher die Messwerte genau genommen werden können. Das Beste daran: Oftmals müssen Sie dafür nicht einmal zusätzliche Software herunterladen, zumindest wenn Sie als Browser Google Chrome verwenden. Lighthouse ist direkt in den "Chrome Dev Tools" integriert, welche Sie per Rechtsklick, einem Klick auf "Untersuchen" im Kontextmenü und der anschließenden Auswahl von "Lighthouse" innerhalb der oberen Toolleiste aufrufen können. Als Beispiel einmal eine Mobile Performance-Messung unserer Webseite mittels Lighthouse über die Dev Tools: ANDERE WEGE Es gibt noch einige andere Wege, die Web Vitals zu messen, unter anderem über die Google Search Console. Diese richten sich aber eher an erfahrene SEOs. Für Anfänger, die die Performance der eigenen Webseite einschätzen wollen, eignen sich am besten die oben genannten PageSpeed Insights und Lighthouse. LARGEST CONTENTFUL PAINT (LCP): BEDEUTUNG UND OPTIMIERUNG Der Largest Contentful Paint (LCP) misst, wie lange es dauert, bis das größte inhaltliche Element innerhalb des initialen Viewports (also der Bereich, den der Nutzer bei Seitenaufruf sieht) fertig dargestellt ist. Das können beispielsweise große Banner-Bilder sein, große Textblöcke, Videos, Buttons, aber auch eher unscheinbare Elemente. Das größte, inhaltliche Element auf unserer neuen Webseite ist laut Google beispielsweise das Logo im Navigationsbereich. Aber keine Sorge: Um das jeweilige Element zu finden, ist keine große Schnitzeljagd von Nöten. Sowohl PageSpeed Insights als auch Lighthouse zeigen Ihnen das Element mittels einem Klick auf "LCP" direkt an. Google hat, wie bei jeder Metrik in den Web Vitals, sehr genaue Vorstellungen davon, wie schnell das Laden dieses Elements vonstatten zu gehen hat. Ein guter LCP ist demnach eine Ladezeit von unter 2,5 Sekunden, während alles über 4 Sekunden sehr schlecht ist und damit starken Handlungsbedarf hat. Alles dazwischen ist zwar in Ordnung, aber immer noch verbesserungswürdig. Und hinsichtlich der Gewichtung von 25% dieses Messwerts im Performance-Score sehen wir persönlich generell für alle Werte über 2,5 Sekunden einen dringenden Optimierungsbedarf. CHECKLISTE FÜR DIE LCP-OPTIMIERUNG Eine grundlegende Optimierung des LCP ist Gott sei Dank relativ einfach erledigt. Manchmal sind jedoch noch mehr tiefgreifende Optimierungen notwendig, um einen wirklich guten LCP-Wert zu erhalten. Die gängigsten Methoden zur Optimierung findest du aber hier in unserer Checkliste: * Verwendung eines Content Delivery Network. Ist das betroffene Element ein Bild, Video oder eine ähnliche, eingebundene Ressource, ist die naheliegendste Option, die Ladezeit dieser Ressource selbst zu verringern. Eine einfache Möglichkeit, dies zu bewerkstelligen, ist die Bereitstellung dieser Ressource über ein Content Delivery Network (CDN). Ein CDN ist ausschließlich darauf optimiert, Ressourcen wie Bilder so schnell wie möglich für jeden Nutzer auf dem Globus bereitstellen zu können. Dafür werden verschiedene Load Balancing Techniken eingesetzt. Durch Verbindung all dieser Techniken ergibt sich eine viel schnellere Ladezeit, als wenn die Ressource lokal vom eigenen Server bereitgestellt wird. Auch wird dadurch gleichzeitig Last vom eigenen Server genommen, welche anderswo sicher benötigt wird. Eine beliebte CDN-Lösung, welche auch wir auf unserer Webseite einsetzen, ist Cloudinary [https://www.cloudinary.com]. * Ressourcen komprimieren und in einem modernen Format bereitstellen. Oft wirst du über diese Empfehlung auch in den PageSpeed Insights oder Lighthouse stolpern. Prinzipiell sollten Ressourcen, auch das LCP-Element, so gut wie möglich komprimiert werden, um so wenig Datenverkehr wie möglich zu erzeugen. Für Bilder gibt es zahlreiche Tools, um diese verlustfrei zu komprimieren. Aber auch auf dem Webserver selbst sollte Kompression, beispielsweise mittels Gzip, aktiviert sein. Bilder sollten darüber hinaus bevorzugt in einem modernen Format wie WebP oder JPEG2000 bereitgestellt werden, da diese eine sehr viel geringere Dateigröße bieten. Da jedoch nicht jeder Browser diese Formate unterstützt, sollten als Fallback immer die alten, aber möglichst komprimierten, Formate vorliegen. Versuchen Sie auch, Rastergrafiken richtig zu dimensionieren und keine 1000x1000px große JPEG für ein kleines Logo im Navigationsbereich an den Nutzer zu senden. * Clientseitiges JavaScript- und CSS-Rendering minimieren. Es macht wenig Sinn, eine große Google Maps Bibliothek bereits bei Seitenaufruf in den Browser zu laden, wenn diese erst am Seitenende benötigt wird. Versuchen Sie, das verwendete JavaScript und CSS weitestgehend zu minimieren und jenes, das benötigt wird, möglichst im Ladezyklus der Webseite mittels async und defer nach hinten zu verschieben. Während JavaScript oder CSS in den Browser geladen wird, kann das Document Object Model (DOM), in welches die eigentliche HTML-Struktur Ihrer Webseite, und damit auch das LCP-Element, geladen wird, nicht weiter ausgebaut werden. CUMULATIVE LAYOUT SHIFT (CLS): BEDEUTUNG UND OPTIMIERUNG Der Cumulative Layout Shift (CLS) misst, vereinfacht gesagt, die visuelle Stabilität Ihrer Webseite während des Ladevorgangs. Um noch einmal das Beispiel von oben aufzugreifen: Stellen Sie sich einen Button vor, den Sie noch während des Ladevorgangs drücken möchten, der aber immer wieder seine Position ändert. Nervenaufreibend, nicht? Genau das soll mit einer Optimierung des CLS verhindert werden. Die CLS-Metrik spricht daher in erster Linie für eine gute Usability der Webseite. Kein Nutzer möchte versehentlich auf den Button klicken, der ihn zum Abschluss eines Jahres-Abos führt, wenn er eigentlich nur eine Ausgabe einer Zeitschrift erwerben wollte. Wie aber lässt sich diese Layout-Verschiebung in einen vergleichbaren Wert packen? Für Google ist dieser Wert das Produkt aus der sogenannten Impact Fraction und der Distance Fraction. Die Impact Fraction sagt aus, wie stark ein instabiles Element des Layouts den Viewport zwischen zwei Frames beeinflusst. Wie bitte? Nochmal anhand eines Beispiels: Stellen Sie sich ein Element vor, das bei Seitenaufruf 50% der Viewport-Höhe einnimmt. Durch ein instabiles Layout wird es jedoch plötzlich um 25% nach unten verschoben. Damit hat das Element nun eine Impact Fraction von 75% (also 0,75). Die Distance Fraction ist im Prinzip der bewegliche Anteil der Impact Fraction. In unserem Beispiel läge die Distance Fraction bei 25%, da sich das Element um diesen Wert verschoben hat. Besteht der CLS nur aus diesem Element, hätten wir also eine gesamte Impact Fraction von 0,75 und eine Distance Fraction von 0,25, was multipliziert miteinander einen CLS von 0,1875 ergibt. Dieser Score wäre laut Google ausbaufähig. Nur ein Score bis maximal 0,1 gilt als gut, alles über 0,25 als schlecht. CHECKLISTE FÜR DIE CLS-OPTIMIERUNG Nachdem wir die technischen Feinheiten geklärt haben, ist nun die Frage, wie wir diese Layout-Verschiebungen am besten verhindern können. * Mit Platzhaltern arbeiten. Laden Sie beispielsweise ein Button-Element während des Ladevorgangs per JavaScript nach und fügen dann einen Button oberhalb eines Textblocks ein, unterliegt der Textblock einem Layout Shift. Sie sollten daher mittels einem Platzhalter, der optimalerweise genauso groß wie der einzufügende Button ist, arbeiten, und diesen Platzhalter anschließend durch den Button ersetzen. So weiß der Textblock bereits zu Anfang, "wo er hin gehört" und wird nicht mehr verschoben. * Breiten und Höhen für Bilder definieren. Der Browser schafft während des Ladevorgangs automatisch Platzhalter für Bilder und Videos, wenn er weiß, wie viel Platz er frei halten muss. Dies kann er nur, wenn die jeweiligen Elemente mit Breiten- und Höhenangaben ausgestattet sind. * Webfonts während des Ladevorgangs durch System-Fonts ersetzen. Arbeiten Sie mit Webfonts, achten Sie stets darauf, dass für diese ein ähnlicher System-Font als Ersatz angegeben ist. Nicht nur können Sie so auch ältere Browser, die ggf. Webfonts nicht anzeigen können, unterstützen, aber auch wird der Text bereits angezeigt, bevor die jeweilige Font geladen wurde, sodass auch hier Layout Shifts vermieden werden. * Layout-Verschiebungen in Animationen vermeiden. Arbeiten Sie mit Animationen oder CSS-Übergängen, sollten Sie darauf achten, dass dadurch nicht das gesamte Layout verschoben wird, wenn beispielsweise die Größe eines Elements animiert wird. Auch hier sollten Sie ein Wrapper-Element schaffen, welches die maximale Größe des animierten Elements hat, sodass außenliegende Elemente nicht verschoben werden. FIRST CONTENTFUL PAINT (FCP): BEDEUTUNG UND OPTIMIERUNG Der First Contentful Paint (FCP) ist eng verwandt mit dem LCP und misst, wann das erste inhaltliche Element auf der Webseite angezeigt wird. Bis zum FCP ist die Webseite daher weiß und für den Nutzer unbrauchbar. Der FCP sollte selbstverständlich weit früher als der LCP sein. Google gibt einen Wert von unter 1,8 Sekunden als gut an, während alles über 3 Sekunden schlecht ist. Bei der Optimierung des FCP kommen viele Faktoren zusammen, welche teilweise auch direkte (positive) Auswirkungen auf die anderen Metriken haben. TIME TO FIRST BYTE (TTFB) ALS SUBFAKTOR FÜR DEN FCP Der FCP hängt naturgemäß stark davon ab, wie lang der Server benötigt, um das erste Byte an den Nutzer zu senden. Dieser Zeitraum wird auch Time To First Byte, oder auch TTFB genannt. Hierzu zählen Dinge wie die DNS-Anfrage, welche den Hostnamen (z.B. kuatsu.dev) in die IP-Adresse des Servers auflöst, oder auch SSL-Handshakes. All dies hat aber eine Sache gemeinsam: Sie sind Sache des Servers und können nur optimiert werden, indem der Server optimiert wird. Große, unübersichtliche Datenbanken können ein Grund für einen langen TTFB sein, oder auch schlechte Webserver-Konfigurationen. Die beste Konfiguration nützt jedoch nichts, wenn der Hosting-Provider schlichtweg nicht gut genug ist oder die Webseite von einem einzigen Server am anderen Ende der Welt im Vergleich zum Nutzer bereitgestellt wird. In der Checkliste für die FCP-Optimierung finden Sie auch einige Punkte, die direkt mit dem TTFB zusammenhängen. CHECKLISTE FÜR DIE FCP-OPTIMIERUNG Wir haben nun also erkannt, dass der FCP einer der wichtigsten Einflüsse auf die Nutzerzufriedenheit ist. Doch wie optimieren wie diesen Messwert? Hierzu gibt es unzählige Möglichkeiten, wovon Google zahlreiche in ihrem eigenen Blog-Eintrag [https://web.dev/fcp/#how-to-improve-fcp] vorstellt. Wir widmen uns einigen von diesen in unserer Checkliste. * CSS und JavaScript minimieren. Wir haben bereits weiter oben gelernt, dass das Document Object Model während des Ladevorgangs von JavaScript oder CSS noch nicht aufgebaut werden kann. Daher ist es selbstredend, dass diese möglichst minimiert werden müssen. Es gibt sogenannte "Minifier" oder "Uglifier", welche Ihr CSS und JavaScript nehmen und dieses mittels ausgeklügelter Methoden so klein schrumpfen lassen wie möglich. Nutzen Sie diese Möglichkeit. * Ungenutzes CSS und JavaScript entfernen. Eng verwandt mit der letzten Optimierungsmöglichkeit: Entfernen Sie CSS und JavaScript, das nicht benötigt wird. Hier kommt oft der Nachteil eeines großen WordPress Themes oder Ähnlichem zu Vorschein, welche oft mehrere Megabyte an CSS und JavaScript mit sich schleppen, welche für Ihre persönliche Webseite wahrscheinlich gar nicht benötigt werden. Für WordPress gibt es einige Plug-ins wie Asset CleanUp, mit welchen sie nicht benötigte Assets weitestmöglich entfernen können. Bei vielen Themes ist dies jedoch nicht immer perfekt möglich, weshalb die beste Lösung hier immer noch ist, auf vorgefertigte Themes zu verzichten und statt dessen ein eigenes Theme zu entwickeln oder auf einen auf Performance optimierten Page Builder wie Oxygen zu setzen. * Caching verwenden. Die meisten Webserver bieten eine Vielzahl an Möglichkeiten, Caching zu aktivieren. Dadurch werden bestimmte Ressourcen nicht bei jedem Seitenaufruf neu generiert, sondern für eine gewisse Zeit zwischengespeichert. Auch für WordPress gibt es einige Plug-ins, die in Verbindung mit den entsprechenden Webserver-Anpassungen für massive Verbesserungen im FCP-Wert sorgen können. Bei jeder von uns angefertigten WordPress-Webseite ist daher eine WP Rocket [https://wp-rocket.me/] Lizenz und Vorkonfiguration mit inbegriffen. * Server-Side Generation (SSG) verwenden. Zugegeben: Nun kommen wir an einen Punkt, wo nicht mehr von Optimierung die Rede ist, sondern von einer völlig neuen Webseite. Ein Static Site Generator wie Next.js erstellt statische HTML-Seiten und übernimmt einen Großteil des JavaScripts auf dem Server. Im Nutzer-Browser werden daher keine dutzenden API-Anfragen für das Anzeigen eines Blogs mehr gemacht, sondern der Server führt diese Anfragen noch vor dem Ladevorgang aus und stellt eine fertige HTML-Seite bereit. Übrigens: Auch wir verwenden Next.js und Static Site Generation. Bitte beachten Sie, dass sich einige der zuvor genannten Optimierungsmöglichkeiten, vor allem im Bereich des Largest Contentful Paint (LCP), mit jenen des FCP überschneiden, und wir diese deshalb hier nicht noch einmal aufzählen. FIRST INPUT DELAY (FID): BEDEUTUNG UND OPTIMIERUNG Der First Input Delay (FID) steht für die Zeit, die es benötigt, bis ein Nutzer auf Ihrer Webseite interaktiv eine Aktion ausführen kann. Klickt ein Nutzer also während des Ladevorgangs auf einen Button, dauert es diesen Zeitraum, bis eine Reaktion entsteht. Auch hier gibt Google Referenzwerte vor: Eine Zeit von unter 100ms gilt als gut, alles über 300ms hingegen als schlecht. CHECKLISTE FÜR DIE FID-OPTIMIERUNG Der First Input Delay kann sich als besonders knifflig bzw. technisch zu optimieren herausstellen. Oft ist es hier so, dass nur eine detaillierte Bestandsaufnahme der aktuellen Webseite und eine tiefgreifende, technische Optimierung einen schlechten FID beheben können. Hier sind jedoch einige Maßnahmen, die vorgenommen werden können: * Den Haupt-Thread entlasten. Das Rendering in JavaScript läuft über den Haupt-Thread. Werden in diesem jedoch gleichzeitig noch API-Anfragen und komplexe Berechnungen durchgeführt, muss das Rendering und damit auch die Reaktion auf eine Nutzerinteraktion warten. Dies kann beispielsweise durch den Einsatz von Web Workern oder dem Verwenden von asynchronem JavaScript behoben werden. * Auswirkungen von Third-Party Code minimieren. Verwenden Sie viele JavaScript-Bibliotheken wie Google Analytics, Google Maps, Facebook Pixel usw. spiegelt sich dies in der Interaktivität Ihrer Webseite wider. Solche Bibliotheken sollten Sie daher prinzipiell erst nach laden, nachdem das Document Object Model (DOM) fertig geladen wurde. Hierzu können Sie unter anderem die async oder defer Attribute im script-Tag nutzen. FAZIT Seit Juli 2021 sind die Core Web Vitals offizieller Bestandteil des Google Rankings und wurden spätestens dann zur Hausaufgabe eines jeden ernstzunehmenden SEOs. Doch nicht nur für eine gute Aufstellung in der Google-Suche sollten Sie diesen Messwerten Beachtung schenken: Am Ende stellen sie gute Metriken da, um die echte Bedienbarkeit und Nutzerfreundlichkeit Ihrer Webseite zu messen und zu vergleichen. Eine Digitalagentur, die sich auf die Optimierung der Web Vitals spezialisiert hat, kann daher nicht nur das Google Ranking verbessern, sondern auch für einen echten Mehrwert bei den Nutzern sorgen.

Bei der Entwicklung bzw. Planung einer neuen App stoßen die meisten schnell auf eine Frage: Hybrid oder nativ? Die meisten Apps sollen auf mehreren Systemen gleichzeitig laufen, meist iOS, Android und gegebenenfalls als Web App. Daher sollte man unbedingt die Vorteile, aber auch Nachteile sowie die Einsatzzwecke dieser beiden Ansätze verstehen. Beide dieser Herangehensweisen erfüllen ihren eigenen Zweck und passen für unterschiedliche Projekte. Wieso wir im Kundengespräch jedoch für die meisten Anwendungszwecke die Entwicklung einer hybriden App (oft auch cross-platform genannt und nicht zu verwechseln mit WebView Apps) empfehlen, möchten wir hier anhand von vier Vorteilen eben dieser aufzeigen. EINE EINZIGE CODEBASE Der größte Vorteil von hybriden Apps war es schon immer, dass nur eine einzige Codebase entwickelt und verwaltet werden muss. Während bei der nativen App-Entwicklung für jedes zu unterstützende System eine eigene App programmiert werden muss, verfolgt die hybride Entwicklung einen Universalansatz. Es wird nur eine einzige App geschrieben, welche anschließend in eine native App kompiliert wird um so auf den gängigen Systemen zu laufen. Der Vorteil liegt auf der Hand: Sowohl am Budget als auch der benötigten Arbeitszeit für die Entwicklung kann mächtig gespart werden. Anstatt mehrere Entwickler an verschiedenen Systemen arbeiten zu lassen, kann oft ein einziges Entwicklungsteam die Programmierung für alle Systeme im Raketentempo vornehmen. Dieser Vorteil ergibt sich nicht nur bei der ersten Entwicklung, sondern auch im weiteren Verlauf. Wenn neue Funktionen hinzugefügt oder die App anderweitig gewartet werden soll, sind Anpassungen binnen weniger Arbeitsstunden erledigt und auf allen Systemen gleichzeitig einsatzbereit. Dies spart nicht nur Kosten, sondern ist auch für die Nutzer umso erfreulicher. PERFORMANCE WIE DER GROSSE BRUDER Vor nicht allzu langer Zeit standen hybride Apps noch massiv in Verruf. Zu diesen Zeiten entstand gerade das noch heute sehr populäre Ionic Framework, welches eines der Vorreiter in seinem Bereich war. Leider hatten Apps, die damals auf diese Art und Weise programmiert wurden, ein massives Problem: Performance. Selbst für den Laien war es einfach, zu erkennen, dass eine App nicht für das jeweilige System optimiert war. Grafikfehler, Stotterer und Abstürze gehörten zur Tagesordnung. Inzwischen eilen hybride Apps, und die Frameworks in denen sie programmiert sind wie React Native [/blog/react-native-vor-und-nachteile], ihrem Ruf jedoch meilenweit voraus. Performance-Probleme gibt es inzwischen kaum noch. Ganz im Gegenteil erreichen diese sogar nahezu ähnliche Geschwindigkeiten wie rein native Apps. Der Nutzer kann in den meisten Fällen keinen Unterschied mehr feststellen. Dadurch setzen sie sich sehr stark von sogenannten WebView Apps ab, welche noch immer mit selbigen Problemen zu kämpfen haben. WebView Apps unterscheiden sich von hybriden Apps, welche zu nativen Apps kompiliert und optimiert werden, dadurch, dass diese einfach gesagt nur eine Webseite in einem Webbrowser, welcher in eine App verpackt wurde, anzeigen. Ein solcher Ansatz kann nie die Geschwindigkeit und Nutzererfahrung nativer und hybrider Apps erreichen. Auch hat ein solcher Ansatz das Problem, dass viele Systemfunktionalitäten wie der Nutzerstandort oder Push-Benachrichtigungen nicht verwendet werden können. Bei einer hybriden App ist dies hingegen kein Problem. Heutzutage lässt sich sagen, dass alles, was mit einer nativen App entwickelt werden kann, auch mit einer hybriden App umsetzbar ist. GROSSARTIGE USER EXPERIENCE Dieser Punkt geht Hand in Hand mit dem vorherigen Punkt. Durch die nahezu native Performance hybrider Apps und der Möglichkeit, System-APIs wie Apple Health, HomeKit oder ähnliche einzubauen, ergibt sich eine fantastische Nutzererfahrung. Und selbst wenn eine Systemfunktionalität mal nicht von Haus aus vom verwendeten Framework verwendet wird, ist es für einen erfahrenen Entwickler möglich, diese mit relativ wenig Aufwand nachzurüsten. OFFLINE-NUTZBARKEIT In diesem Punkt stellen wir die hybride App weniger in den Vergleich zur nativen App, sondern viel mehr zum „kleinen Bruder“ – der WebView App. Der Kernvorteil gegenüber einer solchen liegt nämlich darin, dass die App unabhängig von einer bestehenden Internetverbindung genutzt werden kann. Die App ist mitsamt allen benötigten Funktionalitäten auf dem Gerät des Nutzers installiert und muss sich daher nicht bei jedem Öffnen neu laden. Zugegeben: Durch cleveren Einsatz von Caching können viele Web Apps inzwischen auch offline laufen (man spricht dann auch von einer PWA, also einer Progressive Web App). Oft ist es jedoch so, dass hier bestimmte Features trotz dessen nicht ohne Internetverbindung funktionieren, da diese nicht auf alle System-APIs zurückgreifen können und so oft eine dauerhafte Serververbindung benötigen. Dieses Problem gibt es beim Einsatz von hybriden Apps nicht. Auch ist die Entwicklung einer hybriden App inzwischen oft günstiger als die einer offline verfügbaren Progressive Web App. EIN KLEINER DISCLAIMER… Auch wenn wir von der hybriden App-Entwicklung absolut überzeugt sind, so eignet sie sich jedoch nicht für alle Arten von Projekten. In bestimmten Fällen macht es durchaus Sinn, native Apps für jedes zu unterstützende System zu entwickeln. Insbesondere wenn herausragende Performance wichtig für die Funktion der App ist, kann eine hybride App – trotz der sich immer weiter verbessernden Performanz dieser – vielleicht nicht mehr mithalten.

Bereits seit einiger Zeit stellt TypeScript unsere primäre Sprache dar, sowohl für interne Projekte als auch Kundenprojekte. Bereits seit Beginn arbeiten wir hauptsächlich mit JavaScript (in Kombination mit einigen Frameworks wie React und NodeJS), da die Flexibilität und der vielseitige Anwendungsbereich der Sprache es uns ermöglichen, eine Codebase in derselben Sprache für ein gesamtes Projekt, inklusive Web und Mobile App sowie Backend, zu nutzen. Nicht lang ist es her, dass wir all unsere aktuellen Projekte einer TypeScript Migration durchzogen haben. Auch wenn jedes JavaScript-Projekt technisch gesehen ein gültiges TypeScript-Projekt ist, da TypeScript ein Superset von JavaScript darstellt, so ist nicht automatisch jedes JavaScript-Projekt auch ein gutes TypeScript-Projekt. Fügen Sie TypeScript zu einer bestehenden JavaScript-Codebase hinzu, so werden alle Variablen, Konstanten und Objekte, welche sich nicht aus dem engeren Kontext für den Compiler ergeben, als vom Typen any betrachtet. Dass dies nicht im Sinne des Erfinders ist, dürfte klar sein. TypeScript wurde eben mit dem Hintergedanken entwickelt, strikte Typen in JavaScript nutzen und auf dynamische Typisierung weitgehend verzichten zu können. Als Entwickler sind Sie also gezwungen, für viele dieser Objekte händisch die Typisierung vorzunehmen. Logisch, dass sich dabei zwei Mal überlegt wird, ob dies wirklich notwendig ist und der Nutzen den Kosten bzw. dem Zeitaufwand überwiegt. Zwar gibt es inzwischen zahlreiche Tools und Programme, wie „ts-migrate“ von Airbnb [https://medium.com/airbnb-engineering/ts-migrate-a-tool-for-migrating-to-typescript-at-scale-cd23bfeb5cc] (welche TypeScript ebenfalls als offizielle Frontend-Sprache nutzen!), welche die Migration zu TypeScript vereinfachen sollen. Doch auch diese sind selbstredend bei weitem nicht perfekt und verhindern auch nicht das manuelle Typisieren von Objekten. Computer sind schließlich nicht wirklich gut darin, die Semantik hinter Ihrem Code zu verstehen (auch wenn sich dies in Zeiten von Deep Learning und KIs wie GitHub Copilot rasant ändert). Nun stehen wir also vor einem Dilemma: Migrieren – oder die alten Codebases weiter verwalten? WARUM TYPESCRIPT EINFACH BESSER IST Bevor wir uns also der Frage widmen, ob die Migration bestehender JavaScript-Projekte sinnvoll ist, schauen wir uns zunächst einmal die zwei größten Vorteile von TypeScript an. * Der TypeScript Compiler (TSC). Der unserer Ansicht nach größte Vorteil bei der Nutzung von TypeScript liegt im Compiler. JavaScript ist normalerweise eine interpretierte Skriptsprache, welche vom Browser während der Laufzeit interpretiert und ausgeführt wird. Eine Kompilierung ist daher nicht notwendig. TypeScript wird zu JavaScript transkompiliert (wodurch der Browser den kompilierten Code wiederum als normales JavaScript interpretieren kann). Der Vorteil liegt hierbei vor allem darin, dass TypeScript-Code auch zu älteren JavaScript- / ECMAScript-Versionen transkompiliert werden kann. So können Sie auch dann moderne Funktionen wie Promises nutzen, wenn Sie Ihre Anwendungen für ältere Browser bzw. Umgebungen bauen. TypeScript kümmert sich darum, die Features in äquivalente Strukturen der avisierten JavaScript-Version zu kompilieren. * Fehlererkennung zur Build-Zeit. Selbstverständlich bringen interpretierte, und nicht kompilierte Sprachen auch Vorteile wie schnellere Entwicklungsabläufe mit sich, jedoch auch einen gravierenden Nachteil. Viele Fehler, die normalerweise ein Compiler auffangen könnte, fallen erst während der Laufzeit auf. TypeScript kann hier in der größten Kategorie nachhelfen, den Typfehlern. Jeder/Jedem JavaScript-Entwickler:in wird es irgendwann einmal passiert sein, dass sie / er versehentlich auf Attribute von undefined oder null zugreifen wollte. TypeScript kann solche Fehler noch verhindern, bevor es die Anwendung in die Staging- oder gar Produktionsumgebung schafft. WARUM UND WIE WIR ALLE (AKTUELLEN) PROJEKTE MIGRIERT HABEN Gründe für die TypeScript Migration gibt es also reichlich. Doch lohnt es sich wirklich, auch bestehende, zum Teil riesige Codebases zu migrieren? Die Antwort, die wir uns auf diese Frage gegeben haben, war ein ganz klares Ja. Nachdem wir TypeScript für einige neue Projekte bereits länger verwendet haben und in den Genuss statischer Typisierung in JavaScript gekommen sind, fiel die Entscheidung mehr als leicht. Die Umsetzung hingegen ist eine andere Hausnummer. Viele unserer laufenden Kundenprojekte in JavaScript waren mehrere zehntausend Zeilen lang – wo also anfangen? DEN STATUS QUO BESTIMMEN. Wenn Sie nicht schon zuvor mit TypeScript-„Alternativen“ wie JSDoc gearbeitet haben, ist die Wahrscheinlichkeit hoch, dass Sie recht wenig Ahnung haben, welche Funktion eigentlich welche Typen verwendet. Man sollte sich daher zunächst eine Übersicht über den aktuellen Stand verfassen. Mit welchen Schnittstellen spricht die Anwendung? Welche Daten werden gelesen und geschrieben? Ist die Herkunft dieser Daten typsicher? Eine großzügige Dokumentation des Codes macht sich spätestens hier bemerkbar. DEN „STRICT“ MODE AKTIVIEREN. Generell macht TypeScript unserer Ansicht nach so richtig nur mit Nutzung im „Strict“ Modus Sinn. Ohne Aktivierung dessen spendiert TypeScript zwar weit mehr Bewegungsspielraum, indem beispielsweise implizites Any erlaubt wird. Genau das soll jedoch durch die Migration verhindert werden. Wir möchten dynamische und nicht-statische Typen verbieten, weshalb wir uns durch fehlende Nutzung des Strict Mode ein eigenes Loch buddeln. Als wir unsere ersten Projekte zu TypeScript migriert haben, haben wir unsere Projekte stets zunächst im „Non-Strict“ Modus von TypeScript migriert. Erst im Anschluss haben wir den Strict Mode aktiviert und die restlichen Fehler ausgeweidet. Wir haben jedoch schnell festgestellt, dass dies nicht die effektivste Methode ist. Aktivieren Sie den Strict Mode bereits zu Anfang der Migration. Sie werden sich im weiteren Verlauf viel Kopfzerbrechen sparen. Fehlerbehebungen und Optimierungen, die Sie im ersten Schritt durchführen, müssen teils nach Aktivierung des Strict Modes wieder gänzlich verworfen werden. Auch wenn der Fehler-Tab in Ihrer Entwicklungsumgebung Sie vielleicht einschüchtern mag: Nutzen Sie von Anfang an den Strict Mode. DEKLARATIONSDATEIEN INSTALLIEREN Ein Großteil der von TypeScript angezeigten Fehler stammt wahrscheinlich gar nicht von Ihrem Code, sondern entspringt dem node_modules Ordner. Dies liegt schlicht daran, dass in den meisten Modulen keine Typdeklarationen von Haus aus dabei sind. Glücklicherweise gibt es von der Open-Source-Community nahezu zu jedem Modul passende Typdeklarationen. Zu einem Modul „some_module“ können Sie diese in der Regel mit $ npm install @types/some_module installieren. Hat Ihre Anwendung jedoch einen sehr spezifischen Anwendungszweck und nutzen Sie daher auch sehr spezielle Libraries, so kann es vorkommen, dass keine passenden Typdeklarationen vorliegen. Anstatt diese Libraries nun jedoch einfach als Any zu deklarieren, investieren Sie die Zeit und legen Sie Typdeklarationen an. Tech Debt ist ein echtes Problem – und Sie möchten sich zu diesem Zeitpunkt nicht darin verwickeln. KLASSEN UND FUNKTIONEN MIGRIEREN Bevor Sie sich den Kleinteilen zuwenden, ist es eine gute Idee, zunächst die verwendeten Klassen, Funktionen und größeren Objekte Ihrer Anwendung zu typisieren. Es ist wahrscheinlich, dass diese immer wieder im Code verwendet werden. Dadurch eignen sich diese als erster Kandidat, da die Typisierung der anderen Variablen und Objekte sich so später weitaus einfacher gestalten wird. Wir haben uns bei unserer Migration daher zunächst Dinge wie Middlewares, Models usw. vorgenommen. Indem wir diesen möglichst genaue Typen gaben, fiel es in den kleineren Funktionen und Abschnitten des Codes später weitaus einfacher, diese zuzuordnen und zu typisieren. Achten Sie darauf, bei der Typisierung möglichst streng, aber nicht zu streng vorzugehen: TypeScript ist ein sehr mächtiges Werkzeug, und Sie können Ihre Typen so streng machen, wie es Ihnen beliebt. Allerdings, „don’t over-engineer“! Sich in den Typen zu sehr auszutoben macht vom Kosten-Zeit-Faktor ab einem bestimmten Punkt nur noch wenig Sinn. OTHER STUFF… Ein Großteil der Arbeit wurde nun in recht kurzer Zeit erledigt. Nun geht es jedoch an die Kleinigkeiten. Erfahrungsgemäß reicht es hier meist, Variablen und Co. einen der vorgefertigten Typen wie „string“ zu geben. Auch hier gilt das bekannte Don’t Over-Engineer Prinzip. Auch Ihre Tests sollten Sie an TypeScript anpassen. Viele der bekannten Test Frameworks sind für TypeScript optimiert und arbeiten damit problemlos. FAZIT TypeScript ist womöglich das Beste, was JavaScript in den letzten Jahren passiert ist. Der Trend geht laut den letzten StackOverflow Surveys [https://insights.stackoverflow.com/survey/2021] immer weiter in Richtung statisch typisierte Sprachen. Die Flexibilität von JavaScript und eine sichere Typisierung machen so jedes Projekt zukunftssicher und einfach zu verwalten. Seit unserer vollständigen TypeScript Migration ist es bei uns de-facto Standard, und wir möchten es nicht mehr missen.