\n By\u0142 czas, kiedy mo\u017cna by\u0142o \u015bmia\u0142o odr\u00f3\u017cni\u0107 stron\u0119 internetow\u0105 na komputery i stron\u0119 mobiln\u0105. Tak bardzo, \u017ce ca\u0142a bran\u017ca wyros\u0142a wok\u00f3\u0142 zmiany przeznaczenia witryn stacjonarnych na urz\u0105dzenia mobilne.\n<\/p>\n
\n Przez jaki\u015b czas by\u0142e\u015b nikim, je\u015bli nie mia\u0142e\u015b osobnej witryny mobilnej w osobnej domenie. Potem wszystko zacz\u0119\u0142o si\u0119 zmienia\u0107.\n<\/p>\n
\n Wy\u015bwietlacze mobilne poprawi\u0142y si\u0119 nie do poznania. Podobnie sta\u0142o si\u0119 z przegl\u0105darkami mobilnymi. Tablety wrzuci\u0142y kolejny element do r\u00f3wnania. Pojawi\u0142o si\u0119 4G. Wy\u015bwietlacze Retina oferowa\u0142y u\u017cytkownikom ko\u0144cowym nowy poziom przejrzysto\u015bci.\n<\/p>\n
\n Nagle granica mi\u0119dzy komputerem stacjonarnym a telefonem kom\u00f3rkowym zacz\u0119\u0142a si\u0119 zaciera\u0107.\n<\/p>\n
\n Jednocze\u015bnie ros\u0142a r\u00f3\u017cnorodno\u015b\u0107 rozmiar\u00f3w i rozdzielczo\u015bci wy\u015bwietlaczy komputer\u00f3w stacjonarnych.\n<\/p>\n
\n I rosn\u0105cy b\u00f3l g\u0142owy dla projektant\u00f3w stron internetowych.\n<\/p>\n
\n Dawno min\u0119\u0142y czasy, kiedy trzeba by\u0142o obs\u0142u\u017cy\u0107 tylko kilka rozmiar\u00f3w widocznego obszaru. Sprawy si\u0119 komplikowa\u0142y.\n<\/p>\n
\n Na szcz\u0119\u015bcie pomoc by\u0142a pod r\u0119k\u0105 w postaci zapyta\u0144 o media i koncepcji responsywnego projektowania.\n<\/p>\n
\n Dzi\u0119ki zapytaniom o media mo\u017cliwe sta\u0142o si\u0119 r\u00f3\u017cnicowanie styl\u00f3w i uk\u0142adu \u2013 a nawet tre\u015bci \u2013 w zale\u017cno\u015bci od szeroko\u015bci widocznego obszaru i rozdzielczo\u015bci ekranu u\u017cytkownika. Oczywi\u015bcie zapytania o media nie s\u0105 bynajmniej jedynym narz\u0119dziem w torbie sztuczek responsywnego projektanta, ale mo\u017cna \u015bmia\u0142o powiedzie\u0107, \u017ce stanowi\u0105 podstaw\u0119 tej techniki.\n<\/p>\n
\n To by\u0142a \u015bwietna wiadomo\u015b\u0107 dla urz\u0105dze\u0144 mobilnych. Responsywny projekt oznacza\u0142, \u017ce mo\u017cesz skutecznie dostarcza\u0107 r\u00f3\u017cne wersje tej samej witryny na r\u00f3\u017cne urz\u0105dzenia. Wszystko bez tworzenia osobnej witryny mobilnej w innej domenie.\n<\/p>\n
\n W\u0142a\u015bciciele witryn zaczynaj\u0105 zdawa\u0107 sobie spraw\u0119, \u017ce u\u017cytkownikom ko\u0144cowym zale\u017cy na wydajno\u015bci. Zw\u0142aszcza sprzedawcy detaliczni zaczynaj\u0105 docenia\u0107 fakt, \u017ce skr\u00f3cenie czasu \u0142adowania o milisekundy mo\u017ce prze\u0142o\u017cy\u0107 si\u0119 na miliony w bilansie.\n<\/p>\n
\n Na szcz\u0119\u015bcie responsywne witryny oferuj\u0105 jedn\u0105 wyra\u017an\u0105 przewag\u0119 wydajno\u015bci w por\u00f3wnaniu z ich dedykowanymi kuzynami mobilnymi: wyeliminowane jest przekierowanie do domeny mobilnej.\n<\/p>\n
\n Jednak pomimo tego responsywny projekt zyska\u0142 reputacj\u0119 s\u0142abej wydajno\u015bci.\n<\/p>\n
\n W pewnym sensie jest to raczej niesprawiedliwe, ale warto przyjrze\u0107 si\u0119 dodatkowym wyzwaniom zwi\u0105zanym z wydajno\u015bci\u0105, jakie responsywny projekt stawia nieostro\u017cnym\u2026\n<\/p>\n
\n Pliki obraz\u00f3w s\u0105 du\u017ce. A poniewa\u017c s\u0105 du\u017ce, cz\u0119sto s\u0105 winne powolnego \u0142adowania. S\u0105 zatem dobrym miejscem do rozpocz\u0119cia dla ka\u017cdego, kto pr\u00f3buje zoptymalizowa\u0107 wydajno\u015b\u0107 witryny.\n<\/p>\n
\n Niestety, jedno z pierwszych rozwi\u0105za\u0144 responsywnego dostarczania obraz\u00f3w nie by\u0142o zbyt dobre pod wzgl\u0119dem wydajno\u015bci.\n<\/p>\n
\n Technika jest pi\u0119knie prosta. Po prostu u\u017cyj max-width: 100%, aby upewni\u0107 si\u0119, \u017ce obrazy s\u0105 skalowane do szeroko\u015bci elementu zawieraj\u0105cego:\n<\/p>\n
img\n{\nmax-width: 100%;\n}<\/code><\/pre>\n\n Poniewa\u017c kontener kurczy si\u0119, aby dopasowa\u0107 go do mniejszych rzutni, wszystkie znajduj\u0105ce si\u0119 w nim obrazy b\u0119d\u0105 si\u0119 kurczy\u0107. \u0141atwy!\n<\/p>\n
\n Ale jest problem. Rozmiar obrazu mo\u017ce si\u0119 zmniejszy\u0107 na ekranie, ale rozmiar pliku pozostaje taki sam. Jest to dalekie od idea\u0142u z punktu widzenia wydajno\u015bci. Mo\u017cesz przesy\u0142a\u0107 obraz o wymiarach 800 x 800 pikseli, tylko po to, aby by\u0142 wy\u015bwietlany w rozmiarze 80 x 80 pikseli: innymi s\u0142owy, mo\u017cesz przesy\u0142a\u0107 setki (lub tysi\u0105ce) niepotrzebnych bajt\u00f3w. Nie tylko \u0142adowanie obrazu zajmie du\u017co czasu, ale wszystkie te nadmiarowe bajty mog\u0105 wyczerpa\u0107 cenny limit danych u\u017cytkownika ko\u0144cowego.\n<\/p>\n
\n Jednak nie jest to jedyny \u2013 ani nawet najlepszy \u2013 spos\u00f3b dostarczania responsywnych obraz\u00f3w. Po pierwsze, obraz, kt\u00f3ry dzia\u0142a przy szeroko\u015bci 800 pikseli, niekoniecznie b\u0119dzie dzia\u0142a\u0142 tak dobrze w r\u00f3\u017cnych u\u0142amkach tego rozmiaru.\n<\/p>\n
\n Aby sobie z tym poradzi\u0107, mo\u017cesz u\u017cy\u0107 zapytania o media, aby wy\u015bwietli\u0107 r\u00f3\u017cne wersje obrazu w zale\u017cno\u015bci od rozmiaru rzutni, u\u017cywaj\u0105c zapytania o media i wy\u015bwietlenia: brak.\n<\/p>\n
\n CSS:<\/strong>\n<\/p>\n@media (min-width: 601px) {\n#croppedImage\n{\ndisplay:none;\n}\n}\n@media (max-width: 600px) {\n#largeImage\n{\ndisplay:none;\n}\n}<\/code><\/pre>\n\n HTML:<\/strong>\n<\/p>\n<img id=\"largeImage\" width=\"400\" height=\"400\" alt=\"\" src=\"images\/largeImage.webp\" \/>\n<img id=\"croppedImage\" width=\"200\" height=\"200\" alt=\"\" src=\"images\/croppedImage.webp\" \/><\/code><\/pre>\n\n Umo\u017cliwia to wy\u015bwietlanie r\u00f3\u017cnych wersji obrazu, a nie tylko tego samego obrazu w r\u00f3\u017cnych rozmiarach. Nie zmniejsza to jednak liczby bajt\u00f3w. W rzeczywisto\u015bci ca\u0142kowity rozmiar strony b\u0119dzie wi\u0119kszy, poniewa\u017c wszystkie obrazy zostan\u0105 za\u0142adowane, niezale\u017cnie od tego, czy s\u0105 wy\u015bwietlane, czy nie.\n<\/p>\n
\n Lepsz\u0105 alternatyw\u0105 \u2013 je\u015bli jest to praktyczne \u2013 jest u\u017cycie obraz\u00f3w t\u0142a zamiast <img src=\"https:\/\/inform.click\/wp-content\/uploads\/2024\/11\/inform.click\" \/><\/code>element\u00f3w. Jest to preferowane, poniewa\u017c obrazy, do kt\u00f3rych odwo\u0142uje si\u0119 CSS, s\u0105 \u0142adowane tylko wtedy, gdy s\u0105 u\u017cywane (o ile nie s\u0105 identyfikatorami URI danych):\n<\/p>\n@media (min-width: 601px) {\n#largeImage\n{\nwidth:400px;\nheight:400px;\nbackground-image:url(\/images\/largeImage.webp);\n}\n#croppedImage\n{\ndisplay:none;\n}\n}\n \n@media (max-width: 600px) {\n#croppedImage\n{\nwidth:200px;\nheight:200px;\nbackground-image:url(\/images\/croppedImage.webp);\n}\n#largeImage\n{\ndisplay:none;\n}\n}<\/code><\/pre>\n\n Dzia\u0142a to dobrze: odwiedzaj\u0105cy pobieraj\u0105 tylko te obrazy, kt\u00f3rych potrzebuj\u0105, kiedy i kiedy ich potrzebuj\u0105. Problem polega na tym, \u017ce jest nieporz\u0105dny, skutecznie traktuj\u0105c tre\u015b\u0107 jako styl. W zwi\u0105zku z tym potencjalnie stwarza problem z utrzymaniem, a tak\u017ce mo\u017ce powodowa\u0107 ignorowanie wa\u017cnych obraz\u00f3w przez wyszukiwarki.\n<\/p>\n
\n Zamiast tego, dlaczego nie u\u017cy\u0107 SVG (skalowalnej grafiki wektorowej): formatu obrazu, kt\u00f3ry skaluje si\u0119 z natury? Obrazy SVG maj\u0105 r\u00f3wnie\u017c t\u0119 zalet\u0119, \u017ce mo\u017cna je \u0142atwo stylizowa\u0107 za pomoc\u0105 CSS (zobacz ten \u015bwietny samouczek<\/a> na temat tworzenia responsywnych plik\u00f3w SVG za pomoc\u0105 CSS). Jest to idealne rozwi\u0105zanie dla ikon i logo, ale niestety nie b\u0119dziesz m\u00f3g\u0142 u\u017cywa\u0107 plik\u00f3w SVG do zdj\u0119\u0107 \u2013 w tym przypadku b\u0119dziesz musia\u0142 skorzysta\u0107 z format\u00f3w rastrowych, takich jak JPEG.\n<\/p>\n\n Inn\u0105 opcj\u0105 jest u\u017cycie jednego z wielu rozwi\u0105za\u0144 JavaScript w celu dostarczenia responsywnych obraz\u00f3w. Jest to popularny spos\u00f3b na zrobienie tego, ale dodaje kolejn\u0105 warstw\u0119 z\u0142o\u017cono\u015bci. Co wi\u0119cej, poniewa\u017c JavaScript blokuje konstrukcj\u0119 DOM, ka\u017cde rozwi\u0105zanie wykorzystuj\u0105ce JavaScript mo\u017ce potencjalnie wstrzyma\u0107 renderowanie. Tak wi\u0119c, chocia\u017c istnieje kilka bardzo sprytnych wtyczek, po prostu wprowadzaj\u0105c JavaScript do r\u00f3wnania, do pewnego stopnia godzisz si\u0119 na mniejsze z\u0142o.\n<\/p>\n
\n Do niedawna by\u0142y to jedyne opcje.\n<\/p>\n
\n Teraz jednak elementy i <source \/><\/code>oraz atrybuty srcset i size wreszcie wprowadzaj\u0105 do sieci naprawd\u0119 responsywne obrazy. Nowa specyfikacja zaczyna r\u00f3wnie\u017c zyskiwa\u0107 wsparcie w przegl\u0105darkach, z pe\u0142nym wsparciem w Chrome i Operze oraz obs\u0142ug\u0105 prze\u0142\u0105czania rozdzielczo\u015bci w Safari. Dop\u00f3ki inne przegl\u0105darki nie nadrobi\u0105 zaleg\u0142o\u015bci, istnieje doskona\u0142y kod JavaScript polyfill<\/a>.\n<\/p>\n\n W tym wspania\u0142ym nowym \u015bwiecie mo\u017cesz u\u017cy\u0107 srcset, aby ustawi\u0107 list\u0119 obraz\u00f3w kandyduj\u0105cych do wybrania przez przegl\u0105dark\u0119. Nast\u0119pnie mo\u017cesz u\u017cy\u0107 zapytania o media w atrybucie rozmiary, aby okre\u015bli\u0107 rozmiar, w jakim obraz b\u0119dzie wy\u015bwietlany. U\u017cywaj\u0105c elementu wraz z zapytaniami o media wewn\u0105trz jednego lub wi\u0119cej element\u00f3w, mo\u017cesz okre\u015bli\u0107r\u00f3\u017cny zakres obraz\u00f3w dla r\u00f3\u017cnych warunk\u00f3w (np. dla rzutni o okre\u015blonej szeroko\u015bci u\u017cyj obrazka a, b lub c, a dla wi\u0119kszych rzutni u\u017cyj obrazka x, y lub z). Jest to przydatne, je\u015bli chcesz dostarczy\u0107 przyci\u0119t\u0105 wersj\u0119 obrazu dla u\u017cytkownik\u00f3w z ma\u0142ymi ekranami.\n<\/p>\n