Вэб-сайт

Як скараціць час LCP (Largest Contentful Paint) да менш чым 2 секунды: Поўны гайд

  • 15 хвілін на чытанне
Як скараціць час LCP (Largest Contentful Paint) да менш чым 2 секунды: Поўны гайд

Каб дасягнуць мэты па скарачэнні LCP да менш чым 2 секунды, неабходна выканаць некалькі крытычна важных крокаў: забяспечыць хуткі водгук сервера, правільна вызначыць самы вялікі бачны элемент старонкі, сціснуць і прыярытызаваць галоўны відарыс (hero image), паменшыць лішнюю нагрузку ад CSS і JavaScript, выкарыстоўваць кэшаванне і CDN, аптымізаваць шрыфты і вымяраць змены на аснове рэальных карыстальніцкіх даных. Largest Contentful Paint вымярае, за колькі часу загружаецца найбуйнейшы бачны элемент на экране карыстальніка — гэта можа быць тэкставы блок, відарыс, постар відэа ці фонавая выява. Паводле стандартаў Google, добры паказчык LCP — менш за 2,5 секунды; але для канкурэнтнага SEO, высокай канверсіі і больш плыўнага карыстальніцкага досведу імкнуцца трэба да паказчыка ніжэй за 2 секунды — гэта рэалістычная і дасягальная мэта.

У гэтым дапаможніку мы разгледзім праблему LCP не проста як паляпшэнне тэхнічнага бала, а як праект па аптымізацыі прадукцыйнасці, што непасрэдна ўплывае на рэальны карыстальніцкі досвед. Мы засяродзімся на кроках, якія часцей за ўсё прыносяць вынік менавіта на практыцы: хостінгавая інфраструктура, TTFB, аптымізацыя відарысаў, рэсурсы, што блакуюць рэндэрынг, плагіны WordPress, CDN і пласты кэшавання. Калі ваш сайт павольна загружаецца, у справаздачы PageSpeed Insights вы бачыце папярэджанне пра LCP або губляеце пазіцыі і канверсію з мабільнага трафіку, паслядоўна выканаўшы ніжэйпрыведзены кантрольны спіс, вы зможаце дасягнуць вымерных паляпшэнняў.

Што такое LCP і чаму мэта — менш за 2 секунды?

LCP — гэта адна з метрык Core Web Vitals, якая вымярае, наколькі хутка карыстальнік бачыць асноўны кантэнт старонкі. FCP (First Contentful Paint) адсочвае момант з’яўлення першага кантэнту, INP — затрымку ўзаемадзеяння, а CLS — візуальную стабільнасць. LCP жа засяроджваецца менавіта на тым вялікім кавалку кантэнту, якога чакае карыстальнік. На старонцы тавару гэта можа быць фота прадукту, у блогу — вокладка ці загаловак, на галоўнай старонцы — буйны банер.

Google вызначае добры парог LCP як 2,5 секунды. Але гэта мяжа, якая азначае толькі адсутнасць сур'ёзных праблем. У SEO-рэаліях 2026 года, асабліва з улікам мабільнага першынства, вынікаў пошуку на аснове штучнага інтэлекту, высокай канкурэнцыі і карыстальніцкай нецярплівасці, паказчык ніжэй за 2 секунды — гэта значна больш бяспечная мэта. На сайтах электроннай камерцыі, SaaS, карпаратыўных парталах і кантэнт-пляцоўках нават секундная затрымка можа павялічыць паказчык адмоваў і знізіць колькасць такіх дзеянняў, як запаўненне формаў, дадаванне ў кошык ці запыт прапановы.

Аптымізацыя LCP важная не толькі для пошукавікаў, але і для іміджу брэнда. Калі пры адкрыцці старонкі карыстальнік бачыць пусты экран, марудна з’яўляюцца выявы ці скача макет, давер да сайта падае. Менавіта таму выбар хуткага хостінгу Hostragons Вэб-хостынг, забеспячэнне бяспечнага сучаснага злучэння праз SSL SSL Сертіфікати і стварэнне даверу да брэнда з правільным даменным імем Даменны запыт з’яўляюцца неад’емнай часткай працы над прадукцыйнасцю.

Правільна вымярайце LCP: лабараторныя і рэальныя даныя

