Аўтаматычна пропусканне процеса адрасавання зместу за дапамою параметраў content-visibility і contain-intrinsic-size

Дзёльныя старонкі, заполненыя павтараючыміся элементамі, такімі як спісы продуктав, фіды, архіўы і вялікія таблыцы, часта працуюць медленна, нават калі ў яных няма великага колькасці коду на JavaScript. Прычына зазвычай у тым, што браузер вылічвае стылі і макет для кожнага элемента на старонцы, укладаючы ў гэта сотні картак, да якіх візітар не прасунуўся і можа ніколи не дазець. У гэтым кярыранты раз’яснюецца, як два атрыбуты CSS — content-visibility і contain-intrinsic-size — дазволяюць браузеру адкласты гэту роботу, як гэтыя змены вяжаюцца з показнікамі Core Web Vitals і процесам аўтаналіза, і дзе гэтыя методы не працуюць або є непаслужальнымі.

Тыповы прыклад: дзёльны спіс, які працуе медленна без явных прычын

Уявіце сторонку каталогу «Адзін усе продукты» для інтэрнет-магазіна. На серверы выдаецца адна дужа дзялёная сторонка, на якой практычна 600 карточак продуктав, кожная з якіх мае адпраўку, назву, цэну і рэйтынг. Не існуе пагінацыі, няма можлівасці бесканечнага прасування і вяртуалізацыі. Компанія паслужваецца такім спосабам: адна URL, кожны продукт можна пераглядаць, усё доступна за дапамогою функцыі пошуку ў сторонцы.

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

Панель Performance у DevTools рассказвае іншую історыю. Большая частка часу галоўнай вяліны прыходзіцца на Layout, і гэта вядзецца раней, чым скрыпты маюць можлівасць падмяніць ситуацыю.

Чаму контэнт за межамі екрана все равно коштае вас

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

У прыкладзе магазіна это значыць, што ўсе 600 картак, кожная з якіх мае рамку для адпраўкі, заголовак упаковкі, цэну і рядок з атрыбутамі оценкі, праходзяць праз процесы стылювання і форматавання, прычаму пакупальнік бачыць толькі першую з іх. Пакупальнік можа бачыць, мабыт, восем продуктаў. Іншыя 592 паказваюцься як непатрэбныя наразе, але браузер не можа знайсці спосабу, чы рэндзер будзе праскроліваць да них, таму за значычнай настройкой ён спрацоўвае з усімі як з контэнтам, які павінен быць гатовы ўжо зараз. Гэта тое марнаванне, якое трэба адрыхтуваць. Якщо хочаце падтвердзіць, як разлічуюцяся цены за кожны з этых этапаў обробкі, адзірніце нашыя пояснення ў стацыі па чым складаюцяся виткі браузера на рефлоу, перапісв і композыцыю.

Рашэння: два заявлення для элемента, які павтарыцца

Застосавыце обая свайныя элементу, які павтараецца, тут — карточцы товара. Першая свайна паведамляе браузэру, што ён можа прыпісці адрасаванне зместу карточкі, калі яна знаходзится далека ад вікна прэвью. Другая свайна задае розмер адміністратыўнага прастору для карточак, рэальныя розмеры якіх ўсё ще не вядомы.

.product-card {
  content-visibility: auto;
  contain-intrinsic-size: auto 340px;
}

За дапамогою content-visibility: auto карточка, якая не знаходзится блізу вікна прэвью, застаецца ў DOM і ў дрэва адчыненасці, і функцыя find-in-page все равно можа знайсці ў яе тэкст. Змянюецца тое, што браузэр не витрачае ресурсы на стыль, макет і адрасаванне зместу карточкі, пакуль яна не падыходзіць да экрана. По суті, гэтая свайна застосавляе правіла макетаў, стылю і адрасавання да элемента, што дазволяе браузэру спрыяжваць падчынную структуру як незалежную і безпечна ўсунуць яе.

Які можа быць розмер выгод

