Digital media – definicja w 100 słowach i 6 typów, które realnie spotkasz

Digital media to treści tworzone, przechowywane i dystrybuowane w formie cyfrowej: obraz, dźwięk, wideo, tekst, animacja i forma interaktywna. Tyle definicja. Reszta to praktyka sklepu.

Gdzie przebiega granica? Media tradycyjne — druk, radio analogowe, billboard — powstają i są przekazywane w świecie fizycznym. Jeden egzemplarz, jedna emisja, brak interakcji. Media cyfrowe to pliki, strumienie i kod: JPEG na serwerze, strumień HLS, komponent AR w przeglądarce. Kopiujesz je bez utraty jakości, wersjonujesz, kompresujesz i mierzysz co do kilobajta. To różnica techniczna, ale ma konsekwencje: plik można zoptymalizować albo zostawić i płacić czasem ładowania.

W e-commerce realnie spotkasz sześć typów:

Dlaczego digital media to infrastruktura sklepu, a nie dodatek do marketingu

Otwórz DevTools → zakładka Network na dowolnej karcie produktu i zobacz, jak rozkłada się waga. HTML, CSS i JavaScript to razem 20–40% transferu. Reszta — 60–80% — to digital media: zdjęcia, wideo, ikony, czasem czcionki. To nie ciekawostka, bo największy element graficzny widoczny przy pierwszym renderze jest zwykle też elementem LCP (Largest Contentful Paint). W sklepie to niemal zawsze główne zdjęcie produktu albo obraz hero na stronie głównej. Google uwzględnia LCP w Core Web Vitals — szczegóły opisuje dokumentacja web.dev — więc każdy kilobajt tego pliku pracuje albo przeciw Tobie, albo dla Ciebie.

Skala rośnie szybciej, niż się wydaje. Policz to dla własnego katalogu:

Formaty plików 2025: co wybrać do zdjęć, wideo i audio

Rekomendacja jest jednoznaczna i nie zmieniła się istotnie w 2025 roku.

Zdjęcia. Kolejność: AVIF → WebP → JPEG/PNG. AVIF daje najmniejszy plik przy tej samej jakości (często 40–50% mniej niż JPEG), ale wspiera go tylko część przeglądarek, więc zawsze zostawiasz fallback. WebP obsługują praktycznie wszystkie nowoczesne przeglądarki. JPEG zostaje jako bezpieczne dno dla starych klientów i części mailowych podglądów.

Wideo. MP4/H.264 dla maksymalnej zgodności — odtworzy go wszystko. WebM/VP9 i AV1 dają mniejszy transfer, ale kosztują czas kodowania i wsparcie serwera. Przy materiałach dłuższych niż minuta stosuj HLS (strumień podzielony na krótkie fragmenty), żeby klient nie czekał na cały plik.

Audio. AAC/MP3 dla uniwersalności, Opus gdy zależy na rozmiarze i jakości mowy — np. w lektorskim omówieniu produktu.

Progi wagowe, których warto się trzymać:

Digital media a SEO i Core Web Vitals – co faktycznie sprawdza Google

Core Web Vitals Google liczy z realnych sesji użytkowników, a nie z testu na Twoim laptopie. Ocena zapada na 75. percentylu wejść — jeśli choć jedna czwarta użytkowników wypada gorzej niż próg, strona nie przechodzi, nawet gdy w Lighthouse widzisz 95.

Z tych trzech metryk media psują dwie. LCP to zwykle zdjęcie hero albo główne zdjęcie produktu. CLS to obrazy bez zarezerwowanego miejsca. INP częściej obciążają skrypty zewnętrzne, ale ciężki slider wideo potrafi dołożyć swoje.

Podstawowa ochrona przed CLS: width i height na każdym <img> albo aspect-ratio w CSS. Przeglądarka rezerwuje miejsce, zanim pobierze plik. To jedna zmiana w szablonie karty produktu i większość problemów z CLS znika.

Obraz LCP traktuj osobno: fetchpriority="high", bez loading="lazy". Lazy na obrazie pierwszego ekranu to klasyczna pułapka — przeglądarka celowo opóźnia pobranie, a Google mierzy to jako wolne LCP. Zasada: pierwszy ekran ładuje się normalnie, wszystko poniżej — loading="lazy". Warto dołożyć <link rel="preload"> dla samego obrazu LCP.

Tekst alternatywny opisuje treść, nie frazę. Obraz informacyjny: co widać. Ikona, separator, tło dekoracyjne: alt="" — pusty, nie brakujący. Upychanie fraz w alt to nie SEO, a sygnał spamu. Aktualne progi sprawdzisz w dokumentacji Google Search Central o Core Web Vitals.