Перш чым пачаць аптымізацыю, трэба дакладна ацаніць бягучы стан. Самыя папулярныя інструменты — PageSpeed Insights, Lighthouse, Chrome DevTools, WebPageTest і справаздача Core Web Vitals у Google Search Console. Але інтэрпрэтаваць іх вынікі аднолькава няслушна. Lighthouse генеруе лабараторныя даныя, тэстуючы ў пэўных сімуляваных умовах прылады і сеткі. А CrUX і Search Console паказваюць рэальныя карыстальніцкія даныя. Каб скараціць час LCP да менш чым 2 секунды, неабходна выкарыстоўваць абодва тыпы інфармацыі.

Асноўныя паказчыкі для адсочвання

  • Элемент LCP: Які менавіта відарыс, тэкст ці блок пазначаны як LCP на старонцы?
  • TTFB: Колькі часу патрабуецца серверу, каб адправіць першы байт? Добрая мэта для большасці старонак — 200–500 мс.
  • Затрымка рэндэрынгу: Чаму браўзер малюе элемент з спазненнем, нават калі рэсурс ужо атрыманы?
  • Затрымка загрузкі рэсурсу: Наколькі позна пачынаецца запыт элемента LCP?
  • Працягласць загрузкі рэсурсу: Ці стварае праблемы памер файла ці затрымка сеткі падчас загрузкі LCP?

Напрыклад, калі на старонцы блога пад WordPress элементам LCP з’яўляецца вокладка ў фармаце WebP памерам 320 КБ, праблема звычайна кіраваная. Але калі тая ж выява важыць 2,8 МБ у JPEG і не паказваецца да загрузкі CSS-файлаў, LCP лёгка можа вырасці да 4–5 секунд. У іншым выпадку, калі памер файла малы, але TTFB складае 1,4 секунды, праблема хутчэй у хостінгу, запытах да базы даных ці адсутнасці кэша.

Найбольш распаўсюджаныя прычыны праблем з LCP

Праблема LCP звычайна складаецца не з адной прычыны, а з ланцужка затрымак. Сервер адказвае позна, HTML прыходзіць з спазненнем, крытычны CSS блакуе рэндэрынг, LCP-відарыс выяўляецца занадта позна, JavaScript займае галоўны паток, а змена шрыфтоў затрымлівае кантэнт. Таму проста ўсталяваць плагін ці сціснуць адну выяву не заўсёды дастаткова.

Найбольш распаўсюджаныя прычыны праблем з LCP
Вобласць праблемыПрыкметаПрыярытэтнае рашэннеЧаканы эфект
Павольны хостінг ці высокі TTFBПершы водгук больш за 800 мсLiteSpeed, NVMe, абнаўленне PHP, сервернае кэшаваннеВысокі
Вялікі галоўны відарыс (hero)Элемент LCP важыць больш за 1 МБWebP/AVIF, правільны памер, preloadВысокі
CSS, што блакуе рэндэрынгКантэнт не бачны да загрузкі CSSКрытычны CSS, ачыстка нявыкарыстоўванага CSSВысокі
Лішні JavaScriptГалоўны паток перагружаны, позні рэндэрынгDefer, delay, падзел кодаСярэдне-высокі
Неаптымізаваныя шрыфтыТэкст з’яўляецца з вялікай затрымкайFont-display swap, preload, лакальныя шрыфтыСярэдні
Адсутнасць CDN і кэшаПавольная загрузка з аддаленых лакацыйCDN, браўзерны кэш, edge cacheСярэдне-высокі

Гэтую табліцу можна разглядаць як карту прыярытэтаў. Першасная мэта — знайсці самы вялікі крок у ланцужку LCP, які выклікае затрымку. Калі TTFB высокі, перш чым займацца відарысамі, трэба вырашыць пытанні з серверам і кэшам. Калі TTFB добры, але LCP-відарыс грузіцца позна, трэба працаваць над фарматам, памерам і прыярытэтам выявы.

1. Зменшце час водгуку сервера