У дэме, выпусканым на web.dev, Google взяў довгую стороннюю сторунку, разбітую на секцыі, і зменіў час ёё адрасавання з 232 мс да 30 мс, што ў сярэзна семразова павышэнне. Памятайце, што гэта спецыяльна створаная дэм-сторунка, а не виробны сайт. Для рэальнага каталогу продукта, як той, што описан вышэй, болей реалістычным є ожыданне павышэння праўда на 2 разы, што вядома можа змяніць ситуацыю між сторункай, якая ўсё яшчэ завантажваецца, і сторункай, якая выглядае готовай ў момент першага адрасавання.

Экстремальныя документы паказваюць максімальны рубеж. У выступленні на Chrome Dev Summit гэтае рашэнне было застосавана да вельмі большай сторунки з адной сторанкою на HTML, якая мела болей 270 000 вузлаў DOM, і час адрасавання зменіўся з праўда 50 секунд да або 400 мілісэкунд. Такія сторункі зустрічаюцца рэдка, але гэта ілюструе, сколькі зусіль витрачаецца на контэнт, які ніхто не можа пабачыць.

Це дапамагае быть точным па тым, што выканалася. CSS не прыводзіць процэсар да вышэйшай швальнасці. Вы паведамляеце браузеру, што вяліка частка работы не павінна выканацца зараз. Калі на сторунцы ёсць 600 карточак, а на вікні прывязкі показваецца толькі восем, адразу атрыбутавацыя кожнай карточкі рэдкая ўзьме на сябе найлепшы выкарыстоўкі галоўнага потока.

Чаму параметр contain-intrinsic-size не ўзельгідны

Якщо вы выкарыстаеце толькі content-visibility: auto, ступічак прасування пачынае рухацца нерэгулярна пад час прасування, і гэта легка можа быць спылена з некалякім багам.

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

contain-intrinsic-size задае розмер, які трэба прыймаць, калі элемент прахоўваецца. Значэнне 340px у прыкладзе — цэлая апрыск для картак, якія ўжо не былі атрыбутаваны. Точнасць не трэба; дастатнек адпаведнай апрыскі, каб скроллбар не рухаўся вялікімі скачкамі.

Што дадае ключавая слова auto

Ключавая слова auto лёгка працягнуць, але яна мае вельмі важлівыя наследкі. З auto браузер, калі картка вже атрыбутавана, фіксуеяе ўсё ейнае рэальнае размер. Якщо пазней картка выйдзе за межы відобразэння і зноў будзе прахоўвана, браузер вжывае гэты запамятаванный размер у замен на вашу апрыску. Без auto кожная картка ўсё часы вяртаецца да фіксаванай апрыскі, калі выходзіць за межы відобразэння.

Карточкі на экране завжы паказваюцца ў сваёй справжней вышыні незалежна ад таго, як ўстановленае настройка. Разлік прымаеся ў випадку контэнту з мянючайся вышынай: дужо дзьвігучая назва товару, якая розтягваецца на дадатковыя рядкі, або значак зніжкі, який дае ўтварыцца новаму рядку. Без параметра auto карточкі вяртаюцца да пачатковай вышыні, калі вони выходзяць за межы вікна перагляду, і пазицыя прасування рывком зменшаецца. Заўжды вярніся да параметра auto.

Падтрымка браузераў і поступова павышэння якосці

Падтрымка больш не ўскладнена толькі Chrome. Chrome падтрымлеў параметр content-visibility з версіі 85 (2020 г.), Firefox — з версіі 125, а Safari — з версіі 18. На момент напісання яго статус адзначаецца як «Baseline Newly Available», які быў досягнут 15 сябрня 2025 г., тое значыць, ён працуе ў всіх трох ведучых двойчыках браузераў; пераканайцеся ў актуальных данных пра сумеснастае, якщо вы падтрымляеце старэйшыя версіі.

Браузеры, які не розумеюць гэтага, проста ігнаруяйу яго і адрадзіваюць усё так, як завжды. Чырвоныя гэта прагрэсіўная падтрымка, якая не мае негатыўных наследкав для старэйшых кліентаў.

Як гэта з’яўляецца у зв’язку з Core Web Vitals і SEO