Nazwa pliku działa jak etykieta: buty-biegowe-damskie-rozmiar-38.webp mówi więcej niż IMG_4521.jpg, a kosztuje tyle samo pracy. Dla wideo dochodzi kontekst: dane strukturalne VideoObject, sitemap wideo, dostępny thumbnail i publikacja na stronie docelowej. Sam embed z zewnętrznego serwisu, bez treści wokół, nie wystarczy.

Gdzie trzymać media: hosting, CDN i object storage

Decyzję o infrastrukturze podejmuj na podstawie liczby plików i miesięcznego transferu, nie „na wyczucie”.

Osobny serwer plików statycznych albo object storage zgodny z S3 ma sens, gdy media zaczynają zjadać pasmo i CPU aplikacji. Ale offload to projekt, nie wtyczka „włącz i zapomnij”: trzeba przepisać URL-e, sprawdzić podgląd w bibliotece mediów i policzyć koszt wyjścia ruchu (egress), który przy rosnącym ruchu potrafi przebić koszt samego storage'u.

Konwersja formatów przy uploadzie (WebP/AVIF obok JPG) kosztuje CPU raz i jest prosta we wdrożeniu. Konwersja on-the-fly przenosi koszt na każdą odsłonę — opłaca się tylko z agresywnym cache i CDN przed serwerem.

PrestaShop: miniatury definiujesz w panelu (Projektowanie → Ustawienia obrazów), typy home_default, large_default, cart_default mają własne wymiary. Po zmianie ustawień uruchom regenerację miniatur — stare pliki nie znikają z /img/p/, a ten katalog potrafi urosnąć do kilkudziesięciu GB i zjada limity inode. WooCommerce: rozmiary ustawiasz w Ustawienia → Media plus własne rozmiary sklepu; sama zmiana suwaków nie przelicza istniejących plików, potrzebna regeneracja miniatur.

Nagłówki cache: dla plików z hashem w nazwie Cache-Control: public, max-age=31536000, immutable. Jeśli podmieniasz zdjęcie pod tą samą nazwą — a tak robi PrestaShop — klient i CDN nadal zobaczą starą wersję. Dodaj parametr wersji albo czyść cache; ETag pomaga tylko przy zapytaniach warunkowych.

Backup: /img/p/ i wp-content/uploads rosną szybciej niż baza danych. Kopia samej bazy po awarii odtworzy sklep bez zdjęć. Sprawdź, czy media są w harmonogramie i przetestuj odtworzenie na kopii. Szczegóły techniczne opisuje dokumentacja dla deweloperów PrestaShop.

Prawa, licencje, RODO i dostępność – czego nie wolno pominąć

Trzy obszary, w których oszczędność kilkuset złotych na licencji kończy się roszczeniem: prawa do mediów, dane osobowe w plikach i dostępność.

Licencja stockowa ma zakres: nośnik (online, druk, outdoor), terytorium, czas i typ użycia. „Editorial use only” nie nadaje się na kartę produktu. Zdjęcie od fotografa wymaga umowy przenoszącej majątkowe prawa autorskie na wszystkich polach eksploatacji — plus osobnych zgód na wizerunek, jeśli osoby są rozpoznawalne.

Wizerunek: polskie prawo autorskie (art. 81 ustawy o prawie autorskim i prawach pokrewnych) wymaga zgody na rozpowszechnianie wizerunku. Dotyczy to pracowników, modelek i klientów — także zdjęć z eventu firmowego, jeśli ktoś jest rozpoznawalny i stanowi główny motyw kadru. UGC, czyli zdjęcia przysyłane przez klientów: samo wysłanie pracy na konkurs nie jest zgodą na publikację w sklepie. Potrzebny regulamin z klauzulą licencyjną albo wyraźna zgoda z datą i zakresem.

Media z AI: obraz w pełni wygenerowany, bez twórczego wkładu człowieka, może nie być w ogóle chroniony prawem autorskim — nie masz do niego wyłączności. Rozporządzenie o AI (2024/1689) wprowadza obowiązki przejrzystości, m.in. oznaczanie treści syntetycznych i deepfake'ów. Praktycznie: nie publikuj wygenerowanego zdjęcia jako zdjęcia realnego produktu i oznaczaj takie grafiki. Wątpliwości prawne konsultuj z prawnikiem, bo stanowiska bywają różne.

RODO: pliki zdjęciowe noszą metadane EXIF z geolokalizacją. Usuń je przed publikacją (exiftool, ImageOptim). Zdjęcia dokumentów i nagrania z klientami trzymaj poza katalogiem publicznym, z ograniczonym dostępem i terminem usunięcia.

