Ein entscheidender Schl\u00fcssel f\u00fcr diese signifikanten Anstieg war f\u00fcr Rakuten dabei neben der Bildoptimierung und Anpassung der CSS-Dateien vor allem auch eine Verbesserung und Reduktion des JavaScript-Codes der Seite. [2] <\/p>\n\n\n\n
Mit Blick auf die untere Abbildung scheint diese Ma\u00dfnahme wichtiger denn je zu sein. Heutige Webseiten- und Applikationen bieten Usern mehr M\u00f6glichkeiten als noch vor 10 oder 15 Jahren und ein nie zuvor dagewesenes Ma\u00df an Interaktivit\u00e4t und Funktionalit\u00e4t im Web. Diese Entwicklung resultiert jedoch in einer deutlichen Zunahme des ben\u00f6tigten JavaScript-Codes, tendenziell weiter steigend, wodurch sich im Bereich der Webentwicklung mittlerweile immer mehr die Frage stellt: Wie kann JavaScript reduziert und die Auslieferung an den Browser verbessert werden? [3] <\/p>\n\n\n\n
In diesem Artikel wird nach einem \u00dcberblick \u00fcber Trends und Ans\u00e4tze des Web Developments der letzten Jahre und den damit entstandenen Problemen das Framework Qwik in den Fokus ger\u00fcckt. Dessen neuer Ansatz der Resumability soll dabei im Kontext der Performance von Webapplikationen genauer beleuchtet und in einer prototypischen, praktischen Anwendung mit bisherigen Standards verglichen werden.<\/p>\n\n\n\n
![](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2024\/02\/v3vfQZ0g2RQOZ1wlF34TFz1kZQ01zOYO-9in5xDgtoYMODmJ4lctGo4nKRaKj4ScNWOzs7sqiZoZqdoxpjxEmbNGixkPIs9LkLVjfMUb43mCnQRDi8rcjWILA1n6LmALtpFhDvKtlDkgGwsW3rY5OqA.png\")
<\/p>\n\n\n\n
Ein \u00dcberblick \u00fcber die Geschichte der Webentwicklung<\/strong><\/p>\n\n\n\n In seinen anf\u00e4nglichen Jahren war das Web noch weit entfernt von den hochinteraktiven Anwendungen, die wir heute nutzen. Statische Inhalte wurden als HTML-Dokumente auf den Servern bereitgestellt und auf Anfrage des Clients ausgeliefert. Erst mit der Einf\u00fchrung des Document Object Models als Schnittstelle zwischen zu den HTML-Dokument und dem Aufkommen von JavaScript, konnten nun auch mit Hilfe von Programmiersprachen wie PHP oder Java dynamische und personalisierte HTML-Inhalte auf der Serverseite erzeugt werden, die zudem auch noch im Browser auf Eingaben der Nutzer reagierten. [4]<\/p>\n\n\n\n Mit der wachsenden Komplexit\u00e4t von Webanwendungen und dem Bedarf an effizienter Codeverwaltung und Strukturierung schreiben immer mehr Entwickler kleine, hilfreiche Tools in wiederverwendbaren Paketen. Aus den losen Ansammlungen von verschiedenen Funktionen in Bibliotheken entstanden schlie\u00dflich feste Programmierger\u00fcste, sogenannte Frameworks, die es den Entwicklern erleichtern sollten, moderne und interaktive Webanwendungen zu erstellen. [5]<\/p>\n\n\n\n Mit dem Durchbruch von Frameworks wie Angular, React oder Vue hat sich der HTML-Rendering-Prozess von der Server- auf die Clientseite verschoben. Bei diesen sogenannten Single Page Apps l\u00e4dt die initiale Anfrage lediglich eine minimale HTML-Datei, die in der Regel nur ein leeres Root-Element sowie Links zu den entsprechenden JavaScript-Files enthalten. Diese werden nun angefragt, kompiliert, ausgef\u00fchrt und so die HTML-Elemente dynamisch erzeugt und auf dem Display f\u00fcr den User ausgegeben. [6]<\/p>\n\n\n\n Single Page Applications mit clientseitigem Rendering k\u00f6nnen zum einen die Server entlasten. Zudem sind diese nach dem ersten Ladevorgang sehr fl\u00fcssig und f\u00fchlen sich f\u00fcr die Nutzer oftmals wie eine native App an. Da bei erstmaligem Aufruf der Seite zun\u00e4chst alle zus\u00e4tzlichen JavaScript- und CSS-Dateien heruntergeladen und verarbeitet werden m\u00fcssen, sieht der Nutzer bei dem ersten Ladevorgang f\u00fcr einige Zeit nur einen leeren Screen. Aufgrund dessen, dass die ungerenderte HTML-Seite zun\u00e4chst nur ein leeres Element enth\u00e4lt, haben auch die Crawler der Suchmaschinen Probleme, den Inhalt der Seite richtig zu erfassen, was sich negativ auf die SEO auswirkt. [7]<\/p>\n\n\n\n Meta-Frameworks und das Problem der Hydration<\/strong><\/p>\n\n\n\n Aus diesen Gr\u00fcnden wurden gegen Ende der 2010er Jahre Erweiterungen und neue Technologieans\u00e4tze entwickelt, die die Nachteile der Single Page Apps ausgleichen sollten. Diese sogenannten Meta-Frameworks wie beispielsweise Next.js f\u00fcr React oder Nuxt.js f\u00fcr Vue bauen auf den Grundlagen der SPA-Frameworks auf, bieten jedoch neue Funktionalit\u00e4ten und M\u00f6glichkeiten f\u00fcr das Erstellen von Multi-Page-Anwendungen mit Server Side Rendering (SSR<\/em>) oder Static Site Generation (SSG<\/em>). Hier werden die HTML-Inhalte nicht erst auf dem Client erstellt, sondern \u00e4hnlich wie in den Anfangszeiten des Webs nach eingehendem Request auf dem Server gerendert bzw. bei der Static Site Generation als statische Assets gehostet und anschlie\u00dfend ausgeliefert. [4]<\/p>\n\n\n\n Anstatt leeres HTML zu senden, das dann im Client von Grund auf neu gebaut werden muss, sehen die User so nach dem Seitenaufruf zum einen deutlich schneller die Inhalte und auch die Crawler der Suchmaschinen k\u00f6nnen den Content besser indexieren. Diese Rendering-Technologie l\u00f6st jedoch nur einen Teil des Problems. Zwar scheint die Seite schnell geladen zu sein, der User kann jedoch noch nicht mit ihr interagieren. So muss zus\u00e4tzlich JavaScript-Code geladen und mit dem serverseitig erzeugten HTML verbunden werden, damit die Webanwendung auch wirklich interaktiv ist. [4] <\/p>\n\n\n\n Was versteht man unter Hydration?<\/strong><\/p>\n\n\n\n Um dieses Ziel zu erreichen, wird die sogenannte Hydration (dt. Hydratation<\/em>) als L\u00f6sung genutzt, um dem vom Server gesendeten, statischen HTML wieder Event Handler hinzuzuf\u00fcgen und den State der Anwendung initialisieren, sodass diese wieder im Browser dynamisch und interaktiv ist. [8] <\/p>\n\n\n\n Die technische Herausforderung bei der Hydration besteht nun jedoch darin, zu wissen, welche Event Handler ben\u00f6tigt werden und an welchen Stellen sie an das HTML angeh\u00e4ngt werden m\u00fcssen. Dies ist besonders komplex, da die Event Handler als innere Funktionen, sogenannte Closures auf den Kontext, in dem sie erstellt wurden, zugreifen m\u00fcssen (z.B. den State der Anwendung, Variablen oder andere Funktionen). Da die Closures meist tief in die Komponenten eingebettet sind und nicht auf oberster Ebene exportiert werden k\u00f6nnen, muss nun zum Wiederherstellen des States und dem Anbringen der Handler der Code aller Komponenten des aktuellen HTML-Dokuments noch einmal heruntergeladen und ausgef\u00fchrt werden. Der Prozess der Hydration l\u00e4uft dabei typischerweise in vier Phasen ab: <\/p>\n\n\n\n Das Problem der Hydration<\/strong><\/p>\n\n\n\n Besonders die ersten drei, der oben beschriebenen Phasen, in denen der Code der Komponenten heruntergeladen, ausgef\u00fchrt und die State-Informationen wiederhergestellt werden, sind recht zeitaufwendig. Da der Wiederherstellungsprozess proportional zur Komplexit\u00e4t der zu hydrierenden Anwendung ist, kann dies vor allem bei gr\u00f6\u00dferen Seiten zu einer schlechten Performance f\u00fchren und beispielsweise auf mobilen Ger\u00e4ten bis zu 10s dauern. [9]<\/p>\n\n\n\n Es entsteht redundanter Aufwand, da Informationen, die im Backend bereits w\u00e4hrend des serverseitigen Renderings gesammelt und verworfen wurden, sp\u00e4ter vom Client wiederhergestellt werden m\u00fcssen. Nachdem zun\u00e4chst das gerenderte HTML \u00fcbertragen wird, erfordert die Hydration ein zweites Senden der Anwendung als JavaScript an den Client und das erneute Ausf\u00fchren des Framework-Codes. Dies f\u00fchrt zu \u201cOverhead\u201d und einer unn\u00f6tigen Duplizierung der Arbeit von Server- und Browser. [9]<\/p>\n\n\n\n Die Hydration bietet somit zwar eine L\u00f6sung, die HTML-Elemente des DOM bei serverseitig gerenderten Anwendungen wieder mit dem JavaScript des Frameworks zu verkn\u00fcpfen. Allerdings wird dieser Ansatz aufgrund der zuvor beschriebenen Nachteile von vielen Entwicklern problematisch gesehen. So beschreibt Misko Hevery die Hydration als \u201cschreckliche Umgehung, da die Frameworks nicht ber\u00fccksichtigen wie Browser tats\u00e4chlich funktionieren\u201d [10] und Ryan Carniato kritisiert, dass der JavaScript-Payload dadurch oftmals erh\u00f6ht wird und es meist sogar l\u00e4nger als bei einem clientseitigen Rendering dauert, bis die Anwendung vollst\u00e4ndig geladen und interaktiv ist. [8]<\/p>\n\n\n\n Das Framework Qwik.js<\/strong><\/p>\n\n\n\n Im Jahr 2021 versuchen die Verantwortlichen hinter dem CMS-Tool Builder.io unter der Leitung von Misko Hevery, fr\u00fcher Teil des Teams von Angular und einer der Pioniere der modernen Webentwicklung, dieses Problem zu l\u00f6sen und ver\u00f6ffentlichen das neue JavaScript-Framework Qwik in einer ersten Version. [4] <\/p>\n\n\n\n Ein \u00fcbergeordnetes Ziel von Qwik ist es, performante und direkt interaktive Anwendungen zu liefern, unabh\u00e4ngig von deren Gr\u00f6\u00dfe oder Komplexit\u00e4t und ohne dass sich der Entwickler dabei dar\u00fcber Gedanken machen muss. Laut CTO Hevery liegt die eigentliche St\u00e4rke des Frameworks jedoch nicht in seiner Geschwindigkeit selbst, sondern darin, \u201cdass es gekonnt jegliche Arbeit vermeidet\u201d. M\u00f6glich wird dies dadurch, dass Qwik nicht wie viele andere SSR-Frameworks Hydration nutzt, sondern auf das neue Konzept der Resumablilty setzt. [10]<\/p>\n\n\n\n Was versteht man unter Resumability?<\/strong><\/p>\n\n\n\n Der Begriff Resumability l\u00e4sst sich am besten mit \u201cWiederaufnahmef\u00e4higkeit\u201d \u00fcbersetzen und beschreibt im Kontext von Qwik, die F\u00e4higkeit die Ausf\u00fchrung der Anwendung nach \u00dcbertragung vom Server auf den Client, dort wieder aufzunehmen und fortzusetzen, ohne dass wie bei der Hydration die gesamte Anwendungslogik erneut heruntergeladen und ausgef\u00fchrt werden muss. Durch diesen Ansatz sind Qwik-Applikationen nach der \u00dcbertragung des HTML und einer 1kB kleinen JavaScript-Funktion, dem QwikLoader, fertig geladen. [11]<\/p>\n\n\n\n Um die Anwendung interaktiv zu machen, m\u00fcssen auch hier wieder, wie bei allen serverseitig gerenderten Anwendungen, die Event Listener mit den Elementen des DOM verkn\u00fcpft werden. W\u00e4hrend dies bei anderen Frameworks typischerweise durch die oben beschriebenen Schritte der Hydration erreicht wird, l\u00f6st Qwik diese Aufgabe, indem alle daf\u00fcr ben\u00f6tigten Informationen beim SSR-Prozess gesammelt und im HTML als sogenannte QLRs (Qwik URL<\/em>) serialisiert werden. [11]<\/p>\n\n\n\n Diese lassen sich als spezielle Form von URLs beschreiben, die aus einem Pfad zur Ressource und einem Symbolnamen hinter der Raute bestehen, die zus\u00e4tzliche Informationen zum State oder Referenzfunktionen beinhalten. Der QwikLoader dient nun dabei als globaler Event Listener f\u00fcr alle Browser Events. Tritt ein Event durch eine Nutzerinteraktion ein, durchsucht der QwikLoader das DOM f\u00fcr das entsprechende Attribut mit der zugeh\u00f6rigen QRL, sodass der einzelne Chunk geladen und ausgef\u00fchrt werden kann.<\/p>\n\n\n\n Auf diese Weise wei\u00df die serverseitig gerenderte Qwik-Applikation auch im Client, wo Events registriert sind und welcher Code beim Eintreten ausgef\u00fchrt werden muss. W\u00e4hrend bei der Hydration der vollst\u00e4ndige Komponenten-Baum der Anwendung ab der Wurzel geladen werden muss, gen\u00fcgt bei Qwik zu Beginn durch die Serialisation in das HTML nur der 1kB gro\u00dfe QwikLoader wodurch ein redundantes Ausf\u00fchren der kompletten Anwendung im Client nicht mehr n\u00f6tig ist. [12]<\/p>\n\n\n\n Bei kleineren, serverseitig gerenderten Webanwendungen stellt die anschlie\u00dfende, zus\u00e4tzliche Hydration normalerweise kein Problem dar und die Ladeperformance wird nur marginal und f\u00fcr den User nicht merklich beeinflusst. Anhand der oberen Abbildung links l\u00e4sst sich erkennen, dass bei den herk\u00f6mmlichen Meta-Frameworks mit zunehmender Komplexit\u00e4t und mehr Komponenten jedoch immer mehr JavaScript-Code heruntergeladen werden muss, um diese zu hydrieren. Bei Qwik-Anwendungen hingegen steigt die initiale JavaScript-Bundlegr\u00f6\u00dfe nicht proportional zur Gr\u00f6\u00dfe und Komplexit\u00e4t der Anwendung, sondern bleibt konstant, wodurch die Performance sehr gut skalierbar ist. [13]<\/p>\n\n\n\n Durch das Prinzip der Resumability l\u00e4sst sich in Qwik wie auf der rechten Seite der Abbildung Lazy-Loading umsetzen, bei dem nach und nach bei jeder Interaktion des Nutzers mit einer Komponente das entsprechende JavaScript heruntergeladen und ausgef\u00fchrt wird. So muss auch nur der wirklich ben\u00f6tigte Code abgerufen werden, w\u00e4hrend bei herk\u00f6mmlichen Frameworks der aller Komponenten ben\u00f6tigt wird, ganz egal ob der User sp\u00e4ter mit diesen interagiert oder nicht. [13]<\/p>\n\n\n\n Syntax in Qwik<\/strong><\/p>\n\n\n\n Betrachtet man ein St\u00fcck Code einer Qwik-Anwendung, so wird dies zumindest Entwicklern mit Erfahrung in React bekannt vorkommen, da Qwik ebenfalls auf funktionale Komponenten und JSX setzt. Auf den zweiten Blick f\u00e4llt jedoch ein $<\/em>-Suffix an bestimmten Stellen der Syntax auf. Dies ist zum einen f\u00fcr den Entwickler als auch den QwikOptimizer ein Zeichen, dass an dieser Stelle die Applikation in kleinere Chunks aufgesplittet wird, die dann sp\u00e4ter nach dem Prinzip der Resumability \u201clazy-loadable\u201d sind. [14] Der Optimizer \u00fcbersetzt beim Build den Code so, dass die Referenzen und States f\u00fcr die Closures wiederhergestellt sind und so die Anwendung im Client direkt fortgesetzt werden kann. Beim Build-Prozess der Anwendung wird dann das $<\/em>-Suffix als Indiaktor erkannt und die Funktion als sogenanntes Symbol auf oberster Ebene unter einer eigenen QLR (siehe oben<\/em>) extrahiert wodurch automatisch ein sehr fein-granulares Code-Splitting erreicht wird, ohne dass sich der Entwickler selbst darum k\u00fcmmern muss. [14]<\/p>\n\n\n\n In diesem Beispiel erkennt man, dass das $<\/em>-Zeichen hinter der Komponente und dem OnClick-Event steht. Der Optimizer kann nun daraus zwei separate Qwik-Symbole generieren, die nun auf User-Request geladen werden.<\/p>\n\n\n\n Performance-Vergleich anhand einer prototypischen Anwendung<\/strong><\/p>\n\n\n\n Die Performance des Frameworks und ob das oben beschriebene Konzept der Resumability auch in der Praxis einen wirklichen Geschwindigkeitsvorteil bietet, soll nun anhand einer prototypischen Testapplikation \u00fcberpr\u00fcft und mit einer \u201cHydration\u201d-Anwendung verglichen werden.<\/p>\n\n\n\n Vorgehen und Aufbau der Anwendungen<\/strong><\/p>\n\n\n\n F\u00fcr den Performance-Vergleich wird daf\u00fcr zum einen eine Qwik-Anwendung und zus\u00e4tzlich eine weitere Applikation mit Next.js entwickelt, das als Meta-Framework von React die Seite serverseitig rendert und schlie\u00dflich hydriert. Die beiden Anwendungen sollen f\u00fcr eine bestm\u00f6gliche Gegen\u00fcberstellung nahezu identisch aufgebaut und implementiert werden. So bestehen sowohl die Qwik- als auch die Next.js- App aus einer einzigen Seite mit einer \u00fcbergeordneten, vom Framework bereitgestellten Layout-Komponente, die einen simplen Header und Footer beinhaltet, sowie eine globale CSS-Datei einbindet. Der Hauptinhalt der Seite setzt sich aus verschiedenen einzelnen Qwik- bzw. React-Komponenten zusammen, die in einem separaten Ordner mit jeweils zugeh\u00f6rigen CSS-Files f\u00fcr das Design liegen und dabei verschiedene, typische Aspekte einer modernen Webanwendung abdecken sollen.<\/p>\n\n\n\n Vergleichender Test<\/strong><\/p>\n\n\n\n Nach dem Deployment der Testapplikationen werden diese mit dem Tool \u201cWebPageTest\u201d von Catchpoint hinsichtlich ihrer Ladeperformance \u00fcberpr\u00fcft. F\u00fcr jede Seite werden dabei zwei Testl\u00e4ufe unter verschiedenen Bedingungen durchgef\u00fchrt. <\/p>\n\n\n\n Bei dem ersten Durchgang wird im Tool eine Konfiguration gew\u00e4hlt, bei der die Seiten von einem Desktoprechner mit Firefox-Browser in Frankfurt mit einer 5 Mbps LAN-Verbindung und einer Latenz von 28ms aufgerufen werden, sodass dieser Test unter nahezu optimalen Bedingungen durchgef\u00fchrt wird. Im zweiten Teil soll nun au\u00dferdem \u00fcberpr\u00fcft werden, wie die beiden Anwendungen unter schlechteren Voraussetzungen abschneiden. Dabei wird der WebPageTest von einem Motorola-Mittelklasse-Smartphone mit Chrome-Browser in Indien mit einer 1,6 Mbps 3G-Verbindung und einer h\u00f6heren Latenz von 300ms simuliert.<\/p>\n\n\n\n F\u00fcr die Evaluierung der Ladeperformance der Seiten werden anschlie\u00dfend folgende Metriken betrachtet:<\/p>\n\n\n\n![](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2024\/02\/iJXp3JwtYsFDHaNgfW8xj868CnAbzQgDaGaTqhVcKepyPnlbuPgqwdPgAxh3-Bgo4qX0M7xWWp8wTHGSDOzbcfB-GVPmA1KUYDc_BjtAFS2nlrYEI9gATDMWoiDqQ3fhJjec0PJWzbdyM07QKFzI-m0.png\")
<\/p>\n\n\n\n![](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2024\/02\/OhL2oNcWpqViawB7mmWLuQ5Nfx5sifQU5flMArUw7qLY97JMXbW5iEn40uz79e5YsQKoMY30idGVGw_K7ZhyO6PilEutqbad6Jp6gEn3J2ZJjKaljJeYcQRZ_vZQO1zbXVMIrgzuwgYxp1XmnCspcqg.png\")
<\/p>\n\n\n\n\n
![](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2024\/02\/SX0uhL7Do3cgoH4aWoNztUMVvtXG6-tpM36CsMTj88bm8LUd9pMlN1-mx3N9x0h44wMcNxpVyymmftRVEqIWtgSpnjoGkEyJLK5DZnbM7EbY3jPOf__gQyMnmk502ILhNXuV17hH5s0BlBOQXGsvg_Q.png\")
<\/p>\n\n\n\n![](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2024\/02\/ZUI9Kk5RrFTYgaQXtlxfzTupJMVuKVy7lm2irvUA0MDTtWArPCQ4_UgbtpRcdIWbhhKWwAR_t1VrPOpuAKm_Zjgovw75N9izt-NkIfg5_7gGsARaOz8kWSEe1WC3KbQtcv0ETKYuuKBOZOyZrDVP9Zw.png\")
<\/p>\n\n\n\n![](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2024\/02\/VQ5IhLMU58FAl7I8F0itn1KFyVaIGB5RXtYPTwL7PDQjwD7lsYmtcTaZI7WFEbt7vY2ocM-ydVEMNaBZy8M7oQTvdvU4gY_xuzJ5W_JBO8vRmtxIkW-R7JFUXZ3G86mhwg1SWK-fAmzbQX80w8cmFIc.png\")
<\/p>\n\n\n\n![](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2024\/02\/SQ6ILl6xGY6z-5RfGIZ8K_DDCTVcy6RoDOkXL_XjoFaozLDbrdtqw0CxrvQjXaxRyQFvd-XSNHmDkzqXOJc0sIjm_czciUCwCEJXJqvCRyYYkTCfI1VClqpw-J9u1RCF4sDiKObvDBmkkzgeWawiRLo.png\")
<\/p>\n\n\n\n![](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2024\/02\/ljbgGf3910XtiChg1LK1-ue4Py4DPEmCqi3XHLQLh2WwrmGHf3KTP8jfKOo5diwG_6dxQVBXOc1_tE8jplDsHjzgx389llTIs-9mVmIdp5rhw45mii7F70fpQ2hF5FR_oBYDx9x6FxTXF6dyX9JBoeQ.png\")
<\/p>\n\n\n\n\n
F\u00fcr die anschlie\u00dfende \u00dcberpr\u00fcfung werden nun noch beide Anwendungen \u00fcber den Cloud- Hosting-Anbieter Vercel deployed und sind unter den URLs https:\/\/qwik-app-one.vercel.app\/<\/em><\/a> <\/em>bzw. <\/em>https:\/\/next-app-psi-one.vercel.app\/<\/em><\/a> <\/em>\u00f6ffentlicht aufrufbar.<\/p>\n\n\n\n\n
![](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2024\/02\/vm6o42zSi0mK7OntVhP16W6OzSt7pjZZCVNu7KsyoI5nngqyiFVAO6FaCRb6nCvnr61gi8Fw-un2XKSeEMNoShtb-gKJMInIJbMFb3yRUnB51fadHVk9S_8Vx9Dn2qmQ7OIW4i7A0-nBtZ6JOw-XWZE.png\")
<\/p>\n\n\n\n