September 2017 – Web Debugging

Zwei Bildschirme

Web Debugging

Unlängst haben wir in einem Thema des Monats sowie in einem ergänzenden Blog-Beitrag Möglichkeiten zum Monitoring von Websites dargestellt. Dabei konnten wir aufzeigen, dass ein Monitoring-Alarm nicht ausschliesslich auf ein Netzwerk- oder Serverproblem und damit eine tatsächliche Downtime hinweisen muss, sondern auch durch eine schlechte Performance der Website, also (zu) lange Ladezeiten ausgelöst werden kann. Damit eine solche Problematik nicht erst im Livebetrieb einer Website erkannt wird, bedarf es schon bei deren Entwicklung regelmässiger Tests sowie Analysen von Ladezeiten und anderen Performanceindikatoren. Aus diesem Grund wollen wir ein paar wenige Hinweise auf Tools und Techniken geben, die uns bei solchem Website Debugging nützlich erscheinen. Auch hierbei gilt natürlich, dass wir nur einen kleinen Ausschnitt der verfügbaren Tools zeigen und erst recht keinen umfassenden Leitfaden zum Debugging von Websites erarbeiten können.

Debugging mit Browsertools

Zu den für Webentwickler unverzichtbaren Werkzeugen gehören die in den Browser eingebauten Dev(eloper)-Tools, die eine Vielzahl von Möglichkeiten bieten, Websites auf deren Struktur, Programmierung, Performance und Layout hin zu untersuchen. Sprechen wir hier von ‚dem‘ Browser, meinen wir eigentlich alle verbreiteten Webbrowser, allen voran Google Chrome, Firefox, Safari, Microsoft Edge/Internet Explorer oder auch Opera. (Safari verfügt mit den Web Development Tools über ein vergleichbares Set an Werkzeugen, die jedoch erst ab dessen Version 6 und damit nur unter Mac OS, nicht aber unter Windows zur Verfügung stehen: https://developer.apple.com/safari/tools/)

Aufgerufen werden diese in den Windows-Versionen auf der zu analysierenden Website mittels Strg+Shift+I und offenbaren sogleich eine Fülle von Informationen sowie verschiedenste Analysemöglichkeiten:

Bereits in dem beim Aufruf standardmässig aktiven Bereich „Elements“ lassen sich Aufbau und Struktur der Website sowie die Eigenheiten bestimmter Objekte hierauf einfach betrachten. Die Möglichkeit, mit der Maus Bereiche der Website anzuklicken und daraufhin den entsprechenden Abschnitt im Quellcode angezeigt zu bekommen, vereinfacht die Suche nach Fehlern im Code erheblich.

Unabhängig vom Quellcode lassen sich in den Dev-Tools aber auch die einzelnen Elemente einer Website sowie deren Herkunft, Grösse und Ladegeschwindigkeit anzeigen. Auf diese Weise können beispielsweise leicht grosse Dateien ausgemacht werden, die die Ladezeit der Seite erhöhen, oder auch langsame (Fremd-) Server identifiziert werden, die bestimmte Ressourcen wie etwa Webfonts zur Verfügung stellen.

Auf die weithin bekannten Funktionen der Dev-Tools gehen wir an dieser Stelle nicht weiter ein – zu zahlreich sind die hierzu bereits vorhandenen Erläuterungen und Anleitungen. Auf eine recht neue, erst mit Version 59 in Chrome Stable implementierte und dadurch noch nicht allzu bekannte Funktion wollen wir dennoch hinweisen: Die bis vor Kurzem lediglich in der Canary-Version des Browsers vorhandene „Code Coverage“-Funktion. Chrome Canary ist nach Stable, Beta und Dev die vierte, instabilste Version des Browsers, in der neue Funktionen demnach zuerst getestet werden können. Für den produktiven Alltagseinsatz ist diese Version nicht geeignet, mitunter aber für das Debugging, zumal Canary und Stable parallel installiert und genutzt werden können.

Aufgerufen wird die neue Funktion via Dev-Tools-Menü > More Tools > Coverage. Nun muss, wie beispielsweise auch bei der Performance-Analyse, eine Aufzeichnung gestartet werden, während der die gewünschte Seite zu laden ist. Nach Beendigung der Aufzeichnung werden im Coverage-Tab die geladenen CSS- und JS-Dateien aufgelistet samt ihrer Grösse und – hier wird es spannend – den Anteilen der geladenen und ungeladenen Zeilen des jeweiligen Scripts. Diese werden beim Anklicken eines einzelnen Scripts im Bereich „Sources“ zudem farblich hervorgehoben, sodass direkt ersichtlich wird, welche Zeilen des Codes im aufgezeichneten Zeitraum ausgeführt wurden (grün), nicht ausgeführt wurden (rot), oder in denen sich sowohl ausgeführte als auch nicht ausgeführte Code-Snippets befinden (grün und rot).

Dieses Feature ist äusserst nützlich, um den während der Entwicklung angewachsenen Code von unnützem Ballast zu befreien, wobei freilich Vorsicht geboten ist. Zumindest vermittelt diese Funktion jedoch einen Einblick in die Qualität des Codes und dessen Verwendung auf der jeweils aktuellen Seite.

Web-Tests zum Debuggen

Möchte man statt solcher detaillierter Einblicke in die Tiefen einer Website hingegen einen Überblick über deren generelle Ladezeit gewinnen und sogleich Optimierungsmassnahmen vorgeschlagen bekommen, ist man mit diversen Web-Tools und -Tests gut bedient. Stellvertretend für diese sind lediglich einige wenige zu nennen: webpagetest.org, GTmetrix inklusive Yahoo’s YSlow, Pingdom, Nibbler sowie Google’s PageSpeed Insights.

Diese Tools starten Tests von verschiedenen Standorten und mit verschiedenen, teils auswählbaren Browsern, und stellen detaillierte Ergebnisse zur Verfügung, deren Analyse durch Hinweise zur Optimierung bereits deutlich vereinfacht wird.

Die Ergebnisse der Analyse werden plakativ dargestellt, sechs zentrale Kategorien von A/grün bis F/rot bewertet und eingestuft, wie auf den ersten Blick erkennbar ist. Diese Einschätzungen werden jedoch mit vielen Messwerten untermauert, sodass eine detaillierte Analyse der Ladezeiten einzelner Elemente und damit der ganzen Website möglich ist. So manches Bauchgefühl hinsichtlich (zu) langer Ladezeiten wird dadurch bestätigt und die verantwortlichen Elemente und Einstellungen ausgemacht. Besonders hilfreich sind diese Tools vor allem dort, wo sie nicht nur auf einen Mangel hinweisen, sondern explizit dessen Auswirkungen schildern und Lösungsmöglichkeiten darlegen.

Ein Klick auf die im Beispiel schlecht bewertete Kategorie der Bildkomprimierung offenbart nicht nur, welche der geladenen Bilder komprimiert werden könnten, sondern auch welche Grösseneinsparungen dies zur Folge hätte. Ähnliches gilt auch für das Browsercaching statischer Ressourcen. Hierbei wird für die unterschiedlichsten Dateien und Dateitypen angegeben, wie deren aktuelle Gültigkeitsdauer konfiguriert ist und welche aus Sicht der Ladezeitenoptimierung erhöht werden sollten. Dabei wird jedoch ein Problem deutlich: Je nach Art der Website muss hierbei unterschieden werde: Je dynamischer die Seite und deren Inhalte sind, desto genauer muss bei den Caching-Einstellungen differenziert und mitunter für eine Vielzahl einzelner Dateien ein individueller, oft niedriger Wert konfiguriert werden. Werte wiederum, die bei einer reinen Performanceanalyse kritisch bewertet werden, aber mitunter vonnöten sind. Hieran zeigt sich, dass der Analyse solcher Tools nicht blind vertraut werden sollte und auch nicht jede Anpassung automatisch in jedem Anwendungsszenario sinnvoll ist.

Den meisten der durch solche Tests und Tools vorgeschlagenen Massnahmen ist gemein, dass sie möglichst schnell ladende Websites zum Ziel haben, bei denen die Menge der übertragenen Daten möglichst gering gehalten wird. Dies ist sowohl wünschenswert als auch gut messbar, da Ladezeiten und Dateigrössen die massgeblichen Faktoren darstellen.

In einem anderen Bereich der Webentwicklung beziehungsweise dem „Debugging“ einer weit gediehenen Website sind solche automatisierten Tests freilich hinfällig: Das visuelle Erscheinungsbild bei der Verwendung unterschiedlicher Geräte – klassischerweise: Desktop-PC, Tablet, Smartphone – sowie unterschiedlicher Browser zu testen bleibt zunehmend „Handarbeit“. Allerdings gibt es auch hierfür nützliche Helfer, die wir nicht vorenthalten wollen.

Visual Debugging: Unterschiedliche Darstellung in unterschiedlichen Browsern und Devices testen

Zu unterscheiden hierbei ist zunächst zwischen dem Testen der Website in verschiedenen Browsern und dem Testen des Responsive Designs, also des Verhaltens und der Darstellung auf verschiedenen (mobilen) Geräten. Die meisten Webentwickler werden grundsätzlich neben ihrem Haupt-/Arbeitsbrowser noch weitere installiert haben, um ihre Arbeit zu testen. Wird es nicht selten als besondere Last empfunden, eine komplexe Seite auch im Internet Explorer korrekt darstellbar zu realisieren, führt hieran oft kein Weg vorbei. Doch gerade Microsofts Browser (mittlerweile „Edge“) bringt für entsprechende Tests ein hilfreiches Tool mit sich: In den Edge-Dev-Tools (aufzurufen mittels F12) verbirgt sich im Tab „Emulation“ die Möglichkeit, nicht nur unterschiedliche Auflösungen, sondern auch verschiedene Browser- und dabei vor allem auch ältere IE-Versionen zu emulieren.

Einen ersten Eindruck, wie sich die Seite bei verschiedenen Auflösungen darstellt, können auch die verschiedenen Dev-Tools der Browser vermitteln, wie das Beispiel Chrome zeigt. Ebenfalls eine Neuerung von dessen Version 59 ist die Möglichkeit, in dieser Darstellung „full size-Screenshots“ des skalierten Bereichs zu machen:

Eine detailliertere Anleitung dieser Funktion sowie eine weitere Übersicht über die Neuerungen der Dev-Tools in Chrome 59 finden sich hier.

Wenn es aber darum geht, nicht allein die unterschiedlichen Auflösungen mobiler Geräte wie Tablets und Smartphones zu berücksichtigen, sondern auch betriebssystemabhängige Eigenheiten der jeweiligen Plattform, stossen diese Tests in den Desktop-Browsern natürlich an ihre Grenzen. Hier kommen etwa Lösungen wie Crossbrowsertesting oder Browserstack zum Einsatz. Diese sind zwar kostenpflichtig, bieten jedoch den grossen Vorteil, unterschiedlichste Browser und Geräte in die Tests einbeziehen zu können, ohne diese installieren beziehungsweise anschaffen zu müssen – wie wir bereits in einem früheren Thema des Monats beschrieben haben.

Allerdings sind Szenarien denkbar, in denen diese virtualisierte Darstellung nicht ausreicht, etwa wenn es nicht allein auf die Darstellung der Website auf verschiedenen Displaygrössen ankommt, sondern auch auf das „look and feel“ und das Handling der gesamten Website mit all ihren Möglichkeiten. In einem solchen Falle ist es meist unumgänglich, zumindest eine Auswahl an aktuellen Smartphones und Tablets in die Tests einzubeziehen.

Dabei kann wiederum ein äusserst hilfreiches Tool zum Einsatz kommen, welches vor allem das Bugfixing von responsive Websites vereinfacht. Ghostlab vermag eine Website synchron auf unterschiedlichen, mit dem Hauptrechner verbundenen Smartphones und Tablets darzustellen, sodass diese parallel in unterschiedlichen Rahmenbedingungen beurteilt werden kann. Der eigentliche Clou ist jedoch, dass Änderungen an der Seite „live“ betrachtet werden können; wird beispielsweise das CSS angepasst, muss die Seite nicht erst händisch auf Smartphone und Tablet aktualisiert oder neu aufgerufen werden.

Debugging for Accessibility: Barrierefreiheit bei der Webentwicklung berücksichtigen

Alle bislang angeführten Tests zielen freilich auf hehre Ziele der Webentwicklung ab: Ansprechende, intuitiv zu bedienende Websites zu realisieren, die schnell geladen werden und auf verschiedenen Geräten problemlos genutzt werden können. Was bei allem innovativen Design hingegen mitunter in Vergessenheit gerät, ist die „User Experience“ (UX) beispielsweise blinder Besucher der Website. Doch Barrierefreiheit sollte bereits im gesamten Entwicklungsprozess einer neuen Seite berücksichtigt werden. Dies macht deren Berücksichtigung wesentlich leichter, als sie im Nachhinein zu realisieren.

Diesen absolut zentralen, oft aber sträflich vernachlässigten Aspekt wollen wir an dieser Stelle nur andeuten, zumal wir bereits vor einiger Zeit längere Ausführungen hierzu publiziert haben.

Soll demnach eine bestehende Seite oder eine Entwicklungsversion auf den aktuellen Stand hin geprüft werden, was ihre Barrierefreiheit anbelangt, stehen hierfür unterschiedliche Tests und Tools zur Verfügung, wie die Übersicht des World Wide Web Consortiums (W3C) zeigt. Wer grundsätzlich (auch) für und mit Chrome entwickelt und regelmässig die Developer Tools nutzt, wird sich freuen, dass sich ein zumindest rudimentärer Accessibility Check hier integrieren lässt. Mit den Accessibility Developer Tools lässt sich eine entsprechende Überprüfung der jeweiligen Website vornehmen; zu finden ist die Option im Reiter „Audits“:

Wie auch bei manch anderen Tests gilt, dass nicht sämtliche der vorgeschlagenen Änderungen vorgenommen werden müssen. Oftmals zeigt der Accessibility Test jedoch Probleme auf, derer man sich während der Entwicklung bewusst war. Wird die Website durch regelmässige Tests und anschliessende Anpassungen schrittweise leichter zugänglich, ist dennoch viel gewonnen – zumal sich Barrierefreiheit und ansprechendes Design keineswegs ausschliessen müssen.

Weitere Erläuterungen zum Thema finden Sie zudem auf den Seiten des W3C, und auch die Schweizer Accessibility-Studie von 2016 hält hierzu Informationen bereit. Wenn Barrierefreiheit essentiell ist für den zu realisierenden Webauftritt, lohnt es sich auch, mehr als nur einen Blick auf die sehr ausführliche Accessibility Checklist zu werfen, die zudem Hinweise und Vorlagen explizit für Entwickler zur Verfügung stellt.

Fazit

Es wird schnell deutlich, wie umfangreich sich das Testen einer Website gestaltet, wenn all diese Aspekte berücksichtigt werden sollen, das heisst die Website schnell laden, auf möglichst allen auch mobilen Geräten gut aussehen und dennoch barrierefrei umgesetzt sein will. Allein mit diesen Bereichen und den verschiedensten hierfür vorhandenen Ansätzen, Workarounds und Best Practices liessen sich umfangreiche Ausführungen machen. Wir haben uns an dieser Stelle bewusst darauf beschränkt, lediglich einen groben Überblick zu vermitteln, der künftig um zusätzliche Blog-Beiträge zu konkreten Tests, Problemen und Gegenmassnahmen ergänzt werden soll.

Haben Sie aber bereits jetzt Fragen zu den angedeuteten Themen, entsprechende Erfahrungen gemacht oder interessieren sich speziell für einzelne Tools und Tests, zögern Sie nicht, mit uns Kontakt aufzunehmen.