Share
Meine letzten beiden Artikel konzentrierten sich auf Debugging-Tools. Daher ist es nur passend, dass ich mit diesem Thema fortfahre. Beim Debuggen von Front-End-Code verbringen Sie häufig viel Zeit damit, zu überprüfen, wie sich CSS und JavaScript auf das Rendern Ihrer Seite auswirken. Ebenso wichtig ist, wie Netzwerkanforderungen Ihren Standort beeinflussen. In vielen Fällen arbeiten wir lokal und vergessen, dass die Seitengröße, Latenzzeit und das Laden und Blockieren von Skripts die Art und Weise beeinflussen können, in der ein Benutzer Ihre Site erlebt. Daher ist es wichtig, ein gutes Set an Tools zur Überprüfung des Netzwerkverkehrs zu haben, um Ihr Debugging-Toolset abzurunden.
Glücklicherweise bieten alle gängigen modernen Browser Debugging-Tools, mit denen Sie den Netzwerkverkehr überprüfen können. Mit Tools von Drittanbietern wie Fiddler und Charles können Sie nicht nur Netzwerkanfragen sehen, sondern auch erweiterte Funktionen für die Interaktion mit Ihrer Site bieten.
Wir werden beide Arten von Tools untersuchen.
Wie bereits erwähnt, verfügt jeder größere Browser über integrierte Debugging-Tools. Diese schließen ein:
Jeder Satz hat seine eigenen einzigartigen Fähigkeiten, aber jeder hat die Fähigkeit, Netzwerkverkehr zu sammeln. Wenn Sie die folgenden Bilder betrachten, können Sie feststellen, dass die gesammelten und angezeigten Daten sehr ähnlich sind, obwohl die Benutzeroberflächen variieren können:
Das Endergebnis ist eine Liste der Netzwerkanfragen des Browsers, die mit dem Herunterladen der Assets oder Daten unserer Seiten verbunden sind. Das Netzwerktool kann diese Anforderungen abfangen, um Ihnen wichtige Daten anzuzeigen, beispielsweise:
Fiddler nimmt die Anfrage für Ihren URI an und ersetzt sie durch eine lokale Datei.
Wenn wir also die Ergebnisse von Firebug betrachten, sehen wir, dass die Anfrage die Hauptseite und die zugehörigen CSS- und JavaScript-Dateien zurückgezogen hat, einschließlich Assets von Amazons AWS. Aufgrund von Bildbeschränkungen kann ich Ihnen nicht alles zeigen, was geladen wurde. Es wurden jedoch auch Bild- und Flash-SWF-Dateien zurückgegeben.
Mit diesen Informationen kann ich nun gezielt nach bestimmten Anforderungen suchen, um festzustellen, ob ich die richtigen Daten erhalte oder warum ich eine lang andauernde Anfrage habe. Angenommen, ich schaue mir die Anfrage nach der JavaScript-Datei von Webtrend an. Das Herunterladen hat 1,2 Sekunden gedauert, und ich möchte sehen, wie die Anforderung bearbeitet wird. Ich kann die Anfrage erweitern und feststellen, ob sie gekippt wird (es ist):
und wenn es vermint ist:
In diesem Fall wurde die Datei nicht minimiert, und ich kann mit dem Entwickler Kontakt aufnehmen, um festzustellen, ob dies sinnvoll ist. Zugegeben, es ist eine 2K-Datei, aber jedes Byte ist von Bedeutung und diese Informationen ermöglichen es mir, meine Website besser zu optimieren.
Netzwerklatenz kann ein Killer sein, insbesondere für Single-Page-Apps, die für ihre Funktionalität von externen APIs oder mehreren Skriptdateien abhängig sind. Die meisten Browser versuchen, Assets asynchron zu laden, wenn dies möglich ist. Einige JavaScript-Dateien können jedoch blockierende Ereignisse verursachen. Es ist wichtig, diese festzuschreiben, um das Laden der Ressourcen so weit wie möglich zu optimieren. Wenn Sie dieses Bild betrachten, können Sie sehen, dass die Datei 1,4 Sekunden zum Laden benötigte:
Wenn Sie den Mauszeiger über die Zeitleisten bewegen, erhalten Sie einen Dialog, in dem wir den Fortschritt der Anforderung aufgeschlüsselt sehen:
Ein Teil davon war, weil es für 760 ms vom Laden blockiert wurde. Wenn sich herausstellte, dass dies ein allgegenwärtiges Problem war, könnten Sie einen Skript-Loader wie RequireJS verwenden, um das Laden von Skripts und Abhängigkeiten besser zu verwalten.
Da dynamische Apps so allgegenwärtig sind, ist es wichtig, XHR-Anrufe überprüfen zu können. Zuvor hatten Sie eine Unmenge von Netzwerkanfragen gesehen, und der Versuch, alle zu filtern, um Ihre XHR-Anrufe zu finden, ist nicht effizient. Daher können Sie bei den meisten Tools auswählen, welche Arten von Anforderungen angezeigt werden sollen. Hier werde ich nach XHR-Anfragen gefiltert, damit ich die Anfrage und Antwort auswerten kann:
Durch Drilldown in die Anfrage kann ich wichtige Details der Anfrage wie Kopfzeilen und Status, Anforderungsmethode, Cookies und vor allem die zurückgegebene Antwort auswerten:
In diesem Fall wurde HTML zurückgegeben. Die Antwort könnte jedoch auch Text, JSON oder XML umfassen. Das Tolle ist, dass ich es in der Lage bin, alles zu überprüfen, falls ich Probleme habe.
Cookies sind unglaublich nützlich, und da wir sie ausgiebig verwenden, ist es einfacher, ihre Werte zu überprüfen. Entwicklertools machen es einfach, indem Sie Ihnen zeigen, welche Cookies gesendet und empfangen wurden:
Wenn Sie jemals serverseitige Entwicklung ohne clientseitige Tools durchgeführt haben, wissen Sie, warum das so großartig ist.
Insgesamt ist das Tolle daran, dass die Funktion in Ihrem Browser richtig ist, was es sehr praktisch macht, den Debugger zu öffnen und die Dinge zu überprüfen. Manchmal brauchen Sie jedoch etwas mehr Leistung.
HTTP-Proxy-Anwendungen wie Fiddler und der Charles Web Debugging Proxy sind die großen Brüder von browserbasierten Netzwerk-Verkehrsschnüfflern. Sie können nicht nur Netzwerkanfragen vom Browser abfangen, sondern auch andere Anwendungen auf Ihrem Computer, wodurch sie für das Debugging viel vielseitiger werden. Sie bieten auch reichhaltigere Funktionen wie:
Ich verwende ausgiebig den Windows-basierten, unglaublich funktionsreichen Fiddler (Freeware!). Es wird wegen seines robusten Funktionsumfangs auch stark in Microsoft eingesetzt. Der Entwickler von Fiddler, Eric Lawrence, hat zuvor bei Microsoft gearbeitet und verwaltet die Anwendung weiterhin.
Wenn wir uns die Benutzeroberfläche anschauen, werden Sie Ähnlichkeiten mit den Ergebnissen der Browser-Tools feststellen. Alle Netzwerkanforderungen werden zusammen mit den wichtigsten Informationen zu den Anforderungen angezeigt.
Und wenn ich in eine Anfrage hineinbohrt, kann ich ausführliche Details dazu sehen, einschließlich der verminderten Quelle der jQuery-Bibliothek:
Viele dieser Informationen können über die browserbasierten Tools abgerufen werden. Was passiert jedoch, wenn Sie sehen möchten, ob eine bestimmte Bibliothek Ihre Site in die Luft sprengt? Sie können Bibliotheken auf jeden Fall austauschen und Fehler beheben. Ein besserer Weg wäre, einen Fiddler AutoResponder zu erstellen, der Ihre Anfrage abfängt und die Produktionsbibliothek durch eine Ihrer Wahl ersetzt. Denken Sie eine Sekunde darüber nach. Fiddler nimmt die Anfrage für Ihren URI an und ersetzt sie durch eine lokale Datei. Lass es uns überprüfen.
Zuerst muss ich die URI identifizieren, die ich ersetzen möchte. In diesem Fall sehe ich, dass das Design meines Blogs jQuery v1.2.6 ausführt. Das ist wahnsinnig, aber bevor ich es reinbringe und Verwüstungen auf meiner Website anrichte, würde ich gerne sehen, ob jQuery v1.8.3 wie erwartet funktioniert.
Ich klicke auf den Eintrag für jQuery v1.2.6. In der rechten Spalte von Fiddler wähle ich die Registerkarte "AutoResponder" aus und klicke "Automatische Antworten aktivieren". Das Starten des Antworters ist so einfach wie das Ziehen des URI in den Regeleditor. Sie werden feststellen, dass die Regel durch einen Vergleich der URI gestartet wird. Wenn es passt, reagiert es mit einem Ereignis Ihrer Wahl.
Da ich jQuery 1.8.3 testen möchte, möchte ich, dass die Produktionsversion gegen eine lokale Kopie von jQuery ausgetauscht wird, die ich auf meinem Computer habe.
Ich speichere die Regel und lade meine Seite erneut. Das Endergebnis ist, dass der URI zwar gleich aussieht, die Überprüfung der Ergebnisse jedoch zeigt, dass jQuery v1.8.3 tatsächlich injiziert wurde. Dies ermöglicht es mir, dies sofort zu testen, ohne Änderungen an der Site vorzunehmen:
Aus Debugging-Sicht kann ich nicht betonen, wie nützlich dies ist, insbesondere wenn Sie versuchen, einen Fehler in älteren Versionen eines Frameworks oder einer Bibliothek zu finden.
Mein guter Freund Jonathan Sampson hat einen großartigen Screencast mit dieser Funktion gemacht.
>Netzwerklatenz kann besonders bei einseitigen Apps ein Killer sein.
Fiddler profitiert von einem umfangreichen Add-On-Ökosystem, das seine Funktionalität über die iFiddlerExtension-Schnittstelle erweitert. Es gibt Add-Ons, die Folgendes ermöglichen:
Fiddler hat selbst eine Menge Funktionen - zu viele, um sie in diesem Beitrag zu beschreiben. Aus diesem Grund gibt es ein 330 Seiten starkes Buch, in dem Sie die Vorteile voll ausnutzen können. Es kostet nur 10 US-Dollar und hilft Ihnen, die Besonderheiten dieses großartigen Tools kennenzulernen.
Unter OSX oder Linux ist der Charles Web Debugging Proxy die beste Option. Es ist eine großartige und gut unterstützte App, und obwohl sie kommerziell ist, ist sie jeden Cent wert. Ich habe nach guten Alternativen gesucht, die sich auf die Webentwicklung konzentrierten, und Charles ist wirklich herausragend.
Die Schnittstelle ähnelt Fiddler, bietet jedoch zwei verschiedene Möglichkeiten, den Netzwerkverkehr zu betrachten:
Der Stil liegt ganz bei Ihnen. Ich neige dazu, mich auf die strukturierte Sicht zu neigen, weil sie sich etwas organisierter anfühlt, aber es ist ein bisschen mehr Arbeit, herauszufinden, wo sich eine bestimmte URI befindet.
Wie Fiddler bietet auch Charles eine Autoresponder-Funktion an. Es heißt "Map Local ..." und Sie können es durch Klicken mit der rechten Maustaste auf einen bestimmten URI aufrufen. Dadurch können Sie eine lokale Datei auswählen, mit der Sie arbeiten möchten.
Wenn ich die Seite neu lade, lasse ich jetzt jQuery v1.2.6 durch die lokale Kopie von jQuery v1.9 ersetzen, die sich auf meinem Computer befand.
Eine weitere großartige Funktion von Charles ist die Möglichkeit, Ihre Netzwerkanforderungen zu drosseln, um bestimmte Bandbreitengeschwindigkeiten zu simulieren. Ich erinnere mich an die Tage der 56k-Modems und ihre atemberaubenden Geschwindigkeiten, so dass die Verwendung dieser Erinnerungen schöne Erinnerungen weckt (ähm, rechts):
Charles kann auch unter Windows arbeiten, da es eine vollständige plattformübergreifende Benutzeroberfläche bietet.
Ich verwende all diese Tools die ganze Zeit, weil ich mit jedem großen Browser teste. Mit dieser Funktion ist die Fehlerbehebung wirklich einfacher. Die Entscheidung, ob Sie einen browserbasierten Sniffer oder einen hardcore-app-basierten Proxy verwenden, hängt natürlich ganz von Ihren Debugging-Anforderungen ab.
Wenn Sie lediglich den Datenverkehr überprüfen und die Ergebnisse überprüfen müssen, wird ein Browser-basierter Sniffer höchstwahrscheinlich perfekt zu Ihnen passen.
Auf der anderen Seite, wenn Sie eine genaue Kontrolle über das Verhalten von URIs benötigen oder die Flexibilität beim Erstellen benutzerdefinierter Testskripte haben möchten, ist ein Tool wie Fiddler oder Charles das richtige Ziel. Das Tolle ist, dass wir solide Entscheidungen treffen, um uns dabei zu helfen, zumal die Komplexität unserer Projekte zunimmt.
Accentsconagua