Optymalizacja frontendu
Obrazki (zwłaszcza LCP) a serwowanie przez CDN
Ostatnio na naszym Discordzie Web Dev Insider zapytano mnie, czy mógłbym rozwinąć / omówić ideę serwowania obrazków w przestrzeni ATF (zakwalifikowanych jako LCP) poprzez CDN, ale proxy'ując połączenie przez serwer.
Temat na tyle mnie zaintrygował, że postanowiłem go szybko przeanalizować i przetestować na kilku przykładach.
Zanim zaczniemy...
Obrazki zakwalifikowane jako LCP idealnie gdyby były ładowane lokalnie. Jeżeli zatem korzystamy z CDNów, które umożliwiają automatyczne serwowanie w odpowiednim formacie (np. WebP / AVIF), w ustalonym rozmiarze, ładowanie ich z zewnętrznej domeny zawsze wydłuży nam czas oczekiwania przez DNS lookup / TCP/TLS handshake podczas pierwszej wizyty do momentu cache'owania. Tego nie unikniemy.
Nie wiem, czy pamiętasz, ale w jednym z ostatnich newsletterów polecałem Twojej uwadze pewien tweet od Harry'ego Robertsa, który traktował na ten sam temat. Harry pokazał, że czasem nawet obrazek niezoptymalizowany, ale ładowany lokalnie może dać lepszy rezultat niż zoptymalizowany, ale serwowany przez CDN. Tak jak mówiłem, uważam, że jest to stwierdzenie prawdziwe do pewnego momentu. Samodzielnie przetestowałem ów przypadek i jeśli obrazek (LCP) będzie naprawdę ogromnych rozmiarów i nieskompresowany, nadal może wygrać serwowanie przez CDN.
W tym samym wątku na Twitterze, jedna osoba zapytała, jak Harry radzi sobie z takimi obrazkami i odpowiedź była następująca:
O ile można zaakceptować taki proces w przypadku niewielkich stron (optymalizujemy obrazek ręcznie i wgrywamy w odpowiednie miejsce), o tyle w przypadku ogromnych witryn, z dużą liczbą produktów, artykułów i czegokolwiek, dodatkowo jeszcze zarządzanych przez CMS, takie rozwiązanie może być bardzo kłopotliwe i czasochłonne.
Taki przypadek mamy w większości stron, jakie tworzymy dla klientów naszej agencji (BTW zerknij na naszą nową stronę :-)). Wszystkie obrazki serwujemy przez IMGIX, który odpowiada za nowoczesny format (WebP i AVIF) oraz adaptacyjne rozmiary dla odpowiednich ekranów.
Postanowiłem, że przetestuję ideę serwowania obrazków przez IMGIX, ale proxy'ując połączenie "na backendzie".
Aby to lepiej zobrazować, poniżej krótki opis "co i jak":
- oto obrazek oryginalny: https://www.webdevinsider.pl/images/512x512px.png
- oto obrazek serwowany przez IMGIX (który cache'uje oryginalny obrazek): https://webdevinsider.imgix.net/images/512x512px.png?auto=format
Aby uniknąć łączenia do zewnętrznej domeny na frontendzie, w konfiguracji serwera Nginx'a dodałem taki blok:
Dzięki temu, ten sam obrazek, może być wciąż serwowany przez Imgix, ale z poziomu lokalnej domeny:
https://www.webdevinsider.pl/imgix/images/512x512px.png?auto=format
Ot, cała filozofia! :) Przyznasz, że proste i genialne?
Podany przykład można dowolnie zmodyfikować i "podpiąć" np. pod Cloudinary, ImageKit lub jakikolwiek inny CDN o podobnym działaniu.
Zaimplementowałem to rozwiązanie na kilku stronach i efekty są następujące:
Ten sam obrazek. Ten sam format i rozmiar. Na pierwszym waterfallu ładowany standardowo, po zewnętrznej domenie Imgix, a na drugim ładowany również przez Imgix, ale "pod spodem", z lokalnej domeny.
50% szybciej. Myślę, że warto rozważyć ładowanie obrazków przez CDN nie tylko w kontekście LCP, ale także pozostałych, below the fold.
To samo rozwiązanie można zastosować do jakichkolwiek innych CDNów, np. Cloudinary, ImageKit i tym podobnych. Warto nadmienić, iż połączenie między naszym serwerem, a usługą CDN odbywać się musi przez protokół http://, ale dopóki mówimy o zasobach statycznych (jak np. obrazki czy video), nie widzę z tym żadnego problemu. Cały czas natomiast połączenie do naszej lokacji /imgix/ odbywać się będzie w sposób zabezpieczony przez https://. Tu się nic nie zmienia.
Zapytałem support Imgix'a, czy mają jakikolwiek problem z takim podejściem i odpowiedź była jednoznaczna: nie :-) Stwierdzili, iż kilku klientów korzysta już z takiego rozwiązania.
W międzyczasie, jak piszę ten newsletter, natrafiłem na chyba jedyny artykuł, który przedstawia ten sam pomysł. Pokazano w nim przykład z Cloudinary - https://timkadlec.com/remembers/2020-11-17-netlify-proxy-requests/
Daj znać, co o tym sądzisz :-)
PS ostatnia szansa dołączenia do kursu Zoptymalizowany Frontend tylko 21-25. listopada 2022 w cenie 1549 PLN brutto (jeśli kurs wróci to na pewno w wyższej cenie). Tutaj możesz się zapisać. Jeżeli dysponujesz jeszcze niewykorzystanym budżetem na 2022 - rekomenduję zainwestować go w to szkolenie. Inwestycja zwróci się wielokrotnie i bardzo szybko - obiecuję.