Pse një imazh dështon ndërsa pjesa tjetër e faqes ngarkohet
Tre kushte ndajnë një defekt rrjeti nga një kërkesë e bllokuar dhe nga një gabim vizatimi. Gjeni URL-në që zgjodhi shfletuesi para se të ndryshoni shtegun.
Faqja ngarkohet, teksti vizatohet dhe një imazh mbetet një ikonë e thyer. Reagimi i parë është të fajësohet tuneli, sepse tuneli është ajo që ndryshoi. Para kësaj, zbuloni cilën URL kërkoi vërtet shfletuesi për atë imazh, sepse URL-ja e faqes dhe URL-ja e imazhit janë dy dëshmi të ndryshme. Shumica e raporteve për një imazh që mungon përfundojnë te një host që nuk mori kurrë një kërkesë funksionale, dhe ai përgjigje kushton një vështrim në panelin Rrjeti.
Tre kushte vendosin ku duhet të shikoni
Kushti i parë është nëse imazhi vjen nga i njëjti host si faqja. Një host i veçantë imazhesh ka nevojë për zgjidhjen e vet të emrave, lidhjen e vet dhe identitetin e vet TLS, kështu që një faqe që ngarkohet nuk thotë asgjë për të.
I dyti është nëse shfletuesi e bllokoi kërkesën para se ta dërgonte. Përmbajtja e përzier, politika e sigurisë së përmbajtjes dhe rregullat e referuesit mund të ndalojnë një imazh pa prodhuar një përgjigje normale serveri, prandaj nuk shfaqet asnjë kërkesë e dështuar në listë.
I treti është nëse dërgimi pati sukses dhe vizatimi dështoi, një rast ku bajtët mbërrijnë dhe imazhi prapë nuk shfaqet. Këto tre kushte kanë tre pronarë të ndryshëm, dhe vetëm i pari është çështje rrjeti.
| 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 |
Gjeni burimin që shfletuesi zgjodhi vërtet
URL-ja që shihni në kodin burimor të faqes shpesh nuk është URL-ja që u kërkua. Grupet e burimeve, elementet picture dhe sfondet CSS u lejojnë të gjitha shfletuesit të zgjedhë një burim tjetër bazuar në gjerësinë e pamjes, dendësinë e pikselave ose mbështetjen e formatit. Një imazh i ngarkuar me përtesë mund të mos kërkohet fare derisa faqja të arrijë një gjendje të caktuar.
Inspektoni elementin dhe kërkesën së bashku, dhe mbani iniciatorin me kërkesën kur raportoni problemin. Referenca e elementit të imazhit e MDN-së mbulon zgjedhjen e burimit, sjelljen e ngarkimit dhe kontrollet e referuesit në një vend, gjë që mjafton për të treguar cili atribut zgjodhi URL-në që dështon.
Regjistroni emrin e hostit, statusin, çdo zinxhir ridrejtimi dhe llojin e përmbajtjes së përgjigjes. Një përgjigje 200 që kthen një faqe hyrjeje nuk është imazh i përdorshëm, dhe një ridrejtim në një faqe gabimi HTML duket identik me një skedar të dëmtuar derisa të lexoni llojin.
Lexoni statusin para rrjetit
Një afat i skaduar, një kërkesë e refuzuar dhe një gabim dekodimi kërkojnë hapa të ndryshëm në vijim, dhe kodi i statusit është ai që i ndan. Afati i skaduar tregon zgjidhjen e emrave, shtegun ose një host që nuk përgjigjet. Kërkesa e refuzuar tregon një politikë ose një shtresë autorizimi. Gabimi i dekodimit tregon bajtët ose formatin.
Nëse kërkesa nuk shfaqet fare, ndaloni së shikuari rrjetin dhe shikoni shënimin. Shkaku më i zakonshëm është një zë në një grup burimesh që shfletuesi e preferoi dhe që nuk ekziston më në server, i ndjekur nga një element që një skript nuk e bëri kurrë të dukshëm.
Vetëm ky dallim parandalon pjesën më të madhe të përpjekjes së humbur në këtë lloj raporti.
Kur shfletuesi e bllokon, nuk ka përgjigje për të lexuar
Përmbajtja e përzier është rasti klasik: një faqe HTTPS që kërkon një imazh përmes HTTP të thjeshtë e merr kërkesën të bllokuar në vend të dështuar, dhe konsola regjistron arsyen. Politika e sigurisë së përmbajtjes jep të njëjtën formë, me direktivën e bllokuar të emërtuar në mesazh. Një politikë referuesi që heq kokën mund të bëjë gjithashtu që një host i mbrojtur nga hotlink të kthejë një vendmbajtëse në vend të imazhit.
Lexoni arsyen e regjistruar para se të prekni shtegun e rrjetit, sepse këto bllokime nuk përmirësohen kur ndryshon rruga. Shtimi i lejeve ndërmjet origjinave gjithashtu nuk është zgjidhja: shfaqja e një imazhi nga një host tjetër dhe leximi i pikselave të tij në canvas janë operacione të ndryshme, dhe vetëm e dyta ka nevojë për kokët që njerëzit ngjitin.
Për një faqe që administroni, korrigjoni URL-në e burimit, përgjigjen ose politikën te pronari i saj dhe mbani të paprekura kërkesat e autorizimit dhe të referuesit. Për një faqe që nuk e kontrolloni, dërgoni faqen dhe provat e kërkesës në kanalin e saj të mbështetjes në vend që të ripublikoni lidhje private ose që skadojnë drejt burimeve.
Krahasoni shtigjet pa ndryshuar provat
Nëse vërtet dëshironi të provoni shtegun e aksesit, mbani gjithçka tjetër konstante: e njëjta faqe, i njëjti llogari, i njëjti imazh i zgjedhur, një shteg i lejuar i ndryshuar. Krahasoni zërat e kërkesave krah për krah në vend të rezultatit të vizatuar, sepse rezultati i vizatuar tregon nëse imazhi u shfaq, jo pse.
Një imazh që ngarkohet në një rrugë të re nuk provon që ajo rrugë është e autorizuar, dhe një imazh që mbetet i thyer nuk provon që tuneli është fajtor. Nëse imazhi është hequr ose aksesi është kufizuar qëllimisht, përdorni një alternativë të mbështetur në vend që të çaktivizoni kontrollet e certifikatës ose të kopjoni materialin e mbrojtur të dikujt tjetër.
Rendi i punës: identifikoni URL-në e zgjedhur, lexoni statusin dhe llojin e saj, kontrolloni nëse ka një arsye bllokimi të regjistruar, më pas krahasoni një ndryshim shtegu në një herë.