Share
I miei due precedenti articoli si sono concentrati sugli strumenti di debug, quindi è giusto che continui con questo tema. Quando esegui il debug del codice front-end, tendi a dedicare molto tempo a esaminare come i CSS e JavaScript influenzano il rendering della tua pagina; altrettanto importante è il modo in cui le richieste di rete influenzano il tuo sito. In molti casi, lavoriamo localmente e dimentichiamo che le dimensioni della pagina, la latenza e il caricamento e il blocco degli script possono influire notevolmente sul modo in cui un utente sperimenta il tuo sito. Quindi avere un buon set di strumenti per ispezionare il traffico di rete è fondamentale per completare il set di strumenti di debug.
Per fortuna, tutti i principali browser moderni forniscono strumenti di debug che consentono di ispezionare il traffico di rete e strumenti di terze parti come Fiddler e Charles non solo consentono di visualizzare le richieste di rete, ma offrono funzionalità estese per interagire con il tuo sito.
Esploreremo entrambi i tipi di strumenti.
Come ho già detto, ogni browser principale ha strumenti di debug integrati. Questi includono:
Ogni set ha le proprie capacità uniche, ma ognuna ha la capacità di raccogliere il traffico di rete. Se guardiamo le seguenti immagini, puoi vedere che mentre le interfacce utente possono variare, i dati raccolti e visualizzati sono molto simili:
Il risultato finale è un elenco delle richieste di rete del browser coinvolte nel download delle risorse o dei dati delle nostre pagine. Lo strumento di rete è in grado di intercettare queste richieste per mostrare dati importanti come:
Fiddler prenderà la richiesta per l'URI e la sostituirà con un file locale.
Quindi, se guardiamo i risultati di Firebug, possiamo vedere che la richiesta ha richiamato la pagina principale e i file CSS e JavaScript associati, incluse le risorse di AWS di Amazon. A causa dei vincoli di immagine, non posso mostrarti tutto ciò che ha caricato, ma c'erano anche file immagine e file swf Flash che sono stati restituiti.
Con queste informazioni, ora posso eseguire il drill-down in richieste specifiche per determinare se sto ricevendo i dati corretti, o perché potrei avere una richiesta di lunga durata. Supponiamo che guardi la richiesta del file JavaScript di Webtrend. Ci sono voluti 1,2 secondi per il download e voglio vedere come viene gestita la richiesta. Posso espandere la richiesta e determinare se è compressa (è):
e se è stato minimizzato:
In questo caso, il file non è stato minimizzato e posso seguire lo sviluppatore per determinare se ha senso farlo. Certo, è un file 2K, ma ogni byte è importante e questa informazione mi consente di ottimizzare al meglio il mio sito.
La latenza della rete può essere un killer, in particolare per le app a pagina singola che dipendono da API esterne o da più file di script per le loro capacità. La maggior parte dei browser tenta di caricare le risorse in modo asincrono quando è possibile, ma alcune, come i file JavaScript, possono causare eventi di blocco. È importante essere in grado di bloccarli per ottimizzare il più possibile il caricamento delle risorse. Se guardiamo questa immagine, puoi vedere che il file impiega 1,4 secondi per caricare:
Passando il mouse sopra le linee temporali, otteniamo una finestra di dialogo che ci offre una panoramica del modo in cui la richiesta è progredita:
Parte di questo era perché era bloccato dal caricamento per 760ms. Se questo si è rivelato un problema pervasivo, è possibile esaminare l'utilizzo di un caricatore di script come RequireJS per gestire meglio il caricamento e le dipendenze degli script.
Poiché le app dinamiche sono così pervasive, è fondamentale poter ispezionare le chiamate XHR. In precedenza, hai visto un sacco di richieste di rete e tentare di filtrarle tutte per trovare le tue chiamate XHR non è efficiente. Per questo motivo, la maggior parte degli strumenti ti consente di scegliere i tipi di richieste che desideri vengano visualizzati. Qui sto filtrando per richieste XHR, così posso valutare la richiesta e la risposta:
Eseguendo il drill down nella richiesta, posso valutare dettagli importanti sulla richiesta, come le intestazioni e lo stato, il metodo di richiesta, i cookie e, soprattutto, la risposta che è stata restituita:
In questo caso, l'HTML è stato restituito, ma la risposta potrebbe essere qualsiasi cosa che includa testo, JSON o XML. La cosa bella è che sono in grado di ispezionarlo completamente nel caso mi capitasse qualche problema.
I cookie sono incredibilmente utili, e dal momento che li utilizziamo ampiamente, avere un modo semplice per ispezionare i loro valori rende la vita più facile. Gli strumenti di sviluppo rendono semplice farlo mostrandoti quali cookie sono stati inviati e ricevuti:
Se hai mai fatto sviluppo sul lato server senza strumenti lato client, saprai perché è così fantastico.
Nel complesso, la cosa grandiosa di questo è che la capacità è giusta nel tuo browser, rendendo incredibilmente conveniente far apparire il debugger e controllare le cose. A volte, però, hai bisogno di un po 'più di potenza.
Le applicazioni proxy HTTP come Fiddler e Charles Web Debugging Proxy sono i grandi fratelli degli sniffer di traffico di rete basati su browser. Non solo possono intercettare le richieste di rete dal browser ma anche altre applicazioni sulla tua macchina, rendendole molto più versatili per il debug. Inoltre tendono a offrire funzionalità più ricche come:
Uso estensivamente il Fiddler basato su Windows, incredibilmente ricco di funzionalità (è gratuito!). Viene anche utilizzato pesantemente all'interno di Microsoft a causa del suo robusto set di funzionalità. Lo sviluppatore di Fiddler, Eric Lawrence, in precedenza ha lavorato in Microsoft e mantiene ancora l'applicazione.
Se guardiamo l'interfaccia utente, vedremo le somiglianze nell'output a ciò che abbiamo visto negli strumenti del browser. Tutte le richieste di rete vengono visualizzate insieme alle informazioni chiave relative alle richieste.
Inserendo una richiesta, è possibile visualizzare dettagli dettagliati su di esso, inclusa la fonte miniata della libreria jQuery:
Molte di queste informazioni possono essere ritirate tramite gli strumenti basati su browser, ma cosa succede quando si desidera verificare se una specifica libreria sta facendo esplodere il proprio sito? Puoi sicuramente scambiare le librerie e risolvere i problemi. Un percorso migliore sarebbe costruire un risponditore automatico Fiddler che intercetti la tua richiesta e sostituisca la libreria di produzione con una di tua scelta. Pensaci per un secondo. Fiddler prenderà la richiesta per l'URI e la sostituirà con un file locale. Controlliamolo.
Innanzitutto, ho bisogno di identificare l'URI che voglio sostituire. In questo caso, vedo che il tema del mio blog è in esecuzione jQuery v1.2.6. È pazzesco, ma prima di rilasciarlo e provocare il caos nel mio sito, vorrei vedere se jQuery v1.8.3 funziona come previsto.
Faccio clic sulla voce per jQuery v1.2.6. Nella colonna di destra di Fiddler, seleziono la scheda "AutoResponder" e spunta "Abilita risposte automatiche". Dare il via al risponditore è semplice come trascinare l'URI nell'editor delle regole. Noterai che avvia la regola confrontando l'URI. Se corrisponde, risponderà con un evento di tua scelta.
Dal momento che voglio testare jQuery 1.8.3, voglio che la regola cambi la versione di produzione con una copia locale di jQuery che ho sul mio computer.
Salvo la regola e ricarico la mia pagina. Il risultato finale è che mentre l'URI può sembrare lo stesso, ispezionando i risultati si verifica che jQuery v1.8.3 sia stato effettivamente iniettato, permettendomi di testare questo al volo senza apportare modifiche al sito:
Da una prospettiva di debug, non posso sottolineare quanto sia utile, specialmente quando stai cercando di rintracciare un bug nelle versioni precedenti di un framework o di una libreria.
Il mio buon amico Jonathan Sampson ha fatto un ottimo screencast sull'utilizzo di questa funzione.
>La latenza della rete può essere un killer, soprattutto per le app a pagina singola.
Fiddler beneficia di un ampio ecosistema aggiuntivo che estende le sue funzionalità tramite l'interfaccia iFiddlerExtension. Esistono componenti aggiuntivi che consentono:
Di per sé, Fiddler ha un numero di funzionalità - troppe da descrivere in questo post. Ecco perché c'è un libro di 330 pagine su come trarne il massimo vantaggio. Sono solo $ 10 e ti aiuteranno a imparare l'interno e l'esterno di questo fantastico strumento.
Se utilizzi OSX o Linux, l'opzione migliore è il proxy di debug del Web Charles. È un'app fantastica e ben supportata e, anche se commerciale, vale ogni centesimo. Ho cercato buone alternative incentrate sullo sviluppo web e Charles si è distinto davvero.
L'interfaccia è simile a Fiddler, ma offre due diversi modi di guardare il traffico di rete:
Lo stile è interamente a te. Tendo ad orientarmi verso la vista strutturata perché ci si sente un po 'più organizzati, ma è un po' più di lavoro per scoprire dove un URI specifico è.
Come Fiddler, Charles offre anche una capacità di risposta automatica. Si chiama "Map Local ..." e ci si arriva facendo clic con il tasto destro del mouse su un URI specifico. Questo ti permette di scegliere un file locale con cui lavorare.
Quando ricarico la pagina, ora ho jQuery v1.2.6 sostituito dalla copia locale di jQuery v1.9 che era sul mio computer.
Un'altra grande caratteristica di Charles è la capacità di limitare le richieste di rete per simulare specifiche velocità di banda. Ricordo i giorni dei modem a 56k e le loro folgoranti velocità, quindi l'uso di questo richiama bei ricordi (ehm, giusto):
Charles può anche lavorare su Windows poiché offre un'interfaccia utente multipiattaforma completa.
Uso tutti questi strumenti tutto il tempo perché eseguo il test su tutti i principali browser. Avere questa capacità rende davvero più facile la risoluzione dei problemi. Naturalmente, scegliere se utilizzare uno sniffer basato su browser o un proxy basato su app hard-core dipende interamente dalle esigenze di debug.
Se devi solo ispezionare il traffico e verificare i risultati, uno sniffer basato su browser molto probabilmente ti si addice perfettamente.
D'altra parte, se hai bisogno di un controllo granulare su come gli URI rispondono o vuoi la flessibilità per creare script di test personalizzati, allora uno strumento come Fiddler o Charles è dove devi andare. Il bello è che abbiamo solide scelte per aiutarci a farlo, soprattutto con l'aumentare della complessità dei nostri progetti.
Accentsconagua