Share
Mina tidigare två artiklar fokuserade på felsökningsverktyg, så det är bara passande att jag fortsätter med detta tema. När du debugger front-end-kod brukar du spendera mycket tid på att granska hur CSS och JavaScript påverkar din sidas rendering. lika viktigt är hur nätverksförfrågningar påverkar din webbplats. I många fall arbetar vi lokalt och glömmer sidstorlek, latens och skrivning och blockering kan påverka hur en användare upplever din webbplats. Så att ha en bra uppsättning verktyg för att inspektera nätverkstrafik är viktigt för att avrunda din felsökningsverktyg.
Lyckligtvis erbjuder alla stora moderna webbläsare felsökningsverktyg som gör att du kan inspektera nätverkstrafik, och 3: e partsverktyg som Fiddler och Charles låter dig inte bara se nätverksförfrågningar, men erbjuder utökade möjligheter att interagera med din webbplats.
Vi utforskar båda typerna av verktyg.
Som jag nämnde har alla större webbläsare inbyggda felsökningsverktyg. Dessa inkluderar:
Varje uppsättning har sina egna unika möjligheter, men alla har möjlighet att samla nätverkstrafik. Om vi tittar på följande bilder kan du se att medan användargränssnittet kan variera är data som samlas in och visas väldigt likartat:
Slutresultatet är en lista över webbläsarens nätverksförfrågningar med att ladda ner våra sidors tillgångar eller data. Nätverksverktyget kan avlyssna dessa förfrågningar så att du får viktiga uppgifter som:
Fiddler tar begäran om din URI och ersätter den med en lokal fil.
Så om vi tittar på resultaten från Firebug kan vi se att förfrågan drog tillbaka huvudsidan och dess tillhörande CSS- och JavaScript-filer, inklusive tillgångar från Amazons AWS. På grund av bildbegränsningar kan jag inte visa dig allt det laddas, men det var också bilder och Flash-swf-filer som returnerades.
Genom att ha den här informationen kan jag nu borra ner i specifika förfrågningar för att avgöra om jag får rätt data, eller varför jag kan få en långsiktig begäran. Antag att jag tittar på begäran om Webtrends JavaScript-fil. Det tog 1,2 sekunder att ladda ner, och jag vill se hur förfrågan hanteras. Jag kan expandera förfrågan och bestämma om den är gzipped (den är):
och om det har blivit minifierat:
I det här fallet har filen inte minskats, och jag kan följa upp med utvecklaren för att avgöra om det är vettigt att göra det. Beviljas, det är en 2K-fil, men varje byte är viktig och den här informationen gör det möjligt för mig att optimera min sida bättre.
Nätverksfördröjning kan vara en mördare, speciellt för enkelsidiga program som beror på externa API eller flera skriptfiler för deras förmåga. De flesta webbläsare försöker att asynkront ladda tillgångar när de kan, men vissa, som JavaScript-filer, kan orsaka blockering av händelser. Det är viktigt att kunna stifta dem för att optimera resursbelastningen så mycket som möjligt. Om vi tittar på den här bilden kan du se att filen tog 1,4 sekunder att ladda:
Genom att sväva över tidslinjerna får vi en dialog som ger oss en sammanfattning av hur förfrågan fortskred:
En del av det berodde på att den var blockerad från lastning för 760ms. Om det här visade sig vara en genomgripande fråga kan du titta på att använda en skriptlaster som RequireJS för att bättre hantera skriptbelastning och beroenden.
Eftersom dynamiska appar är så genomgripande, är det viktigt att kunna inspektera XHR-samtal. Tidigare såg du massor av nätverksförfrågningar och försökte filtrera genom dem alla för att hitta dina XHR-samtal är inte effektiva. På grund av detta kan de flesta verktyg du välja vilka typer av förfrågningar du vill visa. Här filtrerar jag efter XHR-förfrågningar så att jag kan utvärdera begäran och svaret:
Genom att borra ner i begäran kan jag utvärdera viktiga detaljer om begäran, till exempel rubrikerna och statusen, förfrågningsmetoden, cookies och framför allt svaret som returnerades:
HTML returnerades i det här fallet, men svaret kan vara allt inklusive text, JSON eller XML. Det bästa är att jag kan inspektera det fullständigt om jag stöter på några problem.
Kakor är otroligt användbara, och eftersom vi använder dem i stor utsträckning har det enkelt att inspektera sina värden lättare. Utvecklarverktyg gör det enkelt att göra det genom att visa vilka cookies som skickades och mottogs:
Om du någonsin har gjort server-sida utveckling utan verktygssidan verktyg, vet du varför det här är så fantastiskt.
Sammantaget är det bra med det här att möjligheten är rätt i din webbläsare, vilket gör det oerhört bekvämt att popup debuggeren och kolla saker. Ibland behöver du lite mer hästkrafter.
HTTP Proxy-applikationer som Fiddler och Charles Web Debugging Proxy är de stora bröderna av webbläsarbaserade nätverkstrafikniffrar. Inte bara kan de fånga nätverksförfrågningar från webbläsaren, men även andra applikationer på din dator, vilket gör dem mycket mer mångsidiga för felsökning. De tenderar också att erbjuda rikare funktioner som:
Jag använder i stor utsträckning den Windows-baserade, otroligt funktionella Fiddler (det är freeware!). Den används också kraftigt inuti Microsoft på grund av det robusta funktionssetet. Utvecklaren av Fiddler, Eric Lawrence, arbetade tidigare hos Microsoft och behåller fortfarande ansökan.
Om vi tittar på användargränssnittet ser du likheter i produktionen till det vi såg i webbläsarfunktionerna. Alla nätverksförfrågningar visas tillsammans med viktig information om förfrågningarna.
Och genom att borra i en förfrågan kan jag se omfattande detaljer om det, inklusive den minifierade källan till jQuery-biblioteket:
Mycket av den informationen kan dras tillbaka via de webbläsarbaserade verktygen, men vad händer när du vill se om ett specifikt bibliotek sprängar din webbplats? Du kan definitivt byta ut bibliotek och felsöka. En bättre väg skulle vara att bygga en Fiddler AutoResponder som avlyssnar din begäran och ersätter produktionsbiblioteket med ett av dina val. Tänk på det för en sekund. Fiddler tar begäran om din URI och ersätter den med en lokal fil. Låt oss kolla upp det.
Först måste jag identifiera URI-enheten som jag vill ersätta. I det här fallet ser jag att min blogg temat kör jQuery v1.2.6. Det är vansinnigt, men innan jag släpper in det och utspelar mig på min sida, skulle jag vilja se om jQuery v1.8.3 fungerar som förväntat.
Jag klickar på posten för jQuery v1.2.6. I den högra kolumnen i Fiddler väljer jag fliken "AutoResponder" och markerar "Aktivera automatiska svar". Att skicka av svararen är lika enkelt som att dra URI i regelredigeraren. Du kommer märka att det börjar regeln genom att jämföra URI. Om det matchar, svarar det med en händelse du väljer.
Eftersom jag vill testa jQuery 1.8.3 vill jag regeln att byta ut produktionsversionen med en lokal kopia av jQuery som jag har på min dator.
Jag sparar regeln och laddar om min sida igen. Slutresultatet är att medan URI kan se ut på samma sätt, kontrollerar resultaten att jQuery v1.8.3 faktiskt injicerades, vilket gör det möjligt för mig att testa det här utan att göra några ändringar på webbplatsen:
Ur ett felsökningsperspektiv kan jag inte betona hur användbart det här är, speciellt när du försöker spika ner en bugg i äldre versioner av en ram eller ett bibliotek.
Min goda vän Jonathan Sampson gjorde en bra skärmdump om att använda den här funktionen.
>Nätverksfördröjning kan vara en mördare, speciellt för enkelsidiga appar.
Fiddler drar nytta av ett omfattande tilläggsekosystem som utökar sin funktionalitet via iFiddlerExtension Interface. Det finns tillägg som tillåter:
Fiddler har i sig en TON av funktioner - för många att beskriva i det här inlägget. Därför finns det en 330 sidbok om hur man kan dra fördel av det. Det är bara $ 10 och hjälper dig att lära dig in och ut ur det här fantastiska verktyget.
Om du är på OSX eller Linux är det bästa alternativet Charles Web Debugging Proxy. Det är en bra och välskött app, och när det är kommersiellt är det värt vartenda öre. Jag har letat efter bra alternativ som fokuserade på webbutveckling, och Charles stod verkligen ut.
Gränssnittet liknar Fiddler, men det erbjuder två olika sätt att titta på nätverkstrafik:
Stilen är helt upp till dig. Jag brukar luta mig mot den strukturerade vyn eftersom den känns lite mer organiserad, men det är lite mer arbete att ta reda på var en viss URI är.
Liksom Fiddler erbjuder Charles också en autosvarfunktion. Den heter "Map Local ...", och du klarar det med högerklickning på en viss URI. Detta låter dig välja en lokal fil att arbeta med.
När jag laddar om sidan har jag nu jQuery v1.2.6 ersatt av den lokala kopian av jQuery v1.9 som fanns på min dator.
En annan stor egenskap hos Charles är möjligheten att smasha dina nätverksförfrågningar för att simulera specifika bandbreddshastigheter. Jag kommer ihåg de 56k modemernas dagar och deras brinnande hastigheter, så med det här får du tillbaka förtjusta minnen (um, höger):
Charles kan också arbeta med Windows eftersom det erbjuder en komplett plattforms-gränssnitt.
Jag använder alla dessa verktyg hela tiden eftersom jag testar på alla större webbläsare. Att ha denna förmåga gör det verkligen lättare att felsöka. Naturligtvis väljer du om du vill använda en webbläsarbaserad sniffer eller en hårdvaraappbaserad proxy helt beroende på dina felsökningsbehov.
Om du bara behöver inspektera trafik och kontrollera resultat, kommer en webbläsarbaserad sniffer troligtvis att passa dig perfekt.
Å andra sidan, om du behöver granulär kontroll över hur URI-enheter svarar eller vill ha flexibilitet att skapa anpassade testskript, är ett verktyg som Fiddler eller Charles där du behöver gå. Det stora är att vi har solida val för att hjälpa oss att göra detta, särskilt när våra projekt komplexitet ökar.
Accentsconagua