De ce eșuează o imagine în timp ce restul paginii se încarcă
Trei condiții separă o defecțiune de rețea de o cerere blocată și de o eroare de randare. Găsiți URL-ul pe care l-a ales browserul înainte de a schimba calea.
Pagina se încarcă, textul este randat, iar o imagine rămâne o pictogramă ruptă. Prima reacție este să dăm vina pe tunel, pentru că tunelul este lucrul care s-a schimbat. Înainte de asta, aflați ce URL a cerut de fapt browserul pentru acea imagine, pentru că URL-ul paginii și URL-ul imaginii sunt două dovezi diferite. Majoritatea rapoartelor despre o imagine lipsă ajung la un host care nu a primit niciodată o cerere funcțională, iar acel răspuns costă o privire în panoul Rețea.
Trei condiții decid unde să căutați
Prima condiție este dacă imaginea provine de pe același host ca pagina. Un host separat de imagini are nevoie de propria rezoluție a numelor, de propria conexiune și de propria identitate TLS, așa că o pagină care se încarcă nu spune nimic despre el.
A doua este dacă browserul a blocat cererea înainte de a o trimite. Conținutul mixt, politica de securitate a conținutului și regulile de referrer pot opri o imagine fără a produce un răspuns normal de server, de aceea în listă nu apare nicio cerere eșuată.
A treia este dacă livrarea a reușit și randarea a eșuat, un caz în care octeții ajung și imaginea tot nu apare. Aceste trei condiții au trei proprietari diferiți, și doar prima este o problemă de rețea.
| What you see | Where the fault sits |
|---|---|
| Request absent from the list | Markup, lazy loading or a policy that blocked it |
| Request failed or timed out | Resolution, route, TLS or the image host itself |
| Request returned 200, image blank | Response type, decoding or rendering |
Găsiți resursa pe care browserul a ales-o de fapt
URL-ul pe care îl vedeți în codul sursă al paginii adesea nu este URL-ul care a fost cerut. Seturile de surse, elementele picture și fundalurile CSS le permit browserului să aleagă o altă resursă în funcție de lățimea ferestrei, densitatea de pixeli sau suportul pentru format. O imagine încărcată leneș poate să nu fie cerută deloc până când pagina ajunge într-o anumită stare.
Inspectați elementul și cererea împreună, și păstrați inițiatorul lângă cerere când raportați problema. Referința elementului imagine de la MDN acoperă selecția sursei, comportamentul de încărcare și controalele de referrer într-un singur loc, ceea ce este suficient pentru a spune ce atribut a ales URL-ul care eșuează.
Notați numele hostului, starea, orice lanț de redirecționări și tipul de conținut al răspunsului. Un răspuns 200 care returnează o pagină de autentificare nu este o imagine utilizabilă, iar o redirecționare către o pagină de eroare HTML arată identic cu un fișier deteriorat până când citiți tipul.
Citiți starea înaintea rețelei
Un timeout, o cerere refuzată și o eroare de decodare necesită pași următori diferiți, iar codul de stare este cel care le separă. Un timeout indică rezoluția numelor, ruta sau un host care nu răspunde. O cerere refuzată indică o politică sau un strat de autorizare. O eroare de decodare indică octeții sau formatul.
Dacă cererea nu apare deloc, opriți-vă din a privi rețeaua și priviți marcajul. Cea mai frecventă cauză este o intrare dintr-un set de surse pe care browserul a preferat-o și care nu mai există pe server, urmată de un element pe care un script nu l-a făcut niciodată vizibil.
Doar această distincție evită cea mai mare parte a efortului risipit în acest tip de rapoarte.
Când browserul îl blochează, nu există niciun răspuns de citit
Conținutul mixt este cazul clasic: o pagină HTTPS care cere o imagine prin HTTP simplu primește cererea blocată, nu eșuată, iar consola înregistrează motivul. Politica de securitate a conținutului produce aceeași formă, cu directiva blocată numită în mesaj. O politică de referrer care elimină antetul poate determina un host protejat împotriva hotlinkului să returneze un substituent în locul imaginii.
Citiți motivul înregistrat înainte de a atinge calea de rețea, pentru că aceste blocaje nu se îmbunătățesc atunci când ruta se schimbă. Nici adăugarea permisiunilor cross-origin nu este soluția: afișarea unei imagini de pe alt host și citirea pixelilor ei într-un canvas sunt operații diferite, iar doar a doua are nevoie de anteturile pe care oamenii le lipesc.
Pentru un site pe care îl administrați, corectați URL-ul resursei, răspunsul sau politica la proprietarul ei și păstrați intacte cerințele de autorizare și de referrer. Pentru un site pe care nu îl controlați, trimiteți pagina și dovezile cererii către canalul său de suport în loc să republicați linkuri private sau expirate către resurse.
Comparați căi fără a schimba dovezile
Dacă vreți într-adevăr să testați calea de acces, păstrați tot restul constant: aceeași pagină, același cont, aceeași imagine selectată, o singură cale permisă schimbată. Comparați intrările cererilor una lângă alta, nu rezultatul randat, pentru că rezultatul randat spune dacă imaginea a apărut, nu de ce.
O imagine care se încarcă pe o rută nouă nu dovedește că ruta este autorizată, iar o imagine care rămâne ruptă nu dovedește că tunelul este vinovat. Dacă imaginea a fost eliminată sau accesul este restricționat intenționat, folosiți o alternativă acceptată în loc să dezactivați verificările de certificat sau să copiați materialul protejat al altcuiva.
Ordinea de lucru: identificați URL-ul selectat, citiți starea și tipul, verificați dacă există un motiv de blocare înregistrat, apoi comparați o singură schimbare de cale o dată.