Аснова аптымізацыі LCP — хуткі водгук сервера. Калі HTML-дакумент спазняецца, браўзер пазней выяўляе і файлы CSS, JS і відарысы. Таму на сайтах з высокім TTFB першым крокам павінен быць аналіз хостінгавай інфраструктуры. Калі рэсурсаў агульнага хостінгу не хапае, ліміты CPU часта вычэрпваюцца ці запыты да базы даных выконваюцца занадта доўга, аптымізацыя старонак дасць абмежаваны эфект.

Праверкі на баку хостінгу

  • Перайдзіце на актуальную і стабільную версію PHP. Старыя версіі PHP могуць выклікаць сур’ёзныя затрымкі ў WordPress і сучасных CMS.
  • Праверце наяўнасць такіх функцый прадукцыйнасці, як NVMe-дыскі, серверы на базе LiteSpeed ці NGINX, падтрымка HTTP/2 ці HTTP/3.
  • Выбірайце лакацыю сервера як мага бліжэй да асноўнай аўдыторыі. Напрыклад, для сайта, арыентаванага на Беларусь, сервер у Еўропе дасць меншую затрымку.
  • Ачысціце табліцы базы даных, выдаліце лішнія рэвізіі і часовыя даныя.
  • Для сайтаў з вялікім трафікам разгледзьце VPS, воблачны сервер ці маштабаваны хостінг-план VPS Server.

Практычная мэта — дасягнуць TTFB на ўзроўні 200–400 мс для камп’ютараў і, па магчымасці, менш за 500 мс для мабільных прылад. Вядома, для дынамічных, персаналізаваных ці моцна залежных ад базы даных старонак гэтыя лічбы могуць вар’іравацца. Але для блогаў, карпаратыўных сайтаў і старонак катэгорый пры добра наладжаным кэшы гэтыя паказчыкі цалкам дасягальныя.

2. Вызначце і прыярытызуйце элемент LCP

Аптымізацыя без дакладнага ведання элемента LCP — гэта дзеянні наўздагад. Убачыць элемент LCP можна на панэлі Performance у Chrome DevTools ці ў справаздачы PageSpeed Insights. Часцей за ўсё гэта вокладка, слайдэр, буйны загаловак ці постар відэа ў верхняй частцы старонкі. Пасля вызначэння элемента неабходна «растлумачыць» браўзеру, што гэты рэсурс важны.

Рэкамендаваны падыход для галоўнага відарыса (hero)

  • Не прымяняйце lazy load да LCP-відарыса. Галоўная выява ў верхняй частцы экрана не павінна загружацца ляніва.
  • Вызначайце відарыс у HTML як мага раней. Hero-відарысы, зададзеныя праз CSS як фон, часам выяўляюцца пазней.
  • У адпаведных сітуацыях выкарыстоўвайце preload і высокі прыярытэт загрузкі (fetch priority).
  • Падавайце розныя памеры для мабільных і дэсктопных прылад. Не адпраўляйце малюнак шырынёй 1920 пкс на экран мабільнага тэлефона з шырынёй 390 пкс.
  • Заўсёды пазначайце памеры відарыса атрыбутамі width і height. Гэта таксама зніжае рызыку CLS.

Напрыклад, калі элементам LCP на галоўнай старонцы з’яўляецца банер 1600x900 пікселяў, падача яго мабільнай версіі ў WebP шырынёй 720 пкс істотна зменіць сітуацыю. Пасля сціскання выява можа зменшыцца з 1,5 МБ да 180–250 КБ. Адно гэтае змяненне можа палепшыць мабільны LCP больш чым на секунду.

3. Аптымізуйце відарысы з дапамогай WebP ці AVIF

Відарысы — найбольш частая прычына праблем з LCP. Асабліва на сайтах пад WordPress зыходнае дазвол загружанай выявы можа быць вельмі вялікім, і нават калі тэма паказвае яе маленькай, браўзер усё роўна вымушаны спампоўваць вялікі файл. Таму недастаткова проста сціснуць відарыс — трэба падаваць яго правільнага памеру.

Кантрольны спіс для аптымізацыі відарысаў

  • Канвертуйце файлы JPEG і PNG у фармат WebP ці AVIF, дзе гэта магчыма.
  • Сціскайце вокладкі з дапушчальным узроўнем страты якасці. Звычайна дыяпазон 70–85% якасці дае добры вынік.
  • Выкарыстоўвайце адаптыўныя відарысы (responsive images). Дзякуючы srcset на розныя экраны будуць адпраўляцца розныя памеры.
  • Выдаляйце непатрэбныя EXIF-даныя і метаданыя.
  • Для іконак па магчымасці выкарыстоўвайце SVG, але спрашчайце залішне складаныя SVG-файлы.

