Share
Mine tidligere to artikler fokuserte på feilsøkingsverktøy, så det er bare passende at jeg fortsetter med dette temaet. Når du feilsøker frontend-kode, har du en tendens til å bruke mye tid på å vurdere hvordan CSS og JavaScript påvirker sidens gjengivelse. Like viktig er hvordan nettverksforespørsler påvirker nettstedet ditt. I mange tilfeller arbeider vi lokalt og glemmer at sidestørrelse, latens og skriptlasting og blokkering kan påvirke måten brukeren opplever på nettstedet ditt. Så å ha et godt sett med verktøy for å inspisere nettverkstrafikk er viktig for å avrunde feilsøkingsverktøyet ditt.
Heldigvis tilbyr alle store moderne nettlesere feilsøkingsverktøy som lar deg inspisere nettverkstrafikk, og tredjepartsverktøy som Fiddler og Charles lar deg ikke bare se nettverksforespørsler, men tilbyr utvidede muligheter til å kommunisere med nettstedet ditt.
Vi vil utforske begge typer verktøy.
Som nevnt, har alle de store nettleserne innebygde feilsøkingsverktøy. Disse inkluderer:
Hvert sett har sine egne unike evner, men hver har muligheten til å samle nettverkstrafikk. Hvis vi ser på de følgende bildene, kan du se at mens brukergrensesnittene kan variere, er dataene som samles inn og vises svært like:
Sluttresultatet er en liste over nettleserens nettverksforespørsler som er involvert i nedlasting av sidens ressurser eller data. Nettverksverktøyet kan fange opp disse forespørslene for å vise viktige data som:
Fiddler vil ta forespørselen for din URI og erstatte den med en lokal fil.
Så hvis vi ser på resultatene fra Firebug, kan vi se at forespørselen trukket tilbake hovedsiden og tilhørende CSS- og JavaScript-filer, inkludert eiendeler fra Amazonas AWS. På grunn av bildebegrensninger kan jeg ikke vise deg alt det lastet inn, men det var også bilder og Flash-swf-filer som ble returnert..
Ved å ha denne informasjonen, kan jeg nå bore ned i bestemte forespørsler for å finne ut om jeg mottar de riktige dataene, eller hvorfor jeg kan ha en langvarig forespørsel. Anta at jeg ser på forespørselen til Webtrends JavaScript-fil. Det tok 1,2 sekunder å laste ned, og jeg vil se hvordan forespørselen håndteres. Jeg kan utvide forespørselen og avgjøre om den blir gzipped (den er):
og hvis det er blitt minifisert:
I dette tilfellet har filen ikke blitt minifisert, og jeg kan følge opp med utvikleren for å avgjøre om det er fornuftig å gjøre det. Gitt, det er en 2K-fil, men hver byte er viktig og denne informasjonen tillater meg å optimalisere nettstedet mitt.
Nettverksforsinkelse kan være en morder, spesielt for enkeltsidige apper som er avhengige av eksterne APIer eller flere skriptfiler for deres evne. De fleste nettlesere prøver å asynkront laste eiendeler når de kan, men noen, som JavaScript-filer, kan føre til blokkering av hendelser. Det er viktig å kunne knytte dem ned for å optimalisere ressursbelastningen så mye som mulig. Hvis vi ser på dette bildet, kan du se at filen tok 1,4 sekunder å laste:
Ved å svinge over tidslinjene, får vi en dialog som gir oss en oversikt over hvordan forespørselen utviklet seg:
En del av det var fordi det ble blokkert fra lasting for 760ms. Hvis dette viste seg å være et gjennomgripende problem, kan du se på å bruke en skriptlaster som RequireJS for å bedre administrere skriptlasting og avhengigheter.
Fordi dynamiske apps er så gjennomgripende, er det viktig å være i stand til å inspisere XHR-samtaler. Tidligere så du massevis av nettverksforespørsler, og du prøver å filtrere gjennom dem alle for å finne at dine XHR-anrop ikke er effektive. På grunn av dette, lar de fleste verktøyene velge hvilke typer forespørsler du vil ha vist. Her filtrerer jeg etter XHR-forespørsler, så jeg kan evaluere forespørselen og svaret:
Ved å bore ned i forespørselen kan jeg vurdere viktige detaljer om forespørselen, for eksempel topptekstene og statusen, forespørselsmetoden, informasjonskapslene og viktigst av alt svaret som ble returnert:
HTML ble returnert i dette tilfellet, men svaret kan være alt inkludert tekst, JSON eller XML. Det store er at jeg er i stand til å inspisere det fullt ut dersom jeg får problemer.
Informasjonskapsler er utrolig nyttige, og siden vi bruker dem i stor grad, har det enklere å få en enkel måte å inspisere sine verdier på. Utviklerverktøy gjør det enkelt å gjøre det ved å vise deg hvilke informasjonskapsler som ble sendt og mottatt:
Hvis du noen gang har gjort server-sideutvikling uten verktøy på kundesiden, vet du hvorfor dette er så bra.
Samlet sett er det gode med dette at muligheten er rett i nettleseren din, noe som gjør det utrolig praktisk å popup feilsøkeren og sjekke ut ting. Noen ganger, selv om du trenger litt mer hestekrefter.
HTTP Proxy-applikasjoner som Fiddler og Charles Web Debugging Proxy er de store brødrene til nettleserbaserte nettverkstrafiksniffere. Ikke bare kan de fange nettverksforespørsler fra nettleseren, men også andre programmer på maskinen din, noe som gjør dem mye mer allsidige for feilsøking. De har også en tendens til å tilby rikere funksjoner som:
Jeg bruker mye Windows-basert, utrolig funksjonsrik Fiddler (det er freeware!). Det brukes også tungt inne i Microsoft på grunn av det robuste funksjonssettet. Utvikleren av Fiddler, Eric Lawrence, tidligere jobbet hos Microsoft og fortsatt opprettholder søknaden.
Hvis vi ser på brukergrensesnittet, ser du likheter i utgangen til det vi så i nettleserverktøyene. Alle nettverksforespørgene vises sammen med nøkkelinformasjon om forespørslene.
Og ved å bore inn en forespørsel, kan jeg se omfattende detaljer om den, inkludert den oppgraderte kilden til jQuery-biblioteket:
Mye av den informasjonen kan bli trukket tilbake via nettleserbaserte verktøy, men hva skjer når du vil se om et bestemt bibliotek blåser opp på nettstedet ditt? Du kan definitivt bytte ut biblioteker og feilsøke. En bedre rute ville være å bygge en Fiddler AutoResponder som avlyser din forespørsel og erstatter produksjonsbiblioteket med et av dine valg. Tenk på det i et sekund. Fiddler vil ta forespørselen for din URI og erstatte den med en lokal fil. La oss sjekke det ut.
Først må jeg identifisere URIen jeg vil erstatte. I dette tilfellet ser jeg at bloggens tema kjører jQuery v1.2.6. Det er vanvittig, men før jeg slipper det inn og får ødeleggelse på nettstedet mitt, vil jeg gjerne se om jQuery v1.8.3 fungerer som forventet.
Jeg klikker på oppføringen for jQuery v1.2.6. I høyre kolonne av Fiddler velger jeg kategorien "AutoResponder" og merker "Aktiver automatiske svar". Sparking av responderen er like enkelt som å dra URI i regelredigeren. Du vil legge merke til at det starter regelen ved å sammenligne URI. Hvis det samsvarer, svarer det med et arrangement av ditt valg.
Siden jeg vil teste ut jQuery 1.8.3, vil jeg ha regelen om å bytte ut produksjonsversjonen med en lokal kopi av jQuery som jeg har på min datamaskin.
Jeg lagrer regelen og laster på siden min. Sluttresultatet er at mens URI kan se ut som det samme, kontrollerer resultatene at jQuery v1.8.3 faktisk ble injisert, slik at jeg kan teste dette på fly uten å gjøre noen endringer på nettstedet:
Fra et feilsøkingsperspektiv kan jeg ikke understreke hvor nyttig dette er, spesielt når du prøver å spikre ned en feil i eldre versjoner av et rammeverk eller bibliotek.
Min gode venn Jonathan Sampson gjorde en flott screencast på å bruke denne funksjonen.
>Nettverkslatelse kan være en morder, spesielt for enkeltsidede apper.
Fiddler drar nytte av et omfattende tilleggsøkosystem som utvider sin funksjonalitet via iFiddlerExtension Interface. Det er tilleggsprogrammer som tillater:
Fiddler har i seg selv en TON av funksjoner - for mange til å beskrive i dette innlegget. Det er derfor en 330-siders bok om hvordan du kan dra full nytte av det. Det er bare $ 10, og vil hjelpe deg med å lære inn og ut av dette flotte verktøyet.
Hvis du er på OSX eller Linux, er det beste alternativet Charles Web Debugging Proxy. Det er en flott og godt støttet app, og mens det er kommersielt, er det verdt hver krone. Jeg har søkt etter gode alternativer som fokuserte på webutvikling, og Charles stod virkelig ute.
Grensesnittet ligner Fiddler, men det tilbyr to forskjellige måter å se på nettverkstrafikk:
Stilen er helt opp til deg. Jeg pleier å lene seg mot den strukturerte visningen fordi den føles litt mer organisert, men det er litt mer arbeid for å finne ut hvor en bestemt URI er.
I likhet med Fiddler tilbyr Charles også en autosvarer mulighet. Det kalles "Map Local ...", og du kommer til det ved å høyreklikke på en bestemt URI. Dette lar deg velge en lokal fil å jobbe med.
Når jeg oppdaterer siden, har jeg nå jQuery v1.2.6 erstattet av den lokale kopien av jQuery v1.9 som var på datamaskinen min.
En annen flott funksjon av Charles er evnen til å smelte på nettverksforespørsler for å simulere bestemte båndbreddehastigheter. Jeg husker dagene til 56k modemer og deres bråkete hastigheter, så bruk dette bringer tilbake gode minner (um, høyre):
Charles kan også jobbe med Windows siden den tilbyr et komplett UI-plattform.
Jeg bruker alle disse verktøyene hele tiden fordi jeg tester på alle de store nettleserne. Å ha denne funksjonen gjør det egentlig enklere å feilsøke. Selvfølgelig, å velge om du skal bruke en nettleserbasert sniffer eller en hard-core appbasert proxy, avhenger helt naturlig av feilsøkingsbehovene dine..
Hvis du bare må inspisere trafikk og sjekke resultater, vil en nettbasert sniffer trolig passe deg perfekt.
På den annen side, hvis du trenger granulær kontroll over hvordan URIer svarer eller vil ha fleksibilitet til å lage egendefinerte testskript, så er et verktøy som Fiddler eller Charles hvor du må gå. Det store er at vi har solide valg for å hjelpe oss med å gjøre dette, særlig ettersom kompleksiteten i våre prosjekter øker.
Accentsconagua