По-бърз сайт с по-леки изображения, кеш на браузъра и CDN

По-бърз сайт започва с по-леки изображения, правилно настроен кеш на браузъра и CDN пред хостинга. Google смята зареждането за добро, когато най-големият видим елемент се появи до 2,5 секунди, а средната начална страница на мобилен телефон съдържа около 900 KB само изображения (web.dev (Google), HTTP Archive).

Колко бърз трябва да е сайтът

Largest Contentful Paint (LCP) мери кога се изрисува най-големият елемент в първия екран. Добрата стойност е до 2,5 секунди, а над 4 секунди резултатът се смята за слаб (web.dev (Google)). Оценката се взима при 75-ия персентил от зарежданията, отделно за мобилни и настолни устройства. Това значи, че в зелената зона трябва да са поне три от всеки четири посещения, а не само вашите от бърза офис връзка.

Кандидати за LCP са обикновените изображения, кориците на видеата, фоновите картинки, зададени през CSS, и блоковете с текст (web.dev (Google)). Нашият извод е, че при типичния сайт на малка фирма с голяма снимка най-отгоре точно тази снимка е LCP елементът. Затова работата започва от изображенията.

Реалните стойности за собствения си сайт следете в Search Console. Ако още не сте добавили сайта там, започнете от първите стъпки с Google Search Console.

Защо изображенията тежат най-много

Изображенията на началната страница на мобилен са около 2,6 пъти повече от тези на вътрешните страници (наше изчисление по данни на HTTP Archive) (HTTP Archive). Затова първо се заемете с началната страница. Там обикновено стоят слайдерът, голямата снимка и логата на партньори.

Изображения в WebP и в правилния размер

WebP със загуба на качество е с 25–34% по-малък от JPEG при еднакво качество по метриката SSIM (Google for Developers). Без загуба WebP е с 26% по-лек от PNG, а версията със загуба и с прозрачност често е около три пъти по-малка от PNG. Ако всичките 900 KB от средната мобилна начална страница са снимки в JPEG, преминаването към WebP би спестило между 225 и 306 KB. По наше изчисление по данни на Google и HTTP Archive страницата ще носи около 594–675 KB изображения (HTTP Archive).

Форматът решава само половината задача. Качвайте снимката в ширината, в която тя реално се показва на екрана. Кадър от телефона в пълна резолюция, свит с CSS до тясна колона, пак се изтегля целият. Логата и иконите са по-леки като SVG, а фотографиите в WebP.

Мързеливо зареждане без забавяне на първия екран

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

Една уговорка е важна. Голямата снимка в горната част е LCP елементът, затова при нея мързеливото зареждане само отлага момента, в който Google отчита, че страницата е заредена (наш извод по документацията на web.dev и MDN) (web.dev (Google), MDN Web Docs (Mozilla)). Освен това събитието load настъпва, преди да са дошли отложените елементи. Тест, който мери само това събитие, показва по-добра картина от тази, която вижда посетителят.

Как да настроите кеша на браузъра

Браузърът решава колко дълго да пази един файл по заглавката Cache-Control. Стойността max-age=N значи, че отговорът е пресен N секунди от момента, в който сървърът го е създал (MDN Web Docs (Mozilla)). Една година е 31 536 000 секунди.

Версионираните файлове, например style.v2.css, могат да стоят цяла година, защото при промяна на файла адресът също се сменя и старото копие никога не се ползва повторно (MDN Web Docs (Mozilla)). HTML трябва да е с no-cache, за да получава посетителят новата страница заедно с новите адреси на файловете.

Честа грешка е да се сложи no-store навсякъде „за всеки случай“. Тази стойност забранява съхраняването в браузъра и в споделени кешове, а Cloudflare не кешира и отговори с no-cache или max-age=0 (MDN Web Docs (Mozilla), Cloudflare Docs). Така CDN-ът остава напълно без работа.

Какво кешира CDN по подразбиране

CDN като Cloudflare стои между посетителя и хостинга и връща готово копие от своя кеш, без да пита сървъра (Cloudflare Docs). Cloudflare избира какво да кешира по разширението на файла, не по MIME типа (Cloudflare Docs). По подразбиране влизат CSS, JS, JPG, PNG, WEBP, SVG, шрифтове и PDF, но не и HTML и JSON. За да се кешират и страниците, трябва отделно правило (Cache Rule).

Cloudflare не кешира отговор със заглавка Set-Cookie, със стойност private или no-store, както и заявки, различни от GET (Cloudflare Docs). Когато сървърът изобщо не изпраща Cache-Control, отговорите с код 200 стоят в кеша 120 минути, а страниците с грешка 404 само 3 минути. На безплатния план най-големият файл, който може да се кешира, е 512 MB.

Без кеширане на HTML всяка страница се генерира наново от хостинга (наш извод от поведението по подразбиране) (Cloudflare Docs). CDN ускорява снимките и стиловете, но не поправя бавен сървър. Ако HTML-ът отговаря бавно дори след оптимизациите, обмислете прехвърляне на сайта на нов хостинг без прекъсване.

Как да проверите дали кешът работи

Отворете инструментите за разработчици в браузъра, раздела „Network“, изберете файл и вижте заглавката cf-cache-status в отговора. Статус HIT значи, че файлът е дошъл от кеша на Cloudflare, а MISS, че е можел да се кешира, но още го е нямало там (Cloudflare Docs). При EXPIRED копието е било остаряло и сървърът е изпратил ново.

Статус BYPASS показва, че отговорът на сървъра не е позволил кеширане. Типичните причини са no-store, private, Set-Cookie или Vary: * (Cloudflare Docs). DYNAMIC значи, че файлът изобщо не отговаря на условията за кеш, например заради типа си, заради правило за заобикаляне или включен режим за разработка. При HTML статусът DYNAMIC е нормален, защото страниците не се кешират по подразбиране (Cloudflare Docs). Ако снимка упорито връща BYPASS, потърсете тема или плъгин, който добавя бисквитка към всеки отговор.

Работете в този ред, защото всяка стъпка се мери поотделно:

1. Запишете текущия LCP от Search Console.
2. Преобразувайте големите снимки в WebP и ги смалете до ширината, в която се показват.
3. Сложете loading="lazy" само на изображенията и вградените видеа под първия екран.
4. Задайте Cache-Control по таблицата по-горе.
5. Включете CDN и проверете cf-cache-status при второто зареждане.

Ако сайтът тепърва се прави и съдържанието му рядко се променя, мислете за скоростта още при избора на платформа.