У тыповым сцэнары для кантэнт-сайта вокладкі блога важылі ў сярэднім 1,2 МБ, а пасля канвертацыі ў WebP і правільнага змянення памеру змаглі дасягнуць 180 КБ. Калі LCP-відарыс — гэта і ёсць вокладка, то сур’ёзны прырост хуткасці будзе бачны асабліва на мабільных 4G-злучэннях. Гэта паляпшае не толькі бал PageSpeed, але і першае ўражанне карыстальніка.

4. Паменшыце колькасць CSS-файлаў, што блакуюць рэндэрынг

Калі браўзер атрымлівае HTML, яму патрэбныя правілы CSS, каб адмаляваць старонку. Вялікія, непадзеленыя і нявыкарыстоўваныя файлы стыляў могуць затрымаць з’яўленне элемента LCP. Асабліва гатовыя тэмы і канструктары старонак часта загружаюць мноства файлаў стыляў, якія не патрэбныя на канкрэтнай старонцы.

Што рабіць з CSS

  • Стварыце крытычны CSS і загружайце стылі, неабходныя для верхняй часткі экрана, як мага раней.
  • Ачысціце нявыкарыстоўваны код CSS ці загружайце яго толькі для пэўных старонак.
  • Мініфікуйце CSS-файлы, але не абмяжоўвайцеся толькі гэтым; асноўны выйгрыш дае менавіта скарачэнне лішняга кода.
  • Заблакуйце загрузку CSS-файлаў іншых плагінаў на тых старонках, дзе яны не патрэбныя.
  • Выкарыстоўвайце толькі неабходныя кампаненты вашай тэмы; перагледзьце патрэбу ў вялікіх слайдэрах, анімацыях і пакетах іконак.

Тут важна не парушыць візуальную цэласнасць старонкі пры стварэнні крытычнага CSS. Няправільна наладжаны крытычны CSS можа выклікаць першапачатковае адлюстраванне сапсаванага дызайну ці рост CLS. Таму пасля кожнага змянення неабходна праводзіць асобныя тэсты на мабільных і дэсктопных прыладах.

5. Трымайце пад кантролем нагрузку ад JavaScript

JavaScript можа ўплываць на LCP двума шляхамі. Па-першае, JS-файлы могуць блакаваць працэс рэндэрынгу. Па-другое, яны могуць надоўга займаць галоўны паток, затрымліваючы адмалёўку элемента LCP браўзерам. Асабліва моцна прадукцыйнасць могуць зніжаць коды адсочвання, памочнікі анлайн-чатаў, рэкламныя скрыпты, інструменты A/B-тэсціравання і віджэты сацыяльных сетак.

Практычныя тактыкі для JavaScript

  • Адкладайце некрытычныя скрыпты з дапамогай defer ці async.
  • Загрузку іншых скрыптоў, не патрэбных для першага экрана, адкладвайце да моманту ўзаемадзеяння карыстальніка.
  • Адключайце лішнія JS-файлы канструктараў старонак на тых старонках, дзе яны не выкарыстоўваюцца.
  • Каб паменшыць доўгія задачы, выкарыстоўвайце падзел кода і загрузку па модулях.
  • Пратэстуйце ўплыў скрыптоў аналітыкі, пікселяў і чатаў паасобку.

Напрыклад, калі на галоўнай старонцы карпаратыўнага сайта адначасова працуюць слайдэр, бібліятэка анімацыі, убудаваная мапа, анлайн-чат і тры розныя коды адсочвання, дасягнуць мэтавага LCP будзе вельмі складана. Некаторыя з гэтых інструментаў могуць быць неабходныя для канверсіі, але зусім не абавязкова запускаць іх усе пры першай загрузцы. Аптымізацыя прадукцыйнасці — гэта правільная расстаноўка прыярытэтаў без шкоды для бізнес-мэтаў.

6. Паскарыце шрыфты і захавайце бачнасць тэксту

