Niezależnie od tego, na ile jesteś na etapie projektowania i tworzenia stron internetowych, element <img> wymaga krótkiego wprowadzenia.
Wydany w Netscape (w tamtym czasie Mosaic) w 1993 i dodany do specyfikacji HTML w 1995 r. <img> od dawna odgrywa ważną rolę na platformie internetowej. Deweloper dodaje plik obrazu „źródłowy” z atrybutem src i udostępnia tekstową wersję alternatywną z atrybutem alt na wypadek, gdyby nie można było wyrenderować obrazu lub gdy technologie wspomagające prosiły o jego użycie. Przeglądarka ma wtedy tylko jedno zadanie: pobrać dane obrazu, a potem jak najszybciej je wyrenderować.
Przez większość historii tworzenia stron internetowych praca z obrazami nie była bardziej skomplikowana. I pomimo złożoności nowoczesnej sieci, podstawy pracy z obrazami nie uległy zmianie. Należy korzystać z formatu przyjaznego dla sieci, aby uzyskać zgodność, rozsądnej kompresji, aby oszczędzać przepustowość, oraz wymiarów odpowiednich do miejsca, w jakim obraz będzie zajmować układ strony.
Zastosowanie układów o stałej szerokości, tak jak kiedyś, Szczególnie łatwo było ustawić rozmiar źródła obrazu. W przypadku obrazu, który zajmuje przestrzeń o szerokości 500 pikseli i 300 pikseli wysokości, konieczne było wskazanie obrazu źródłowego w tym samym rozmiarze.
Obrazy w układzie elastycznym
Poza elastycznym układem i zapytaniami o media CSS „elastyczne obrazy i multimedia” to jeden z 3 najważniejszych aspektów elastycznego projektowania witryn. Aby obraz był elastyczny, programiści zaczęli używać CSS do umieszczania na obrazie (lub wszystkich obrazach w całej witrynie) atrybutu max-width: 100%. W ten sposób informuje mechanizm renderujący przeglądarki, aby obraz nie przekroczył danych kontenera nadrzędnego przez skalowanie go w dół. Pod względem wizualnym to rozwiązanie działa idealnie – skalowanie obrazu rastrowego w dół jest płynne wizualnie. W połączeniu z wierszami lub dwoma wierszami kodu CSS pomniejszony obraz będzie zawsze wyglądać tak, jakby został przez nas określony źródło obrazu, które miało być wyświetlane w tym rozmiarze.
Gdy mechanizmy renderujące otrzymują więcej danych obrazu niż jest to konieczne dla przestrzeni zajmowanej w układzie, mogą podejmować przemyślane decyzje dotyczące renderowania zmniejszonego obrazu bez konieczności wprowadzania jakichkolwiek artefaktów wizualnych czy rozmycia.
Zwykle nie zalecamy przeskalowania obrazu, czyli renderowania <img> do rozmiaru większego niż wewnętrzny rozmiar obrazu źródłowego.
Wyświetlany obraz będzie rozmyty i ziarnisty.
Używanie funkcji img { max-width: 100% } oznacza, że gdy użytkownik elastycznie zmienia rozmiar kontenera, obrazy zostaną odpowiednio przeskalowane w dół.
W przeciwieństwie do ustawienia bardziej sztywnego elementu width: 100% zapewnia to również, że obraz nie zostanie powiększony poza swój podstawowy rozmiar.
Przez długi czas to było związane z zasadami pracy z obrazami: używaj formatu zrozumiałego dla przeglądarek, stosuj rozsądny poziom kompresji i nigdy nie skaluj obrazów w górę.
Tak proste i efektywne rozwiązanie wizualne wiązało się z ogromnym kosztem wydajności. Usługa <img> obsługiwała tylko 1 źródło danych o obrazie, dlatego to podejście wymagało przesłania komponentu z obrazem o własnym rozmiarze odpowiadającym największym rozmiarom, w jakim można go wyświetlić. Obraz, który zajmuje przestrzeń w układzie o szerokości od 300px do 2000px w zależności od rozmiaru widocznego obszaru przez użytkownika, wymagał źródła obrazu o wewnętrznej szerokości co najmniej 2000px. Jeśli użytkownik przegląda stronę tylko w niewielkim widocznym obszarze, wszystko będzie wyglądać zgodnie z oczekiwaniami, a obraz będzie się skalować prawidłowo. Na wyrenderowanej stronie duży, zmniejszony obraz źródłowy wygląda tak samo jak odpowiedni rozmiar obrazu. Nadal będą jednak przesyłać i renderować obraz o szerokości 2000px, co zużywa ogromną przepustowość i moc obliczeniową bez żadnych wymiernych korzyści.
Sytuacja znacznie się pogorszyła wraz z pojawieniem się pierwszych urządzeń typu „Retina”, ponieważ gęstość wyświetlania stała się problemem związanym z rozmiarem widocznego obszaru. Aby można było dostosować go do wyświetlacza o dużej gęstości, źródło obrazu musi mieć znacznie większą wewnętrzną szerokość. Mówiąc prościej, użycie 2 razy większej gęstości obrazu wymaga dwukrotnego wyrenderowania obrazu.
Tutaj ponownie deweloperzy mogli polegać na możliwości silników renderowania przeskalowania obrazów w dół. Jeśli udostępnisz przeglądarce obraz źródłowy o szerokości 800px w interfejsie src i określisz, że powinien on być wyświetlany na poziomie 400px z użyciem CSS, w efekcie otrzymujemy obraz renderowany z 2 razy większą gęstością pikseli:
Jeden obraz źródłowy, przycięty tak, aby zajął największą możliwą przestrzeń w układzie i wyświetlacz o wysokiej rozdzielczości, jest oczywiście wizualny dla wszystkich użytkowników. Ogromne źródło obrazów o wysokiej rozdzielczości wyrenderowane na małym wyświetlaczu o małej gęstości wygląda jak wszystkie inne małe obrazy o niskiej gęstości, ale wygląda znacznie wolniej. Użytkownik nie będzie mógł nic zyskać na kosztach związanych z wydajnością takiego źródła obrazów o szerokości 4000 pikseli.
Przez długi czas <img> zajmowała się głównie jedną sprawą – „pozyskała dane obrazu i umieściła je na ekranie”. Zrobiło to dość dobrze, z pewnością, ale <img> nie była w stanie poradzić sobie z radykalnymi zmianami w kontekście przeglądania, które zaobserwowaliśmy. Chociaż projektowanie responsywne zostało powszechnie stosowane, przez prawie 20 lat przeglądarki optymalizowały wydajność strony img. Jednak w przypadku wszystkich użytkowników (oprócz najbardziej uprzywilejowanych) od samego początku stosowanie zawartości obrazów na stronach było mało wydajne. Bez względu na to, jak szybko przeglądarka zdołała pobrać, przeanalizować i wyrenderować źródło obrazu, zasób ten z dużym prawdopodobieństwem byłby znacznie większy, niż potrzebował użytkownik.