Dowiedz się, jak systemy CMS, takie jak WordPress, i inne generatory witryn, mogą ułatwić korzystanie z elastycznych obrazów.
Chociaż usprawnienie w stosunku do ręcznego zapisywania alternatywnych cięć każdego zdjęcia i ręcznej ich optymalizacji za pomocą narzędzia takiego jak Squoosh.app, wiąże się z pewnymi ograniczeniami w zakresie automatycznej kompresji obrazów na etapie opracowywania. Po pierwsze, nie zawsze masz pełną kontrolę nad obrazami używanymi w witrynie. Większość obrazów widocznych dla użytkowników w internecie dotyczy raczej treści niż kwestii programistycznych przesyłanych przez użytkowników lub redaktorów. Dzieje się tak, jakby nie mieszkać w repozytorium razem z zasobami dla programistów, takimi jak JavaScript i arkusze stylów.
W związku z tym zarządzanie obrazami wymaga zwykle więcej niż 1 procesu zarządzania obrazami: zadań związanych z opracowaniem zasobów graficznych używanych w tworzeniu i utrzymywaniu witryny (tła, ikon, logo itd.) oraz drugiego z zasobami z obrazem generowanymi przez użycie witryny, takimi jak zdjęcia umieszczone w postach przez zespół redakcyjny czy awatary przesłane przez użytkownika. Mimo że kontekst może być inny, cele końcowe są te same: automatyczne kodowanie i kompresja na podstawie ustawień zdefiniowanych przez zespół programistów.
Na szczęście biblioteki przetwarzania obrazów poznawane w ramach lokalnych procesów programowania można wykorzystać w dowolnej liczbie kontekstów. Mimo że nie ma uniwersalnego podejścia do elastycznych znaczników obrazów, systemy te udostępniają rozsądne ustawienia domyślne, opcje konfiguracji i punkty zaczepienia interfejsu API, które ułatwiają ich implementację.
Generatory witryn statycznych
Istnieje pewne podobieństwo do generatorów statycznych witryn, np. Jekyll lub Eleventy. Użycie tych narzędzi do utworzenia witryny gotowej do wdrożenia wymaga zarządzania zasobami, w tym minifikacji CSS lub transpilacji i pakietowania kodu JavaScript. Te narzędzia pozwalają przetwarzać zasoby graficzne w ten sam sposób, korzystając z wielu bibliotek, które już znasz.
Oficjalna wtyczka obrazów dla Eleventy korzysta z narzędzia Sharp, aby zmieniać rozmiar, generować wiele rozmiarów źródeł, ponownie kodować i kompresować – podobnie jak w przypadku niektórych omówionych tu funkcji.
W przeciwieństwie do mechanizmu uruchamiania zadań statyczny generator witryn zapewnia bezpośredni wgląd zarówno w konfigurację i wykorzystanie tych bibliotek, jak i o znaczniki generowane na potrzeby witryny produkcyjnej. Dzięki temu może w znacznym stopniu automatyzować nasze elastyczne znaczniki obrazów. Na przykład po wywołaniu w ramach skróconego kodu do wyświetlania obrazów ta wtyczka generuje kod HTML zgodnie z opcjami konfiguracji przekazywanymi do Sharp.
const Image = require("@11ty/eleventy-img");
module.exports = function(eleventyConfig) {
async function imageShortcode(src, alt, sizes="100vw") {
let metadata = await Image(src, {
formats: ["avif", "webp", "jpeg"],
widths: [1000, 800, 400],
outputDir: "_dist/img/",
filenameFormat: function( id, src, width, format, options ) {
const ext = path.extname( src ),
name = path.basename( src, ext );
return `${name}-${width}.${format}`
}
});
let imageAttributes = {
alt,
sizes,
loading: "lazy"
};
return Image.generateHTML(metadata, imageAttributes);
}
eleventyConfig.addAsyncShortcode("respimg", imageShortcode);
};
Można go użyć zamiast domyślnej składni obrazu:
{% respimg "img/butterfly.jpg", "Alt attribute.", "(min-width: 30em) 800px, 80vw" %}
Jeśli tak, jak powyżej, wygenerowanym znacznikiem będzie element <picture> zawierający odpowiednie elementy <source>, atrybuty type i atrybuty srcset, które będą już w pełni wypełnione listą wygenerowanych kandydujących rozmiarów.
<picture><source type="image/avif" srcset="/img/butterfly-400.avif 400w, /img/butterfly-800.avif 800w, /img/butterfly-1000.avif 1000w" sizes="(min-width: 30em) 800px, 80vw"><source type="image/webp" srcset="/img/butterfly-400.webp 400w, /img/butterfly-800.webp 800w, /img/butterfly-1000.webp 1000w" sizes="(min-width: 30em) 800px, 80vw"><source type="image/jpeg" srcset="/img/butterfly-400.jpeg 400w, /img/butterfly-800.jpeg 800w, /img/butterfly-1000.jpeg 1000w" sizes="(min-width: 30em) 800px, 80vw"><img alt="Alt attribute." loading="lazy" src="/img/butterfly-400.jpeg" width="1000" height="846"></picture>
Oczywiście ta wtyczka nie będzie w stanie generate realnego atrybutu sizes, ponieważ nie zna ostatecznego rozmiaru i położenia obrazu w renderowanym układzie, ale akceptuje je jako dane wejściowe podczas generowania znaczników. To kolejne zadanie dla RespImageLint.
Platformy
Platformy renderowania po stronie klienta będą wymagać narzędzia do uruchamiania zadań lub tworzenia pakietów (np. Webpack), aby samodzielnie edytować, kodować i kompresować zasoby graficzne. Na przykład moduł ładowania responsywnego ponownie zapisuje komponenty z obrazem za pomocą biblioteki Sharp. Następnie możesz import oznaczyć obrazy jako obiekty:
import imageAVIF from 'img/butterfly.jpg?sizes[]=400,sizes[]=800,sizes[]=1000&format=avif';
import imageWebP from 'img/butterfly.jpg?sizes[]=400,sizes[]=800,sizes[]=1000&format=webp';
import imageDefault from 'img/butterfly.jpg?sizes[]=400,sizes[]=800,sizes[]=1000';
Zaimportowanych obrazów można następnie używać w abstrakcjach, takich jak komponent Obraz w React, lub do bezpośredniego wypełniania elastycznych znaczników obrazów:
<picture>
<source type='image/avif' srcSet={imageAVIF.srcSet} sizes='…' />
<source type='image/webp' srcSet={imageWebp.srcSet} sizes='…' />
<img
src={imageDefault.src}
srcSet={imageDefault.srcSet}
width={imageDefault.width}
height={imageDefault.height}
sizes='…'
loading="lazy"
/>
Platforma, która wykonuje renderowanie po stronie klienta, bardzo dobrze nadaje się do stosowania w przypadku Lazysizes i sizes="auto" – zapewnia prawie w pełni automatyczne elastyczne obrazy.
Systemy zarządzania treścią
WordPress był jednym z pierwszych użytkowników, którzy korzystali z natywnych znaczników obrazów elastycznych. Od wprowadzenia w WordPressie 4.4 interfejsu API stale się rozwijał, zapewniając obsługę WebP i kontrolę nad wyjściowym typem MIME. Rdzeń WordPress został zaprojektowany tak, aby korzystać z rozszerzenia ImageMagick PHP (lub – w przeciwnym razie – z biblioteki GD).
Gdy obraz jest przesyłany przez interfejs administratora WordPress, obraz źródłowy jest używany do generowania na serwerze plików widocznych dla użytkowników, podobnie jak na komputerze lokalnym. Domyślnie każdy obraz wygenerowany przez WordPressa ma wygenerowany atrybut srcset na podstawie rozmiarów obrazów skonfigurowanych w Twoim motywie.
W przypadku generowanych obrazów możesz skonfigurować 2 główne ustawienia: jakość kompresji i wyjściowy typ MIME.
Aby na przykład ustawić domyślną jakość kompresji wszystkich wygenerowanych obrazów na 70, użyj tego kodu:
add_filter( 'wp_editor_set_quality', function() { return 70; } );
Aby uzyskać jeszcze lepszą kompresję, zmień format wyjściowy przesyłanych obrazów JPEG na WebP, wykonując te czynności:
add_filter( 'image_editor_output_format', function( $mappings ) {
$mappings[ 'image/jpeg' ] = 'image/webp';
return $mappings;
} );
Ponieważ WordPress w pełni rozumie wszystkie alternatywne cięcia i kodowanie generowane z przesłanego obrazu, może udostępniać funkcje pomocnicze, takie jak wp_get_attachment_image_srcset(), które pozwalają pobrać pełną, wygenerowaną wartość srcset załącznika graficznego.
Jak się pewnie domyślasz, praca z atrybutem sizes jest trochę trudniejsza. W WordPressie brakuje informacji o sposobie wykorzystywania obrazów w układzie, dlatego WordPress domyślnie ustawia wartość sizes, która w rzeczywistości określa, że „ten obraz powinien zajmować 100% dostępnego widocznego obszaru, aż do nieodłącznego rozmiaru źródła”. Jest to przewidywalne ustawienie domyślne, które jednak nie jest prawidłowym ustawieniem dla żadnej aplikacji w świecie rzeczywistym. Pamiętaj, aby użyć pola wp_calculate_image_sizes(), aby ustawić w szablonach odpowiednie do kontekstu atrybuty sizes.
Istnieje oczywiście niezliczone wtyczki WordPressa przeznaczone do przyspieszenia przepływów pracy związanych z obrazami zarówno dla zespołów programistów, jak i użytkowników.
Co najbardziej ciekawe, wtyczki takie jak Jetpack Site Accelerator (wcześniej „Photon”) mogą obsługiwać po stronie serwera negocjowanie kodowania. Dzięki temu użytkownicy uzyskują najmniejsze i najefektywniejsze kodowanie, które obsługuje ich przeglądarka, bez potrzeby stosowania wzorca znaczników <picture> i type. Dzieje się tak za pomocą sieci dystrybucji treści graficznych – czyli technologii, z której możesz korzystać niezależnie od swojego systemu CMS.
Wszystko to dotyczy również hostowanych rozwiązań CMS, takich jak Shopify, choć same mechanizmy nieco się różnią: oferują podobne punkty zaczepienia do generowania alternatywnych źródeł obrazów i odpowiadających im atrybutów srcset oraz kierunku grafiki za pomocą elementu <picture>.