6. Паскарыце шрыфты і захавайце бачнасць тэксту

На многіх старонках элементам LCP з’яўляецца не відарыс, а буйны загаловак ці тэкставы блок. У такім выпадку позняя загрузка вэб-шрыфтоў можа непасрэдна паўплываць на LCP. Выклік мноства варыянтаў напісання і стыляў з вонкавых сэрвісаў шрыфтоў выклікае затрымкі, асабліва на мабільных прыладах.

Рэкамендацыі па аптымізацыі шрыфтоў

  • Загружайце толькі тыя варыянты напісання шрыфтоў, якія сапраўды выкарыстоўваюцца. Праверце, ці так патрэбныя варыянты 300, 400, 500, 600, 700 і курсіў.
  • Выкарыстоўвайце font-display: swap, каб тэкст не заставаўся нябачным падчас загрузкі шрыфтоў.
  • Рабіце preload для крытычных шрыфтоў, але пазбягайце празмернага выкарыстання preload.
  • Па магчымасці раздавайце шрыфты з лакальнага сервера.
  • Выбар сістэмных шрыфтоў у некаторых праектах — самае хуткае і простае рашэнне.

Памяншэнне колькасці шрыфтавых файлаў здаецца дробяззю, але калі LCP — тэкставы элемент, эфект будзе значным. Акрамя таго, шрыфты моцна ўплываюць на CLS. Пры загрузцы розных шрыфтоў шырыня тэксту можа мяняцца, і макет «скокне». Таму прадукцыйнасць і візуальны дызайн трэба ацэньваць у комплексе.

7. Правільна наладзьце кэш і CDN

Кэшаванне сур’ёзна паляпшае LCP пры паўторных візітах і для статычнага кантэнту. Кэш старонкі, аб’ектны кэш, браўзерны кэш і кэш CDN — гэта розныя пласты. Іх агульная мэта — хутчэй падаваць адзін і той жа кантэнт замест яго паўторнай генерацыі ці перадачы з аддаленага сервера.

На сайтах пад WordPress сумеснае выкарыстанне кэша на базе LiteSpeed, аб’ектнага кэша Redis, браўзернага кэша і інтэграцыі з CDN паскарае час генерацыі HTML і дастаўку статычных файлаў. У карпаратыўных ці індывідуальных праектах варта планаваць стратэгію кэшавання на ўзроўні прыкладання, аптымізацыю запытаў да базы даных і edge-кэшаванне. Калі ваш трафік ідзе з розных гарадоў і краін, выкарыстанне CDN становіцца яшчэ больш важным Кіраўніцтва па CDN і хуткасці сайта.

На што звярнуць увагу пры наладзе кэша

  • Вызначце доўгі тэрмін кэшавання для статычных файлаў і выкарыстоўвайце версіянаванне файлаў.
  • Асцярожна наладжвайце правілы кэшавання HTML для дынамічных абласцей, такіх як асабісты кабінет, кошык ці раздзелы з рэгістрацыяй.
  • Ацаніце магчымасці CDN па аптымізацыі відарысаў, сцісканню Brotli і падтрымцы HTTP/3.
  • Плануйце ачыстку кэша ў адпаведнасці з вашым рэдакцыйным графікам.
  • Калі патрабуецца рознае кэшаванне для мабільных і дэсктопных прылад, праверце, каб не адбывалася памылковай падачы кантэнту.

8. Спецыяльны план для паляпшэння LCP на WordPress

WordPress можа быць хуткім пры правільнай наладзе, але бескантрольнае выкарыстанне тэм і плагінаў павялічвае LCP. Самая частая памылка, якую мы бачым на сайтах пад WordPress, — спроба вырашыць праблему прадукцыйнасці толькі плагінам кэшавання. Аднак выбар тэмы, колькасць плагінаў, дысцыпліна работы з відарысамі і якасць хостінгу павінны разглядацца разам Хостынг WordPress.

