Изображения и скорост: формати, размери, отложено зареждане

Защо изображенията определят времето за зареждане

Google пише, че изображенията често имат най-голям дял в общия размер на страницата, което може да направи страниците бавни и скъпи за зареждане. Два от Core Web Vitals зависят пряко от изображенията. Largest Contentful Paint (LCP) измерва зареждането: Google съветва най-големият елемент да се появи в първите 2,5 секунди след началото на зареждането на страницата. На много страници този елемент е изображение, например голяма снимка най-горе. Cumulative Layout Shift (CLS) измерва визуалната стабилност и трябва да остане под 0,1. Изображенията, които пристигат без запазено място, избутват текста надолу и повишават тази стойност.

Правилният формат

• Снимки: JPEG работи навсякъде. WebP и AVIF често са значително по-малки при подобно качество.
• Графики с остри ръбове или прозрачност: PNG или WebP и AVIF, които също могат да бъдат прозрачни.
• Лога и икони: SVG, защото остава остър при всеки размер и обикновено е много малък.
• Google Търсене поддържа изображения в атрибута src във форматите BMP, GIF, JPEG, PNG, WebP, SVG и AVIF.

Ако предлагаш WebP или AVIF, можеш да запазиш JPEG като резервен вариант в елемент picture. Браузърът избира първия източник, който разбира.

Правилният размер

Изображение с ширина 2400 пиксела, което се показва на 600 пиксела, хаби повечето от байтовете си. Експортирай изображенията приблизително в ширината, в която се показват, а за екрани с висока резолюция – приблизително в двойна ширина. След това ги компресирай. В много програми за изображения настройка за качество около средата на скалата е достатъчна за снимки в мрежата. Провери резултата в пълен размер, преди да замениш оригинала.

srcset и sizes

Един файл никога не пасва на всеки екран. Със srcset предлагаш няколко файла на едно и също изображение и посочваш ширината на всеки файл. Със sizes казваш на браузъра колко широко ще се показва изображението. След това браузърът избира най-малкия файл, който е достатъчно остър.

<img src="/img/sofa-800.jpg"
     srcset="/img/sofa-400.jpg 400w, /img/sofa-800.jpg 800w, /img/sofa-1600.jpg 1600w"
     sizes="(max-width: 700px) 100vw, 700px"
     width="800" height="533"
     alt="…">

В този пример изображението запълва екрана на тесните екрани и е широко 700 пиксела на по-широките. Google препоръчва винаги да има резервен вариант в атрибута src. Вместо трите точки напиши истински алтернативен текст.

width и height срещу разместването

Без width и height браузърът не знае колко място е нужно на изображението, докато файлът не пристигне. Тогава текстът под него скача надолу. Ръководството на web.dev за разместванията съветва: винаги включвай атрибутите width и height в изображенията и видео елементите, с размера на файла в пиксели или поне с правилното съотношение на страните. Съвременните браузъри задават от тези стойности съотношението на страните на изображението по подразбиране и запазват мястото. В CSS width: 100% и height: auto запазват изображението гъвкаво. Ако не можеш да зададеш атрибутите, ръководството посочва CSS свойството aspect-ratio като алтернатива.

Отложено зареждане

С loading="lazy" браузърът зарежда изображение едва когато то се доближи до видимата област. Това спестява данни за изображенията по-надолу в страницата. Google казва за отложеното зареждане (lazy loading): не го добавяй към съдържание, което вероятно ще е видимо веднага, когато потребителят отвори страницата. Вграденото отложено зареждане на браузъра е налично за изображения и iframe елементи.

LCP изображението

Най-голямото изображение най-горе, често hero изображение или основната снимка на продукта, е най-важният файл на страницата. Ръководството на web.dev за LCP казва: никога не зареждай LCP изображението си отложено. fetchpriority="high" е подсказка към браузъра да го зареди рано. Според ръководството висок приоритет за повече от едно или две изображения вече не помага. Изображенията, чийто адрес скриптова библиотека крие в data-src или които са само CSS фон, браузърът открива късно. За фоново изображение ръководството посочва предварително зареждане с link rel="preload" в HTML. AVIF или WebP и по-малък файл също скъсяват времето за зареждане.

За да видиш как се представят страниците ти, Google насочва към отчета Core Web Vitals в Search Console. За отделна страница инструментите за производителност на браузъра ти показват кой елемент е LCP елементът и кои елементи разместват оформлението. Измервай преди и след промяна, за да знаеш дали е помогнала.

Кратък чеклист

• Зарежда ли се най-голямото изображение най-горе нормално, а не отложено?
• Има ли всеки img width и height или място, запазено с aspect-ratio?
• Широк ли е всеки файл приблизително колкото се показва и компресиран ли е?
• Идват ли големите снимки в няколко ширини със srcset и sizes?
• Има ли JPEG или PNG файлове, които биха могли да бъдат WebP или AVIF?

Работа с Do4U

Проверка на изображения чете една страница и всяко изображение в нея. За всеки файл тя отчита формата, размера на файла и пикселите, а от HTML – width и height, loading, fetchpriority, srcset и sizes, източниците в picture и фоновите изображения в атрибутите style. Do4U предполага вероятното LCP изображение от HTML. Той не го измерва, защото истинския LCP елемент го определя браузърът. Получаваш таблица на изображенията с констатациите, общото тегло и кратко обобщение. Изображенията, които JavaScript вмъква, и фоновите изображения от външни CSS файлове не са включени. Не се използва ИИ и проверката е безплатна, с дневен лимит.

Do4U открива подсказки, а ти проверяваш и решаваш. Потвърди LCP елемента с инструментите за производителност на браузъра си, преди да промениш страницата.