Dlaczego zdjęcia w WordPressie są nieostre po przesłaniu (i jak to naprawić)

W dziewięciu przypadkach na dziesięć Twoje zdjęcia wcale nie są rozmazane — WordPress zmniejszył je podczas przesyłania i teraz serwuje pomniejszoną kopię. Od WordPressa 5.3 każde zdjęcie szersze lub wyższe niż 2560px zostaje po cichu zastąpione wersją -scaled ograniczoną do 2560px na dłuższej krawędzi, i to właśnie ten mniejszy plik Twój szablon rozciąga, żeby wypełnić baner, blok o pełnej szerokości albo ekran retina. Naprawa polega na tym, żeby najpierw udowodnić, że tak się właśnie stało, a potem albo podnieść próg, albo przestać przesyłać zdjęcia, które muszą być większe niż miejsce, w którym się znajdują.

Dlaczego tak się dzieje

Kiedy przesyłasz zdjęcie, WordPress uruchamia wp_create_image_subsizes() (w wp-admin/includes/image.php). Jeśli dłuższa krawędź przekracza big_image_size_threshold — domyślnie 2560px — wywołuje _wp_image_meta_replace_original(), generuje your-photo-scaled.jpg i przepisuje metadane załącznika tak, aby rozmiar full wskazywał teraz na pomniejszoną kopię. Twój prawdziwy oryginał pozostaje na dysku jako your-photo.jpg i jest wskazywany przez wp_get_original_image_path(), ale nic na froncie go nie serwuje. Każdy pośredni rozmiar i każdy kandydat srcset jest generowany z pomniejszonego pliku 2560px, a nie z tego, co przesłałeś.

I tu pojawia się nieostrość. Przesyłasz ostre zdjęcie 4000px na nagłówek o pełnej szerokości. WordPress ogranicza je do 2560px. Na standardowym ekranie w kontenerze o szerokości 1600px jest w porządku. Na ekranie retina 2x przeglądarka potrzebuje mniej więcej 3200 rzeczywistych pikseli, żeby ostro wypełnić ten kontener, ma tylko 2560 i różnicę powiększa cyfrowo. Miękkie krawędzie, rozmyty tekst na zdjęciu — dokładnie objaw „nieostrości po przesłaniu”.

Druga połowa tego samego problemu to srcset wybierający zbyt mały rozmiar. Jeśli Twój szablon zgłasza szerokość treści, która nie odpowiada faktycznie wyrenderowanemu miejscu, WordPress podaje przeglądarce pośredni plik -1024x683 albo -1536x1024, a ten zostaje rozciągnięty. Ta sama przyczyna — miejsce wyświetlania większe niż dostępne piksele — inny wyzwalacz.

Sprawdź, co WordPress naprawdę wysłał

Nie zgaduj. Kliknij nieostre zdjęcie prawym przyciskiem, otwórz je w nowej karcie i spójrz na nazwę pliku w adresie URL. Jeśli kończy się na -scaled.jpg albo przyrostkiem z wymiarami w rodzaju -1024x683.jpg, masz potwierdzenie: przeglądarka renderuje pomniejszoną pochodną, a nie to, co przesłałeś. Możesz też zbadać element i odczytać currentSrc, żeby zobaczyć dokładnie, którego kandydata wybrała przeglądarka.

Żeby zobaczyć cały obraz sytuacji zanim cokolwiek prześlesz ponownie, wrzuć zdjęcie do narzędzia rozmiarów zdjęć WordPress — pokaże ono każdą pochodną, którą WordPress wygeneruje z tego konkretnego pliku, w tym czy powstanie kopia -scaled i o jakich wymiarach, dzięki czemu z góry wiesz, czy źródło jest wystarczająco duże dla miejsca, w którym je umieszczasz.

Na serwerze możesz wypisać każdy ograniczony plik:

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

Jak to naprawić, po kolei

1. Jeśli Twoje zdjęcia rzeczywiście muszą być większe niż 2560px (duże banery, retina, galerie w jakości do druku), podnieś próg:

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

Albo wyłącz limit całkowicie:

add_filter( 'big_image_size_threshold', '__return_false' );

2. Prześlij ponownie zmienione zdjęcia. To krok, który ludzie pomijają. Zmiana progu wpływa tylko na nowe przesłania. Zdjęcia już w bibliotece zachowują swoje stare metadane, a regeneracja miniatur przebudowuje pośrednie rozmiary z ograniczonego pliku -scaled — nie przywraca rozdzielczości, która została odrzucona. Pewna droga to: zmień filtr, usuń załącznik, prześlij ponownie.

3. Jeśli Twoje źródło ma już ≤2560px i nadal jest nieostre, próg nie jest Twoim problemem — miejsce wyświetlania jest większe niż zdjęcie. Prześlij większe źródło albo zmniejsz kontener. Dla ostrości na retinie źródło musi mieć mniej więcej dwukrotność szerokości w pikselach CSS miejsca, które wypełnia.

4. Dopiero po powyższym zregeneruj miniaturki, żeby pośrednie rozmiary były spójne — ale pamiętaj, że to porządkowanie, a nie lekarstwo.

Czego nie robić

Nie podkręcaj jakości JPEG do 100. WordPress kompresuje do domyślnej jakości 82 przez wp_editor_set_quality, a połowa porad w sieci każe Ci ją nadpisać:

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

To jest w porządku do redukcji artefaktów kompresji, ale rozciągnięte, powiększone cyfrowo zdjęcie to problem rozdzielczości, a nie kompresji. Przejście z 82 na 100 rozdmuchuje pliki i praktycznie nic nie daje na miękkość, którą widzisz.

Nie wyłączaj -scaled odruchowo. Wyłączenie limitu (jest do tego narzędzie) jest właściwym ruchem, jeśli serwujesz zdjęcia powyżej 2560px — ale jeśli Twoim prawdziwym problemem jest rozciąganie zbyt małego pośredniego pliku, wyłączenie tego niczego nie zmieni, a stracisz oszczędność transferu bez powodu. Najpierw postaw diagnozę.

Nie obwiniaj cache’u ani nie regeneruj miniatur w pierwszej kolejności. Regeneracja czyta z tego samego ograniczonego źródła, więc nie może przywrócić szczegółów. Wyczyszczenie CDN-a albo cache’u strony nie ruszy pliku, który od początku był mały na dysku.

Nie sięgaj po CSS szablonu ani object-fit. Żadne stylowanie nie doda pikseli. Jeśli serwowany plik kończy się na -scaled albo przyrostku z wymiarami, problemem jest plik, a nie układ.

Nadal utknąłeś?

Jeśli potwierdziłeś, że serwowany plik to Twoje przesłanie w pełnej rozdzielczości — bez -scaled, bez przyrostka z wymiarami — a nadal jest miękkie, sprawdź, czy jakaś wtyczka (optymalizator, resizer zdjęć w CDN-ie albo biblioteka lazy-load) nie przepisuje Twojego src na skompresowane proxy. Przepuść zdjęcie przez narzędzie rozmiarów zdjęć, żeby potwierdzić, co WordPress powinien generować, a potem porównaj to z tym, co przeglądarka faktycznie ładuje. Kiedy te dwie rzeczy się nie zgadzają, winowajcą jest coś między WordPressem a przeglądarką.