Пакрокавы кантрольны спіс для WordPress

  • Выкарыстоўвайце лёгкую і актуальную тэму. Замест перагружаных функцыямі тэмаў выбірайце арыентаваныя на патрэбы.
  • Выдаліце непатрэбныя плагіны. Нават адключаныя плагіны могуць ствараць рызыкі для бяспекі і кіравання.
  • Калі вы выкарыстоўваеце канструктар старонак, паменшыце загрузку глабальных віджэтаў і анімацый.
  • Змяняйце памер відарысаў перад загрузкай на сайт.
  • Уважліва наладзьце кэш старонкі, аптымізацыю CSS/JS і малюнкаў у плагіне кэшавання накшталт LiteSpeed.
  • Рэгулярна ачышчайце рэвізіі базы даных, спам-каментары, часовыя даныя (transients) і чарнавікі.

Напрыклад, на старонцы блога першапачатковы LCP можа быць 4,1 секунды. Калі TTFB складае 900 мс, відарыс вокладкі — 1,8 МБ, а CSS-файл тэмы — 450 КБ, парадак дзеянняў відавочны: спачатку зніжаем TTFB з дапамогай хостінгу і кэша, потым робім вокладку адаптыўнай у фармаце WebP, і нарэшце скарачаем нявыкарыстоўваны CSS. Пасля гэтай працы рэалістычнай мэтай будзе паказчык LCP у дыяпазоне 1,7–2,1 секунды.

9. Праводзьце асобную аптымізацыю для мабільнага LCP

Мабільныя карыстальнікі звычайна маюць меншую вылічальную магутнасць і нестабільную якасць сувязі. Таму LCP, які добра выглядае на дэсктопе, на мабільным можа быць дрэнным. Паколькі ў ацэнках Google мабільны досвед мае вялікую вагу, тэсты трэба абавязкова праводзіць у мабільным сцэнары.

Пры мабільнай аптымізацыі вялікія відарысы і цяжкі JavaScript ствараюць больш праблем. Калі на першым экране вы выкарыстоўваеце аўтаматычнае відэа, вялікі слайдэр, інтэнсіўную анімацыю і ўбудаваны знешні кантэнт, дасягнуць мэты па LCP будзе цяжка. На мабільным прыладах лепшы вынік звычайна даюць просты вобраз у шапцы, дакладны загаловак, аптымізаваны відарыс і хуткі водгук сервера.

Хуткія перамогі для мабільных

  • Замест слайдэра выкарыстоўвайце адзін аптымізаваны галоўны відарыс.
  • Замест аўтаматычнага прайгравання відэа на першым экране пакажыце сціснуты постар.
  • Не хавайце непатрэбныя дэсктопныя кампаненты праз CSS, а наогул не загружайце іх на мабільных.
  • Вызначайце srcset для відарысаў з улікам мабільных кантрольных кропак.
  • Запускайце іншыя скрыпты толькі пасля першай загрузкі.

10. Тэстуйце змены паслядоўна і адсочвайце вынік

Адна з самых вялікіх памылак у аптымізацыі LCP — рабіць шмат змен адначасова, пасля чаго немагчыма зразумець, які крок спрацаваў. Для вымернага прагрэсу фіксуйце вынікі да і пасля кожнага змянення. PageSpeed Insights, пакадравая візуалізацыя ў WebPageTest і запіс прадукцыйнасці ў Chrome DevTools — вельмі карысныя інструменты ў гэтым працэсе.

Рэкамендаваны паток тэсціравання наступны: спачатку выберыце 3–5 крытычных URL: галоўную старонку, самы папулярны допіс у блогу, старонку катэгорыі і старонку канверсіі. Для кожнага URL запішыце бягучыя LCP, TTFB, элемент LCP, агульны памер старонкі і колькасць запытаў. Затым паслядоўна прымяняйце паляпшэнні: спачатку сервер/кэш, потым відарысы, затым CSS/JS, затым шрыфты. Пасля кожнага этапу паўторна тэстуйце тыя ж URL. Нарэшце, дачакайцеся абнаўлення справаздачы Core Web Vitals у Google Search Console — даныя рэальных карыстальнікаў стануць больш паказальнымі праз некалькі тыдняў.