Мотывацыяю ў гэтым случае являецца выдатнасць, але сторанкі кацэгарыяў — гэта саме тыя URL-адрэсы, якія команды пошуку старанна стежаць. Яны ўжывачам доступныя, нацэленыя на цінныя запыткі, і Google мерыць яхую выдатнасць для рэальных ўжывачоў.

Распаложэнне элементаў і процес адрадзівання вплываюць на два з трох Core Web Vitals, якія Google выкарыстоўвае як сигналы для ранжавання:

• Interaction to Next Paint (INP) паслядзіць прычынны эфект. Айханае адрадзівання элементаў, якія знаходзяцца за межама экрана, звалняе главную вясь, таму нажаткі і клікі отрымаюць адпаведзь быстрей.

Largest Contentful Paint (LCP) дае парадоксальныя выгоды. На дужо дзёльных сторанках меншыя падрыхтаванні пры першай адразе вываркі змагчыраюць ранейшая паўтарэнне большога візуальнага кантэнту.

Большасць сторанак, неякія не ўжо камерчыя, маюць такую структуру — ад дакументацыі і новынных стрэймоў да архіваў пасляў блога, дзёльных тэм для дыскусій і статэй з калькама разделаў. Як толькі многі падобныя элементы размешчаюцца верткалі і большасць з іх спачатку за межама экрана, а сторанка є публічная, гэтыя змены вплываюць на паказнікі, якія выкарыстоўвае Google.

Будзьце абережны, калі обяцваеце пакращэння рангавання. Адзін сайт, які спостерагалі каля калькоў недзеяў, мало чаго дазваляе сказаць, а рангаванне залежыць ад значна большай колькіцтва паказнікаў. Тое, чаго можна разумна спадзявацца, — гэта рух у правым напрамку ў даных практычных выкарыстоўвачаў, напрыклад у PageSpeed Insights, калі назбіраецца достатня колькасць прыкладаў рэальных корыстувачаў.

Прыцёк не аб’являецца толькі для публічных сторанак. Дашборды, табелі адміністрацыі і внутрашнія інструменты таксама страждаюць ад той самай вартасі адрасавання 600 рядоў. За моментам заходу ў систему немае прыцёку з пошукам, але практычнасць для пользователя застаёцца тая ж, завдакоў таго самага CSS.

Чы розгляджэнне адрасавання магчымая сховаць контэнт ад краўлероў?

Гэта першы вопыт, які задае адпаведальны спецыяліст з SEO, і ён ўсуперш цэлеспрабны, ведаючы, сколькі схем ленівага адрасавання робяць контэнт невізыбельным для ботаў. Ключовая разліка заключаецца ў тым, што content-visibility: auto — это оптымаўзація адрасавання, а не змена візыбельнасці. Контэнт існуе ў HTML і ў DOM з моменту завантажэння сторанакі; толькі ўпорядкуванне і адрасаванне адкладаюцца пакуль элемент не падыходзіць да вікна перагляду.

Googlebot не праскаецца так, як чалавек. У замене ён выкарыстоўвае надзвычайна вялікую паверхню адображэння для обробкі і пасля гэтага аналізуе створаны DOM. Карточкі, якія праўільна ўтварыліся, але былі праўяжаны, ёсць часткай гэтага DOM, таму кожны заглавле і цена товара індексуюцца як і будзь-яны іншы контэнт.

Паўстаноўцем гэтага ёсць старыя падходы, калі контэнт дадаваўся толькі пасля выйска змагання праскаецца. Працоўнікі-пералітчыкі не ствараюць такіх змаганняў, таму такі контэнт сапраўды могаў не быць у індексе. content-visibility не можа спрычыніць гэтую проблему, таму што нічога пазней не дадаецца; усё ўжо є з самага пачатку.

Адзін застерэжны момент не стосуецца самай власнасці. Якщо сторанка формуе свой контэнт за дапамою JavaScript на боку кліента, тады вы сталкнуліся з адзіным SEO-праблемам. Googlebot дэйсна выкананяе JavaScript, але його адражэнне відбываецца па черзі, што робіць процес повольней і менш надзеяным, а багатыя іншыія краулеры паслаба справляюцца з JavaScript. Для публічнага контэнта неабяжна адражаць HTML на сервере і дадаць content-visibility у CSS. Такая комбінацыя дапамагае стварыць контэнт, які можна краулаваць, і паспрабоўвае пакращыць яго показнікі.

