Share
Mijn vorige twee artikelen waren gericht op tools voor foutopsporing, dus het is alleen maar passend dat ik doorga met dit thema. Bij het debuggen van front-end-code bent u geneigd veel tijd te besteden aan het controleren hoe CSS en JavaScript van invloed zijn op de weergave van uw pagina; even belangrijk is hoe netwerkverzoeken uw site beïnvloeden. In veel gevallen werken we lokaal en vergeten we dat paginagrootte, latentie en laden en blokkeren van scripts van grote invloed kunnen zijn op de manier waarop een gebruiker uw site ervaart. Dus het hebben van een goede set tools om netwerkverkeer te inspecteren is essentieel om uw toolset voor foutopsporing af te ronden.
Gelukkig bieden alle grote moderne browsers foutopsporingshulpmiddelen waarmee u netwerkverkeer kunt inspecteren, en hulpprogramma's van derden zoals Fiddler en Charles laten u niet alleen toe om netwerkverzoeken te zien, maar bieden ook uitgebreide mogelijkheden om met uw site te communiceren..
We zullen beide soorten tools verkennen.
Zoals ik al zei, heeft elke grote browser ingebouwde foutopsporingstools. Waaronder:
Elke set heeft zijn eigen unieke mogelijkheden, maar elk apparaat heeft de mogelijkheid netwerkverkeer te verzamelen. Als we naar de volgende afbeeldingen kijken, kunt u zien dat de UI's kunnen verschillen, maar dat de verzamelde en weergegeven gegevens erg op elkaar lijken:
Het eindresultaat is een lijst met de netwerkverzoeken van de browser die betrekking hebben op het downloaden van de activa of gegevens van onze pagina's. De netwerktool kan deze verzoeken onderscheppen om u belangrijke gegevens te tonen, zoals:
Fiddler neemt de aanvraag voor uw URI en vervangt deze door een lokaal bestand.
Dus als we naar de resultaten van Firebug kijken, kunnen we zien dat het verzoek de hoofdpagina en de bijbehorende CSS- en JavaScript-bestanden heeft ingetrokken, inclusief items van Amazon's AWS. Vanwege beeldbeperkingen, kan ik je niet alles laten zien wat erin is geladen, maar er waren ook afbeeldingen en Flash-swf-bestanden die werden geretourneerd.
Door deze informatie te hebben, kan ik nu specifieke verzoeken bekijken om te bepalen of ik de juiste gegevens ontvang of waarom ik een langlopend verzoek heb. Stel dat ik naar het verzoek voor het JavaScript-bestand van Webtrend kijk. Het duurde 1,2 seconden om te downloaden en ik wil zien hoe het verzoek wordt afgehandeld. Ik kan het verzoek uitbreiden en bepalen of het wordt gzipped (het is):
en als het is verkleind:
In dit geval is het bestand niet verkleind en kan ik de ontwikkelaar op de hoogte stellen om te bepalen of het zinvol is om dit te doen. Toegegeven, het is een 2K-bestand, maar elke byte is van belang en met deze informatie kan ik mijn site beter optimaliseren.
Netwerklatentie kan een moordenaar zijn, vooral voor apps met één pagina die afhankelijk zijn van externe API's of meerdere scriptbestanden voor hun mogelijkheden. De meeste browsers proberen asynchroon apparaten te laden wanneer ze kunnen, maar sommige, zoals JavaScript-bestanden, kunnen blokkeergebeurtenissen veroorzaken. Het is belangrijk om deze vast te kunnen pinnen om zo veel mogelijk bronnen te kunnen laden. Als we naar deze afbeelding kijken, kunt u zien dat het bestand 1,4 seconden heeft gekost om te laden:
Door over de tijdlijnen te zweven, krijgen we een dialoogvenster dat ons een overzicht geeft van hoe het verzoek vorderde:
Een deel daarvan was omdat het 760ms werd belemmerd. Als dit een wijdverbreid probleem zou blijken te zijn, zou je kunnen kijken naar het gebruik van een script-loader zoals RequireJS om het laden van scripts en afhankelijkheden beter te beheren..
Omdat dynamische apps zo wijdverspreid zijn, is het essentieel om XHR-oproepen te kunnen inspecteren. Eerder zag je een hoop netwerkverzoeken, en proberen ze allemaal te filteren om je XHR-oproepen te vinden, is niet efficiënt. Daarom kunt u met de meeste hulpprogramma's kiezen welk type verzoeken u wilt weergeven. Hier filter ik op XHR-verzoeken, zodat ik het verzoek en de reactie kan evalueren:
Door in het verzoek te gaan, kan ik belangrijke details over het verzoek evalueren, zoals de headers en status, de verzoekmethode, cookies en vooral, het antwoord dat werd teruggestuurd:
In dit geval is HTML geretourneerd, maar het antwoord kan alles zijn, inclusief tekst, JSON of XML. Het mooie is dat ik het volledig kan inspecteren voor het geval ik problemen tegenkom.
Cookies zijn ongelooflijk handig en omdat we ze op grote schaal gebruiken, is het gemakkelijker om hun waarden te inspecteren. Ontwikkelaarstools maken het gemakkelijk om dat te doen door u te laten zien welke cookies zijn verzonden en ontvangen:
Als u ooit de ontwikkeling aan de serverzijde hebt gedaan zonder hulpprogramma's voor de client, weet u waarom dit zo geweldig is.
Over het algemeen is het geweldige aan dit feit dat de mogelijkheid juist is in uw browser, waardoor het ongelooflijk handig is om de foutopsporing te openen en dingen te controleren. Soms heb je echter wat meer pk nodig.
HTTP-proxy-applicaties zoals Fiddler en de Charles Web Debugging Proxy zijn de grote broers van browsergebaseerde netwerkverkeer-sniffers. Ze kunnen niet alleen netwerkverzoeken van de browser onderscheppen, maar ook andere toepassingen op uw machine, waardoor ze veelzijdiger zijn voor foutopsporing. Ze hebben ook de neiging om rijkere functies aan te bieden, zoals:
Ik gebruik veelvuldig de Windows-gebaseerde, ongelooflijk veelzijdige Fiddler (het is freeware!). Het wordt ook zwaar in Microsoft gebruikt vanwege zijn robuuste functieset. De ontwikkelaar van Fiddler, Eric Lawrence, werkte eerder bij Microsoft en onderhoudt nog steeds de applicatie.
Als we naar de gebruikersinterface kijken, ziet u overeenkomsten in de uitvoer met wat we in de browsertools hebben gezien. Alle netwerkverzoeken verschijnen samen met belangrijke informatie over de verzoeken.
En door een verzoek in te boren, zie ik er uitgebreide details over, inclusief de verkleinde bron van de jQuery-bibliotheek:
Veel van die informatie kan via de browsergebaseerde hulpmiddelen worden teruggetrokken, maar wat gebeurt er als u wilt zien of een specifieke bibliotheek uw site opblaast? U kunt bibliotheken zeker uitwisselen en problemen oplossen. Een betere route zou zijn om een Fiddler AutoResponder te bouwen die uw verzoek onderschept en de productiebibliotheek vervangt door een van uw keuze. Denk daar even over na. Fiddler neemt de aanvraag voor uw URI en vervangt deze door een lokaal bestand. Laten we het bekijken.
Eerst moet ik de URI identificeren die ik wil vervangen. In dit geval zie ik dat het thema van mijn blog jQuery v1.2.6 is. Dat is krankzinnig, maar voordat ik het laat vallen en grote schade aanricht op mijn site, zou ik willen zien of jQuery v1.8.3 werkt zoals verwacht.
Ik klik op het item voor jQuery v1.2.6. In de rechterkolom van Fiddler selecteer ik het tabblad "AutoResponder" en vink "Automatische antwoorden inschakelen" aan. Het uitschakelen van de responder is net zo eenvoudig als het slepen van de URI naar de regeleditor. U zult merken dat het de regel begint door de URI te vergelijken. Als het overeenkomt, zal het reageren met een evenement naar keuze.
Omdat ik jQuery 1.8.3 wil testen, wil ik dat de regel de productieversie uitwisselt met een lokale kopie van jQuery die ik op mijn computer heb staan.
Ik bewaar de regel en laad mijn pagina opnieuw. Het eindresultaat is dat hoewel de URI er hetzelfde uitziet, het controleren van de resultaten verifieert dat jQuery v1.8.3 in feite is geïnjecteerd, waardoor ik dit on the fly kan testen zonder enige wijzigingen aan te brengen aan de site:
Vanuit een oogpunt van foutopsporing kan ik niet genoeg benadrukken hoe nuttig dit is, vooral als je een fout probeert op te sporen in oudere versies van een framework of bibliotheek.
Mijn goede vriend Jonathan Sampson heeft een geweldige screencast gemaakt over het gebruik van deze functie.
>Netwerklatentie kan een moordenaar zijn, vooral voor apps met één pagina.
Fiddler profiteert van een uitgebreid add-on ecosysteem dat zijn functionaliteit uitbreidt via de iFiddlerExtension Interface. Er zijn add-ons die toestaan:
Op zichzelf heeft Fiddler een TON aan functies - te veel om te beschrijven in dit bericht. Daarom is er een 330 pagina's tellend boek over hoe u er optimaal van kunt profiteren. Het is slechts $ 10 en helpt je de ins-en-out van deze geweldige tool te leren.
Als u OSX of Linux gebruikt, is de Charles Web Debugging Proxy de beste optie. Het is een geweldige en goed ondersteunde app en hoewel commercieel, is het elke cent waard. Ik heb gezocht naar goede alternatieven die gericht zijn op webontwikkeling, en Charles sprong er echt uit.
De interface lijkt op Fiddler, maar biedt twee verschillende manieren om naar netwerkverkeer te kijken:
De stijl is helemaal aan jou. Ik neig naar het gestructureerde beeld te leunen omdat het een beetje meer georganiseerd lijkt, maar het is iets meer werk om uit te zoeken waar een specifieke URI is.
Net als Fiddler biedt Charles ook een autoresponder-mogelijkheid. Het wordt 'Lokale kaart ...' genoemd en u komt er terecht door met de rechtermuisknop op een specifieke URI te klikken. Hiermee kunt u een lokaal bestand kiezen om mee te werken.
Wanneer ik de pagina opnieuw laad, heb ik nu jQuery v1.2.6 vervangen door de lokale kopie van jQuery v1.9 die op mijn computer stond.
Een ander geweldig kenmerk van Charles is de mogelijkheid om uw netwerkaanvragen te beperken om specifieke bandbreedtesnelheden te simuleren. Ik herinner me de dagen van 56k-modems en hun razendsnelle snelheden, dus het gebruik van dit levert goede herinneringen op (um, right):
Charles kan ook werken op Windows, omdat het een volledige platformonafhankelijke gebruikersinterface biedt.
Ik gebruik al deze tools altijd, omdat ik test op elke belangrijke browser. Het hebben van deze mogelijkheid maakt het probleemoplossing echt gemakkelijker. Uiteraard hangt de keuze om een browser-gebaseerde sniffer of een op een harde kern gebaseerde app-proxy te gebruiken volledig af van uw debuggingbehoeften.
Als u alleen wat verkeer moet inspecteren en de resultaten wilt controleren, zal een browser-sniffer hoogstwaarschijnlijk perfect bij u passen.
Aan de andere kant, als u nauwkeurige controle wilt hebben over hoe de URI's reageren of de flexibiliteit wilt om aangepaste testscripts te maken, dan is een tool als Fiddler of Charles waar u heen moet. Het mooie is dat we solide keuzes hebben om ons te helpen dit te doen, vooral omdat de complexiteit van onze projecten toeneemt.
Accentsconagua