Кантрольны спіс для дасягнення LCP менш за 2 секунды

  • Знізьце TTFB па магчымасці ніжэй за 500 мс.
  • Дакладна вызначце элемент LCP і забяспечце яго раннюю загрузку на старонцы.
  • Падавайце галоўны відарыс (hero) у фармаце WebP ці AVIF правільнага памеру.
  • Не прымяняйце лянівую загрузку да відарысаў на першым экране.
  • Выкарыстоўвайце крытычны CSS, скарачайце колькасць нявыкарыстоўваных файлаў CSS і JS.
  • Адкладайце загрузку непатрэбных іншых скрыптоў.
  • Паменшыце колькасць шрыфтоў і іх варыянтаў, выкарыстоўвайце font-display: swap.
  • Наладзьце пласты кэшавання: кэш старонкі, браўзерны кэш, аб’ектны кэш і CDN.
  • Праводзьце асобнае тэсціраванне для мабільных прылад і адсочвайце рэальныя карыстальніцкія даныя.
  • Вымярайце кожнае змяненне паасобку, каб стварыць устойлівы стандарт прадукцыйнасці.

Вынік

Скарачэнне часу LCP да менш чым 2 секунды — гэта не аднаразовая налада плагіна, а комплексная праца, якая складаецца з хостінгу, прыярытызацыі рэсурсаў, дысцыпліны работы з відарысамі, кіравання CSS/JS, кэшавання і працэсаў вымярэння. Самы хуткі вынік звычайна даюць крокі па зніжэнні TTFB, аптымізацыі LCP-відарыса і скарачэнні рэсурсаў, што блакуюць рэндэрынг. Для доўгатэрміновага поспеху вы павінны зрабіць прадукцыйнасць часткай вашага працэсу публікацыі.

Калі інфраструктура вашага сайта абмяжоўвае мэты па прадукцыйнасці, пачаць варта з больш хуткага хостінгу, правільнага размяшчэння сервера і наладкі бяспекі SSL. На Hostragons вы можаце азнаёміцца з варыянтамі размяшчэння, якія падыходзяць для вашага сайта, каб закласці больш трывалую аснову для LCP і агульнага карыстальніцкага досведу Hostragons пакеты хостынгу.

Частыя пытанні

Якім павінен быць паказчык LCP?

Google лічыць добрым LCP ніжэй за 2,5 секунды. Але для канкурэнтнага SEO і лепшага карыстальніцкага досведу моцнай мэтай з’яўляецца паказчык ніжэй за 2 секунды. Асабліва ў мабільным трафіку гэтая мэта можа станоўча паўплываць на каэфіцыент канверсіі.

Што найбольш уплывае на час LCP?

Найбольш распаўсюджаныя фактары: павольны водгук сервера, вялікі галоўны відарыс, CSS, што блакуе рэндэрынг, цяжкі JavaScript, шрыфты, якія позна загружаюцца, і адсутнасць кэша. Каб зразумець, які фактар дамінуе, трэба даследаваць элемент LCP з дапамогай PageSpeed Insights і DevTools.

Ці дапамагае CDN знізіць LCP?

Так, асабліва калі карыстальнікі знаходзяцца далёка ад сервера, CDN можа паскорыць загрузку, падаючы статычныя файлы з бліжэйшых вузлоў. Аднак калі TTFB, памер відарысаў і рэсурсы, што блакуюць рэндэрынг, у дрэнным стане, аднаго CDN можа быць недастаткова.

Які першы крок у аптымізацыі LCP для WordPress?

Першы крок — вызначыць элемент LCP і значэнне TTFB. Затым праверыць налады хостінгу і кэша, аптымізаваць відарыс вокладкі ці галоўны відарыс, паменшыць нагрузку ад непатрэбных тэм і плагінаў.

Ці добра выкарыстоўваць лянівую загрузку (lazy load) для LCP?

Лянівая загрузка карысная для відарысаў ніжэй лініі згортвання. Але прымяненне яе да элемента LCP на першым экране звычайна шкоднае, бо браўзер пачынае грузіць гэты важны рэсурс занадта позна. LCP-відарыс павінен загружацца прыярытэтна.

Падзяліцеся гэтым артыкулам:
Rina Zhang

Стратэг па SEO і кантэнт-стратэгіі

Працягвае працу ў галіне міжнароднага SEO і кіравання кантэнтам больш за 8 гадоў. Спецыялізуецца на павышэнні арганічнай прадукцыйнасці вэб-сайтаў.

Усе артыкулы →