Dostępność (WCAG 2.2): alt dla obrazów niosących treść, napisy i transkrypcje dla wideo, kontrast tekstu na grafikach promocyjnych minimum 4,5:1. Tekst wtopiony w obrazek to zły pomysł — czytnik ekranu go nie odczyta.

Ile to kosztuje i ile zajmuje – widełki w godzinach, nie z sufitu

Wycena wdrożenia mediów nie wymaga czekania na ofertę. Wystarczy zakres prac w godzinach pomnożony przez stawkę. Poniższe widełki dotyczą sklepu do 500 SKU, w którym pliki już istnieją na serwerze – nie trzeba ich odzyskiwać z archiwum ani odtwarzać z backupu.

• Audyt i inwentaryzacja mediów – 6–12 h. Liczysz pliki, formaty, wymiary i wagę karty produktu. Na serwerze wystarczy find ./img -type f | wc -l plus sortowanie po rozmiarze. Przy 300 SKU po 4 zdjęcia to ok. 1200 plików, więc robi to skrypt, nie człowiek klikający w FTP.
• Serwowanie AVIF/WebP z fallbackiem i srcset – 8–20 h. Rozrzut wynika z platformy. Część systemów ma to natywnie, w innych trzeba dopisać generowanie wariantów i podmianę w szablonie karty produktu. Jeśli pracujesz na PrestaShop, punktem wyjścia jest oficjalna dokumentacja dla deweloperów: PrestaShop Developer Documentation – sprawdź najpierw, co robi rdzeń, zanim dokupisz moduł.
• CDN i object storage wraz z migracją plików – 6–16 h. Przepięcie adresów, przekierowania, cache, weryfikacja, czy stare linki do zdjęć nie zwracają 404.
• Wideo na kartach produktu – 10–25 h. Szablon odtwarzacza, hosting, miniatura, lazy loading poza obszarem widoku, testy na 4G.
• Procedura licencyjna i zgody na wizerunek – 4–8 h. Wzory zgód, rejestr (kto, kiedy, na co), zasady dla materiałów od dostawców.

Zasada wyceny jest jedna: stawka godzinowa × liczba godzin. Nie „pakiet od sklepu”, bo przy 60 SKU i przy 480 SKU robota jest inna. Każde przewidywane przekroczenie zakresu zgłaszamy przed wykonaniem, nie po fakturze. Pułapka w tanich ofertach: brakuje pozycji „migracja i przekierowania” oraz „fallback dla starszych przeglądarek” – a właśnie tam wracają koszty.

7 błędów, które kosztują najwięcej – i jak wykryć je w 15 minut

Siedem błędów poniżej odpowiada za większość problemów z wydajnością i prawami do mediów w sklepach. Każdy da się wykryć podczas jednego przeglądu: telefon z kartą produktu, DevTools, PageSpeed Insights i kwadrans czasu.

• Obraz LCP z atrybutem loading="lazy". Największy element widoku – zwykle zdjęcie główne produktu – nie może być leniwie ładowany. Sprawdzisz w PageSpeed Insights (sekcja „Largest Contentful Paint element”) i w zakładce Elements. Wystarczy zdjąć atrybut z jednego obrazu, a LCP potrafi spaść o kilkaset milisekund.
• Brak width/height. Powoduje skaczący layout i wysoki CLS. Widać to w raporcie Lighthouse. Jeśli wymiary zmieniają się w zależności od viewportu, użyj responsywnego srcset albo proporcji kontenera.
• Zdjęcia 4000 px prosto z aparatu. DevTools → Network → sortowanie po kolumnie Size. Plik 6 MB na karcie mobilnej to nie „ładna fotka”, a kilka sekund pustego ekranu.
• Podwójne serwowanie formatów. Przeglądarka pobiera i JPEG, i WebP – w Network zobaczysz dwa żądania tej samej grafiki. To znak, że fallback działa źle albo element ma dwa źródła.
• Braki w tekstach alternatywnych. Audyt masowy w Screaming Frog; Search Console tego nie pokaże, bo nie ma takiego raportu. Alt opisuje produkt, nie plik: nie „IMG_2841”, tylko „but trekkingowy męski, podeszwa Vibram, widok z boku”.
• Miniatury generowane przy każdym żądaniu. Rośnie zużycie CPU, a karta produktu zwalnia pod obciążeniem. Sprawdzisz w logach serwera i monitoringu – powtarzalne zapytania do jednego pliku z rosnącym czasem odpowiedzi.
• Brak testu odtworzenia backupu. Kopia, której nigdy nie odtworzyłeś, nie jest kopią. Raz na kwartał odtwórz wybrane medium na środowisku testowym.

