De ce imaginile din WordPress apar neclare după încărcare (și cum rezolvi)

În nouă cazuri din zece imaginile nu sunt de fapt neclare — WordPress le-a micșorat la încărcare și acum servește copia limitată. Începând cu WordPress 5.3, orice imagine mai lată sau mai înaltă de 2560px este înlocuită în tăcere cu o versiune -scaled limitată la 2560px pe latura cea mai lungă, iar acel fișier mai mic este cel pe care tema ta îl întinde pentru a umple un hero, un bloc pe toată lățimea sau un ecran retina. Soluția este să dovedești că asta s-a întâmplat, apoi fie să ridici pragul, fie să nu mai încarci imagini care trebuie să fie mai mari decât caseta în care stau.

De ce se întâmplă

Când încarci o fotografie, WordPress rulează wp_create_image_subsizes() (în wp-admin/includes/image.php). Dacă latura cea mai lungă depășește big_image_size_threshold — 2560px în mod implicit — apelează _wp_image_meta_replace_original(), generează your-photo-scaled.jpg și rescrie metadatele atașamentului astfel încât dimensiunea full să indice acum copia redimensionată. Originalul tău real este păstrat pe disc ca your-photo.jpg și referențiat de wp_get_original_image_path(), dar nimic din front end nu îl servește. Fiecare dimensiune intermediară și fiecare candidat srcset este generat din fișierul redimensionat la 2560px, nu din ceea ce ai încărcat.

Deci iată de unde vine neclaritatea. Încarci o imagine clară de 4000px pentru un header pe toată lățimea. WordPress o limitează la 2560px. Pe un ecran standard, într-un container lat de 1600px, e în regulă. Pe un ecran retina 2x browserul are nevoie de aproximativ 3200 de pixeli reali ca să umple clar acel container, are doar 2560 și mărește artificial diferența. Margini estompate, text-în-imagine cețos, exact simptomul „neclar după încărcare”.

Cealaltă jumătate a aceleiași probleme este srcset care alege o dimensiune prea mică. Dacă tema ta raportează o lățime de conținut care nu se potrivește cu caseta redată efectiv, WordPress îi dă browserului un intermediar de tip -1024x683 sau -1536x1024, iar acesta este întins. Aceeași cauză — caseta de afișare mai mare decât pixelii disponibili — dar declanșator diferit.

Verifică ce a servit de fapt WordPress

Nu ghici. Dă click dreapta pe imaginea neclară, deschide-o într-o filă nouă și uită-te la numele fișierului din URL. Dacă se termină în -scaled.jpg sau cu un sufix de dimensiune precum -1024x683.jpg, ai confirmarea: browserul redă un derivat micșorat, nu imaginea ta încărcată. Poți de asemenea inspecta elementul și citi currentSrc pentru a vedea exact ce candidat a ales browserul.

Ca să vezi întreaga imagine de ansamblu înainte de a reîncărca ceva, aruncă imaginea în instrumentul de dimensiuni pentru imagini WordPress — îți arată fiecare derivat pe care WordPress îl va genera din exact acel fișier, inclusiv dacă se creează o copie -scaled și la ce dimensiuni, ca să știi din start dacă sursa ta este suficient de mare pentru locul în care o pui.

Pe server poți lista fiecare fișier limitat:

find wp-content/uploads -name '*-scaled.*'

Cum să rezolvi, în ordine

1. Dacă imaginile tale au nevoie în mod legitim să fie mai mari de 2560px (hero-uri mari, retina, galerii de calitate pentru print), ridică pragul:

// functions.php or a small mu-plugin
add_filter( 'big_image_size_threshold', function () {
    return 3840; // longest edge, in pixels
} );

Sau dezactivează complet limita:

add_filter( 'big_image_size_threshold', '__return_false' );

2. Reîncarcă imaginile afectate. Acesta este pasul pe care oamenii îl sar. Modificarea pragului afectează doar încărcările noi. Imaginile deja existente în bibliotecă își păstrează metadatele vechi, iar regenerarea miniaturilor reconstruiește dimensiunile intermediare din fișierul limitat -scaled — nu adaugă înapoi rezoluția care a fost aruncată. Calea sigură este: schimbă filtrul, șterge atașamentul, încarcă din nou.

3. Dacă sursa ta este deja ≤2560px și tot neclară, pragul nu este problema ta — caseta de afișare este mai mare decât imaginea. Încarcă o sursă mai mare sau micșorează containerul. Pentru claritate retina, sursa ta trebuie să aibă aproximativ dublul lățimii în pixeli CSS a casetei pe care o umple.

4. Abia după cele de mai sus, regenerează miniaturile ca dimensiunile intermediare să fie consistente — dar înțelege că e curățenie, nu un leac.

Ce să nu faci

Nu urca calitatea JPEG la 100. WordPress comprimă la o calitate implicită de 82 prin wp_editor_set_quality, iar jumătate din sfaturile de pe internet îți spun să o suprascrii:

add_filter( 'wp_editor_set_quality', function () { return 90; } );

Asta e în regulă pentru reducerea artefactelor de compresie, dar o imagine întinsă și mărită artificial este o problemă de rezoluție, nu de compresie. Trecerea de la 82 la 100 îți umflă fișierele și nu face aproape nimic pentru neclaritatea pe care o vezi.

Nu dezactiva -scaled ca reflex. Oprirea limitei (există un instrument pentru asta) este alegerea corectă dacă servești imagini peste 2560px — dar dacă problema ta reală este un intermediar prea mic care se întinde, dezactivarea nu schimbă nimic și pierzi economia de lățime de bandă degeaba. Diagnostichează mai întâi.

Nu da vina pe cache și nu regenera miniaturile mai întâi. Regenerarea citește din aceeași sursă limitată, deci nu poate restabili detaliile. Golirea unui CDN sau a unui cache de pagină nu va atinge un fișier care era mic pe disc de la bun început.

Nu apela la CSS-ul temei sau la object-fit. Niciun stil nu adaugă pixeli. Dacă fișierul servit se termină în -scaled sau cu un sufix de dimensiune, problema este fișierul, nu aspectul.

Tot blocat?

Dacă ai confirmat că fișierul servit este imaginea ta încărcată la rezoluție completă — fără -scaled, fără sufix de dimensiune — și tot este cețoasă, verifică dacă un plugin (un optimizator, un redimensionator de imagini de tip CDN sau o bibliotecă de lazy-load) îți rescrie src-ul către un proxy comprimat. Rulează imaginea prin instrumentul de dimensiuni pentru imagini ca să confirmi ce ar trebui să genereze WordPress, apoi compară cu ceea ce încarcă efectiv browserul. Când cele două nu coincid, ceva dintre WordPress și browser este vinovatul.