Порэшанне з абмежаннем прокручвання, віртуалізацыяй і спецыяльнымі абсервэрамі

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

Завантажэнне пад час прокручвання і API з пагінацыяй

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

Это мае своія выкладкі. Патрэбны змены ў API, станы завантажэння, аб’екты для слежэння за рухам паверхні сторанкі і фіксацыя стану таго, што вже было завантажана. Таксама змінюецца і корыстная працэсная можлівасць: функцыя пошуку ў сторанцы не можа знайсці элементы, якія ўжо не завантажыліся, а дабыранне до канца спіса стае клопачлівым. На сторанцы публічнай катэгорыяй існуе дадатковая навантажэння для SEO, адколі продукты, якія паказуюцца толькі пасля прасування, недоступны для скрабероў; патрэбны URL-адрысы з паградуваннем і дадатковыя маркапы, каб яны заставаліся доступнымі для індексавання. Для 600 картак, якія вже ў HTML, гэта значыць неабходна перапісваўка коду плюс новая работа з SEO, каб выправіць проблему, якая на самай суты ёсць проблемай адрасавання.

Бібліятэкі віртуалізацыі

Віртуалізацыя, за дапамою бібліятэкаў такіх як react-window або TanStack Virtual, зберагае весь набор дадзеных у памяці, а элементы DOM, якія знаходзяцца за межамі видныя часткі сторанкі, выключаецца. Гэта працюе, і при дужа вялікіх масштабах гэта лепшы варыянт, як будзе паспелаць нижэй.

Цена включае адзінктуванне з JavaScript, перапісваў компонентаў і ўскладненую обработку рядоў з мянючыся вышынай. Паколькі выдаленыя элементы ўзагалі не знаходзяцца ў DOM, функцыя find-in-page не можа іх пазначыць, прыстроі для чытання экрана маюць з тым проблемы, а кроулеры на публічных сторунках іх працягваюць праігнораваць.

Падход з вяршынай IntersectionObserver

Автаматычная візуалізацыя элементаў, калі IntersectionObserver адмаўляе іх як видныя, значыць перзбудаваць у JavaScript для главнай вясі выканання тое, што вже робіць content-visibility: auto, і зноў ствараць проблемы з фіксацыяй пад час скроллінгу, якія браузер вже рашыў у сваёй стандартной реалізацыі. Сьогодні няма значных прычын пісаць такі код.

Выбор межы гэтымі падходамі

Праўdziва прычына викорыстання content-visibility не ў тым, што ён перамагае этыя методы, а ў тым, што ён значна дешавей. Це простая CSS-аспект: без JavaScript, без змян у API, без перапісву коду, і контэнт застаецца ў DOM для пошуку, асистуючых тэхналагій і функцыяў пошуку ў сторанцы.

Неабходна чыста адзначыць компрэсію. content-visibility эканоміць ресурсы на адрасаванні, а не памяць. Кожны вузел DOM застаецца. Пры 600 карточках гэта майже незначна. Пры 50 000 або 100 000 элементах размер DOM стае самастоятельной проблемай, і тады вяртуалізацыя становіцца неабходнаю. Перш чым выбраць інструмент, з’ясавіце, якая з двух проблем у вас є: вартасць адрасавання чы размер DOM.

Дзе ён працюе і дзе таятна паслабляе функцыянаванне

Гэты аспект не падходзіць для викорыстання всюды. Ён найэфектывнейшы там, дзе адна і тая ж структура павтараецца часта, напрыклад:

• карточкі ў каталозе чы спісе

Пасткі в соцыяльных сетях або ленты новасцей

Ряды большой табліцы дадзейнаў

Адпаведзі пад статэйкай

Разделы длугой сторонікі дакументаў

Элементы на стороніцы рэзультатаў

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

Апылкі некантрольванага кантэнту дае некоректныя цыфры

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

