Share
Primele mele două articole s-au concentrat asupra instrumentelor de depanare, așadar este potrivit doar să continui această temă. Când depanați codul frontal, aveți tendința de a petrece mult timp pentru a examina modul în care CSS și JavaScript afectează randarea paginii dvs.; la fel de important este modul în care solicitările de rețea afectează site-ul dvs. În multe cazuri, lucrăm local și uităm că dimensiunea paginii, latența și încărcarea și blocarea scriptului pot afecta foarte mult modul în care un utilizator întâlnește site-ul dvs. Deci, având un set bun de instrumente pentru a inspecta traficul de rețea este vital pentru a rotunji setul de instrumente de depanare.
Din fericire, toate browserele moderne moderne oferă instrumente de depanare care vă permit să examinați traficul în rețea, iar instrumentele de la al treilea rând, cum ar fi Fiddler și Charles, nu vă permit doar să vedeți solicitări de rețea, ci să oferiți posibilități extinse de a interacționa cu site-ul dvs..
Vom explora ambele tipuri de instrumente.
După cum am menționat, fiecare browser major are instrumente integrate de depanare. Acestea includ:
Fiecare set are propriile capabilități unice, dar fiecare are capacitatea de a colecta traficul în rețea. Dacă ne uităm la următoarele imagini, puteți vedea că, în timp ce interfațele utilizatorilor pot varia, datele colectate și afișate sunt foarte asemănătoare:
Rezultatul final este o listă a solicitărilor de rețea ale browserului implicate în descărcarea materialelor sau datelor paginilor noastre. Instrumentul de rețea poate intercepta aceste solicitări pentru a vă arăta date importante precum:
Fiddler va lua cererea pentru URI și îl va înlocui cu un fișier local.
Deci, dacă privim rezultatele de la Firebug, putem vedea că cererea a tras înapoi pagina principală și fișierele asociate CSS și JavaScript, inclusiv activele de la AWS din Amazon. Din cauza constrângerilor imaginii, nu vă pot arăta tot ce a fost încărcat, dar au fost și fișiere de imagine și Flash swf care au fost returnate.
Având aceste informații, acum pot să analizez anumite cereri pentru a determina dacă primesc datele potrivite sau de ce ar putea să am o cerere de lungă durată. Să presupunem că mă uit la cererea pentru fișierul JavaScript Webtrend. Au fost necesare 1,2 secunde pentru descărcare și vreau să văd cum este tratată cererea. Pot să extind cererea și să determin dacă este gzipped (este):
și dacă a fost minificată:
În acest caz, fișierul nu a fost miniat și pot continua cu dezvoltatorul pentru a determina dacă are sens să facă acest lucru. Acordat, este un fișier 2K, dar fiecare octet contează și aceste informații îmi permit să optimizez mai bine site-ul meu.
Latența la rețea poate fi un criminal, mai ales pentru aplicațiile de o singură pagină care depind de API-uri externe sau de mai multe fișiere de script-uri pentru capacitatea lor. Cele mai multe browsere încearcă să încarce în mod asincron active atunci când pot, dar unele, cum ar fi fișiere JavaScript, pot provoca evenimente de blocare. Este important să fiți capabili să le fixați în jos pentru a optimiza cât mai mult posibil încărcarea resurselor. Dacă ne uităm la această imagine, puteți vedea că fișierul a luat 1,4 secunde pentru încărcare:
Deplasându-ne peste termenele de timp, avem un dialog care ne dă o defalcare a modului în care cererea a progresat:
O parte din acest lucru a fost pentru că a fost blocat de la încărcare pentru 760ms. Dacă acest lucru sa dovedit a fi o problemă omniprezentă, ați putea analiza utilizarea unui încărcător de sarcini, cum ar fi RequireJS, pentru a gestiona mai bine încărcarea și dependențele de script.
Deoarece aplicațiile dinamice sunt atât de răspândite, posibilitatea de a inspecta apelurile XHR este vitală. Anterior, ați văzut o mulțime de solicitări de rețea și încercarea de a filtra prin toate acestea pentru a găsi apelurile XHR nu este eficientă. Din această cauză, majoritatea instrumentelor vă permit să alegeți tipurile de solicitări pe care doriți să le afișați. Aici filtrez prin cereri XHR pentru a putea evalua solicitarea și răspunsul:
Gândindu-mă la cerere, pot evalua detalii importante despre solicitare, cum ar fi anteturile și starea, metoda de solicitare, cookie-urile și, cel mai important, răspunsul care a fost returnat:
HTML a fost returnat în acest caz, dar răspunsul ar putea fi orice, inclusiv text, JSON sau XML. Lucrul grozav este că pot să inspectez complet în cazul în care întâmpin probleme.
Cookie-urile sunt incredibil de utile și, din moment ce le folosim pe scară largă, o modalitate ușoară de a le inspecta valorile face viața mai ușoară. Instrumentele pentru dezvoltatori facilitează acest lucru prin afișarea mesajelor cookie-uri care au fost trimise și primite:
Dacă ați realizat vreodată dezvoltarea server-ului fără instrumentele clientului, veți ști de ce este așa de minunat.
În general, lucrurile minunate despre acest lucru sunt că capacitatea este corectă în browser-ul dvs., făcând-o incredibil de convenabil să afișați aplicația de depanare și să verificați lucrurile. Uneori, totuși, aveți nevoie de puțin mai mult cai putere.
Aplicațiile HTTP Proxy, cum ar fi Fiddler și Charles Web Debugging Proxy, sunt frații mai mari ai sniffers-ului de rețea bazat pe browser. Nu numai că pot intercepta cereri de rețea din browser, dar și alte aplicații de pe mașină, făcându-le mult mai versatile pentru depanare. De asemenea, ele tind să ofere caracteristici mai bogate, cum ar fi:
Folosesc extensiv Fiddler-ul bazat pe Windows, cu o caracteristică incredibil de bogată (este gratuit!). De asemenea, este folosit foarte mult în interiorul Microsoft datorită setului de caracteristici robust. Dezvoltatorul lui Fiddler, Eric Lawrence, a lucrat anterior la Microsoft și încă menține aplicația.
Dacă ne uităm la interfața utilizator, veți vedea asemănări în ieșire cu ceea ce am văzut în instrumentele de browser. Toate solicitările de rețea apar împreună cu informații cheie despre solicitări.
Și prin forarea unei cereri, văd detalii detaliate despre aceasta, inclusiv sursa miniaturală a bibliotecii jQuery:
O mare parte din aceste informații pot fi retrase prin intermediul instrumentelor bazate pe browser, dar ce se întâmplă atunci când doriți să vedeți dacă o anumită bibliotecă explodează pe site-ul dvs.? Puteți schimba cu siguranță bibliotecile și depanarea. O rută mai bună ar fi să construiți un Feddler AutoResponder care interceptează cererea dvs. și înlocuiește biblioteca de producție cu una la alegere. Gândește-te la asta pentru o secundă. Fiddler va lua cererea pentru URI și îl va înlocui cu un fișier local. Hai să verificăm.
În primul rând, trebuie să identific identitatea URI pe care vreau să o înlocuiesc. În acest caz, văd că tema blogului meu rulează jQuery v1.2.6. Asta e nebun, dar inainte sa o dau jos si sa fac ravagii pe site-ul meu, as vrea sa vad daca jQuery v1.8.3 functioneaza asa cum era de asteptat.
Clic pe intrarea pentru jQuery v1.2.6. În coloana din dreapta a Fiddler, selectați fila "AutoResponder" și bifați "Activați răspunsurile automate". Înlăturarea răspunsului este la fel de simplă ca tragerea URI în editorul de reguli. Veți observa că începe regula prin compararea URI-ului. Dacă se potrivește, va răspunde cu un eveniment la alegere.
Deoarece vreau să testez jQuery 1.8.3, vreau ca regula să schimbe versiunea de producție cu o copie locală a jQuery pe care o am pe calculatorul meu.
Salvez regula și reîncarc pagina. Rezultatul final este că, în timp ce URI ar putea arăta la fel, verificarea rezultatelor verifică faptul că jQuery v1.8.3 a fost de fapt injectat, permițându-mi să testez acest lucru fără probleme, fără a face nicio modificare pe site:
Din perspectiva unei depanare, nu pot să subliniez cât de util este acest lucru, mai ales atunci când încercați să eliminați un bug în versiunile mai vechi ale unui cadru sau al unei biblioteci.
Prietenul meu bun, Jonathan Sampson, a realizat un mare succes în utilizarea acestei funcții.
>Latența la rețea poate fi un criminal, mai ales pentru aplicațiile de o singură pagină.
Fiddler beneficiază de un ecosistem extins extensiv care își extinde funcționalitatea prin interfața iFiddlerExtension. Există suplimente care permit:
În sine, Fiddler are un TON de caracteristici - prea multe pentru a descrie în acest post. De aceea există o carte de 330 de pagini cu privire la modul în care puteți profita din plin de aceasta. Este vorba doar de 10 USD și vă va ajuta să aflați avantajele și avantajele acestui instrument minunat.
Dacă sunteți pe OSX sau Linux, cea mai bună opțiune este Charles Web Debugging Proxy. Este o aplicație excelentă și bine susținută, iar în timp ce este comercială, merită fiecare ban. Am căutat alternative bune care s-au axat pe dezvoltarea web-ului, iar Charles a ieșit cu adevărat.
Interfața este similară cu cea a Fiddler, dar oferă două moduri diferite de a privi traficul în rețea:
Stilul depinde în întregime de dvs. Am tendința să mă aplec spre viziunea structurată, deoarece se simte puțin mai organizată, dar este puțin mai mult să afli unde este URI specific.
Ca și Fiddler, Charles oferă și o capacitate de autoresponder. Se numește "Harta locală ..." și faceți clic pe butonul din dreapta al mouse-ului pe un anumit URI. Aceasta vă permite să alegeți un fișier local cu care să lucrați.
Când reîncarc pagina, voi avea acum jQuery v1.2.6 înlocuit de copia locală a jQuery v1.9 care a fost pe calculatorul meu.
O altă caracteristică excelentă a lui Charles este abilitatea de a accelera cererile dvs. de rețea pentru a simula viteze specifice de lățime de bandă. Îmi aduc aminte de zilele de modemuri de 56k și de viteza lor aprinsă, astfel că, folosind asta, amintirile frumoase (um, right)
Charles poate lucra, de asemenea, pe Windows, deoarece oferă un interfață complet cross-platform.
Folosesc toate aceste instrumente tot timpul, deoarece testez pe fiecare browser major. Având această capacitate face cu ușurință depanarea. Firește, alegerea dacă doriți să utilizați un proxy de bază pentru browser sau un proxy bazat pe aplicații depinde în întregime de nevoile dvs. de depanare.
Dacă trebuie doar să inspectați traficul și să verificați rezultatele, un sniffer bazat pe browser vă va potrivi cel mai bine perfect.
Pe de altă parte, dacă aveți nevoie de un control granular pentru modul în care răspunsurile URI sau doriți flexibilitatea de a crea scripturi personalizate de testare, atunci un instrument ca Fiddler sau Charles este locul unde trebuie să mergeți. Cel mai mare lucru este că avem alegeri solide care ne ajută să facem acest lucru, mai ales că complexitatea proiectelor noastre crește.
Accentsconagua