Kolejność diagnostyki jest ważna – najpierw LCP i CLS, potem waga, na końcu podwójne serwowanie. I pamiętaj, co mierzy Google: Core Web Vitals w Google Search to LCP, INP i CLS – nie liczba kilobajtów jako taka.

Plan wdrożenia w 4 krokach: od inwentarza do monitoringu

Kolejność ma znaczenie: bez pomiaru nie wiesz, co naprawiać, a bez zmian systemowych wrócisz do tego samego problemu przy następnej kampanii.

Krok 1 – inwentarz i pomiar. Policz pliki i zważ stronę. Ile masz mediów (find na serwerze albo eksport z bazy), ile waży karta produktu na mobile, jakie są aktualne LCP, INP i CLS. Punkt wyjścia: PageSpeed Insights dla adresu produktu i raport Core Web Vitals w Search Console. To zadanie zrobisz sam w 2–3 godziny, nie wymaga dostępu do kodu.

Krok 2 – szybkie wygrane. Kompresja (JPEG jakość 75–82, PNG tylko tam, gdzie potrzebna przezroczystość), poprawne wymiary, uzupełnienie tekstów alt, zdjęcie loading="lazy" z obrazu LCP, usunięcie EXIF. Uwaga na pułapkę: razem z EXIF usuwany bywa znacznik orientacji, więc najpierw znormalizuj obrót zdjęcia, inaczej część kadrów wyląduje bokiem. Te prace też wykonasz samodzielnie.

Krok 3 – zmiany systemowe. Format AVIF/WebP z fallbackiem, srcset i sizes, CDN i object storage, procedury licencyjne i rejestr zgód, backup z testem odtworzenia. Tutaj wchodzi się już w motyw i konfigurację serwera.

Krok 4 – monitoring kwartalny. Przegląd Core Web Vitals w Search Console, kontrola mediów przy dodawaniu nowych SKU i przed kampaniami sezonowymi. Definicje i progi metryk znajdziesz w Web Vitals – to materiał, do którego warto wrócić przed każdym przeglądem.

Kryterium podziału prac: jeśli zadanie wymaga edycji motywu, konfiguracji serwera albo logiki modułu, taniej wychodzi zlecić je osobie, która robi to regularnie. Kompresję, alt i pomiary zostaw sobie. Godziny, które „oszczędzisz”, ucząc się nadpisywania szablonu produktu, są zwykle droższe niż stawka specjalisty.

Najczęstsze błędy i jak je wykryć

Lista kontrolna do odklikania

• Waga zdjęcia produktowego — DevTools → Network, filtr Img. Cel: 100–200 KB dla zdjęcia w rozdzielczości 2000×2000 px.
• Waga obrazu hero / LCP — Znajdź największy obraz pierwszego ekranu w Network. Cel: do 300 KB.
• Miniatury — Sprawdź warianty rozmiarów generowane przez sklep. Cel: 20–40 KB na miniaturę.
• Formaty i fallback — Sprawdź nagłówek Content-Type: AVIF lub WebP w nowej przeglądarce, JPEG jako zapas w starszej.
• width/height lub aspect-ratio — Lighthouse, audyt stabilności układu. Każdy powinien mieć zarezerwowane miejsce.
• Lazy tylko poniżej pierwszego ekranu — Przejrzyj szablon karty produktu i strony głównej pod kątem atrybutu loading.
• fetchpriority="high" na obrazie LCP — Sprawdź w HTML element wskazany jako LCP w PageSpeed Insights.
• LCP ≤ 2,5 s — PageSpeed Insights, dane polowe dla 75. percentyla użytkowników, nie wynik z laboratorium.
• INP ≤ 200 ms — PageSpeed Insights, sekcja danych polowych. Sam wynik laboratoryjny nie wystarcza.
• CLS ≤ 0,1 — PageSpeed Insights oraz raport Core Web Vitals w Search Console.
• Wideo na karcie produktu — Network → filtr Media. Cel: do 30 s, poniżej 10 MB, preload="none" lub "metadata".
• Teksty alternatywne — Przegląd alt: opisowe dla obrazów informacyjnych, puste dla dekoracyjnych, bez upychania fraz.
• Dane strukturalne Product — Sprawdź w narzędziu do testowania danych strukturalnych, czy pole image zawiera zdjęcia produktu.
• Martwe pliki — Po wymianie zdjęć sprawdź, czy stare pliki nie są już nigdzie linkowane i czy nie trafiają do sitemapy.

Najczęściej zadawane pytania

Źródła i materiały

• Google Search Central – Core Web Vitals
• Google Search Central – tworzenie treści dla ludzi
• Google Search Central – dane strukturalne
• web.dev – Core Web Vitals
• PrestaShop – dokumentacja dla deweloperów