const height = row
  .querySelector('.details')
  .getBoundingClientRect()
  .height;

Зьважэнне внутрошняй зместу элемента, які быў прыхованы, за дапамою getBoundingClientRect() пры тым, калі ён яшчэ не быў адрасаваны, дае нуль або іншыя некоректныя значэння. Сама рамка элемента паказвае размеры месца для замены, вылічаныя за дапамою contain-intrinsic-size, якія таксама можа не паспрацаваць з рэальнасцю. Такі код часта викорыстоўваецца ў рэальных інтерфейсах, напрыклад, калі вы:

• распаўшчатываете падказку пры элементе-тригеры
• вылічаеце значэння пачатку і канца анімазіі
• выбіраеце месца, дзе будзе адкрывацца меню
• назначаеце розмеры рядоў у віртуальным списку
• реалізуеце логіку фіксаванага розташоўвання
• выравнаваеце адны компоненты з іншымі

Якщо до таго, калі змест стане видным, важна точная геаметрыя, неабходна рэшыткава перапрацаваць код пры ўведэнні гэтай власнасці.

Іншыя паслядні варыянты

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

Два менш вядомыя деталі

Скрытая значэння

content-visibility: hidden не адраптава элемент, падобна display: none, але прыгарнік зберагае стан адраптавання элемента. Праявіць яго зноў значна дашчэй, чым прадстаўіць элемент з display: none, таму што не трэба перадзелваць всю роботу з нуля. Гэта робіць яго корыстным для вкладак, меню за межама екрана і віртуальных скролероў. Няпадобна auto, контэнт, які знаходзіцца пад hidden, не ўможлівы да адчування за дапамогою функцыі find-in-page, калі ён захаваны.

Реакцыя на змены стану

Калі элемент, які выкарыстоўвае content-visibility: auto, пераходзіць з стану «прыгнуты» у стан «адраптаваны», прыгарнік выпускае запуск contentvisibilityautostatechange здарэння. Адслухоўваючы яго, можна призначыць паузу для дорогіх скрыптаванняў, такіх як адрасаванне на canvas, для контэнту, які прыгарнік у будзь-якім случае не адраптавае.

Перакананне ў адпаведнасці на вашых сабе сторунках

Адзін быстры эксперымент паказвае розныцю. Створыце тэстовую старонку з прыблызу 1 000 картак і пераключальнікам, які дадзеяў або зніме content-visibility: auto. Ачыніце DevTools, перайдзіце на панель Performance, запісаце процес перазавантажэння без увыклёвага пераключальніка, пасля запісаце з яго увыклёвам, і парабяруйце фіолетавыя блокі Layout у двух записах.

Пасля застосавыце той жа аптэкст да вашай дазволенай па габаратах старонки. Запісаце етапы ўстановкі старонкі. Калі частка Layout домінуе, а інтерактыўнасць прыходзіце пазней, дадзенне content-visibility: auto да павтараючыхся элементаў часта ёсць найякшым і простым спосабам падборкі: адна настройка, без перапісву коду, без пераходу на іншую фрэймворк-сістэму.

Галоўныя выводы

• Браузеры адмініструюць стыль і макет для всіго документа; content-visibility: auto дозволяе ім відкласты гэту роботу для элементаў, якія знаходзяцца далека ад вікна перегляду, не выкарыстоўваючы при гэму нічога з DOM.
• Заўжды выкорыстоўвайце яго разам з contain-intrinsic-size: auto <estimate> у той жа змяне, іначы скроллбар будзе рухацца неспакойна.
• Контэнт застаецца можлівым для індексавання, пошуку та доступу, што відрóżнае яго ад методаў завантажэння пад час прасування та віртуалізацыі.
• Гэта захоўвае час адрасавання, а не памяць; калі сам DOM стае занадта великім, правым рашэнням є віртуалізацыя.
• Утрымайцеся ад яго выкорыстоўвання над главным фрагментам контэнта, на элементах, геометрыя якіх вимерваецца перад адображэнням, а таксама на компонентах, якія адрасаваюць тэкст за межамі свайго контейнера.