Виджет на сайте: что это и что проверить до запуска

Коротко: виджет на сайте в этой статье - блок чужого сервиса внутри вашей страницы: карта, видеоплеер, чат, обратный звонок, отзывы, оплата, капча. web.dev называет такой блок third-party embed (встраиваемое стороннее содержимое). В страницу он попадает тегом iframe или тегом script. web.dev пишет, что такие блоки могут влиять на скорость страницы, и называет приёмы загрузки. Заказчику остаётся решить, какие виджеты нужны, и спросить подрядчика, как подключён каждый.

Ниже: что такое виджет, чем различаются iframe и script, что web.dev и MDN пишут о цене виджета для страницы, какие приёмы загрузки названы и что MDN говорит о cookie от встроенного содержимого. В конце - решения для шага разработки, вопросы подрядчику и проверки перед запуском.

Страницы источников открыты 06.10.2026. web.dev, MDN (iframe, сторонние cookie, проверка целостности) и Chrome for Developers написаны на английском: цитаты даны в оригинале с переводом, перевод наш. Страница MDN о script - на русском, с пометкой о переводе сообществом. На страницах web.dev о сторонних блоках стоят пометки Last updated 2019 и 2021 года. Поэтому цифры ниже даны с годом страницы.

Статья не обзор сервисов-виджетов: цен, установки конкретного чата или мессенджера и сбора заявок в ней нет. Поставщики названы там, где их называют источники: Яндекс Карты, YouTube и Google Maps. Пример вымышленный: веломастерская с сайтом example.ru.

Что такое виджет на сайте?

Коротко: определения слова виджет в источниках статьи нет, поэтому в статье оно значит блок чужого сервиса внутри вашей страницы. web.dev описывает такое содержимое двумя признаками: написано не вами и отдаётся с серверов третьей стороны. Для блока страница использует термин third-party embed, для скрипта - third-party JavaScript.

Виджет в этой статье - блок чужого сервиса, показанный внутри вашей страницы. Карта организации, видеоплеер, окно чата, форма обратного звонка, лента отзывов, платёжная форма и капча выглядят как часть страницы. Код блока написан поставщиком сервиса. Это определение - сводка автора статьи: ни одна из страниц-источников его не даёт. Слово widget на них встречается без определения («chat widgets», «social media widgets», «sign-in widget»), а Яндекс называет виджетами свои инструменты: Виджет Яндекс Карт и Виджет отзывов.

Что вставлено в страницу со стороны, web.dev описывает через два признака. Страница о встраиваемом содержимом называет third-party embed любым содержимым вашего сайта, которое «Not authored by you» (перевод наш: написано не вами) и «Served from third-party servers» (перевод наш: отдаётся с серверов третьей стороны). Примеры там же:

«The most common examples of third-party content embeds are video players, social-media feeds, maps, and advertisements.» Перевод наш: самые распространённые примеры встраиваемого стороннего содержимого - видеоплееры, ленты соцсетей, карты и реклама.

• web.dev, Best practices for using third-party embeds | Articles | web.dev, страница 2021-10-05

Другая страница web.dev, о сторонних скриптах (2019-08-13), даёт то же определение для скрипта и перечисляет, для чего сайты их подключают: кнопки публикации в соцсетях, видеоплееры, чаты, рекламные iframe, аналитика, A/B-тесты, вспомогательные библиотеки. Для вашей страницы из списка важны блоки, которые видит посетитель. Аналитика и A/B-тесты здесь не разбираются. Страница добавляет оценку: сторонние скрипты дают возможности, но «They also affect privacy, security, and page behavior» (перевод наш: они также влияют на приватность, безопасность и поведение страницы).

Для заказчика из определения следует одно: у блока есть автор и сервер вне вашего сайта. Что с этим делать, зависит от способа встраивания.

Как виджет встраивается: через iframe или script?

Коротко: сервис выдаёт код для вставки, и это либо тег iframe, либо тег script. MDN: iframe встраивает в текущую страницу другой документ, script подключает исполняемый код JavaScript. web.dev пишет, что встраиваемое содержимое «typically» грузят через iframe, а часть поставщиков даёт script, который сам вставляет iframe. В таблице Яндекса способ назван для каждого инструмента.

Код для вставки - несколько строк, которые сервис показывает владельцу сайта. Яндекс пишет, что «код для вставки на сайт» получают по клику на кнопку «Поделиться» (страница о Виджете Яндекс Карт). Подрядчик помещает код в нужное место страницы.

iframe. Это рамка: внутри вашей страницы показан отдельный документ поставщика. MDN определяет элемент так:

«The <iframe> HTML element represents a nested browsing context, embedding another document into the current one.» Перевод наш: элемент iframe представляет вложенный контекст просмотра: он встраивает в текущий документ другой документ.

• MDN, 0 HTML inline frame element - HTML | MDN, страница изменена 1 октября 2026

Вид кода - одна строка с адресом документа поставщика и размерами (адрес вымышленный):

<iframe src="https://example.com/map" width="600" height="400"></iframe>

Рамка отделена от страницы. По MDN, скрипты из другого источника не могут обращаться к «most properties» (перевод наш: большинству свойств) родительского окна: это правило одного источника (same-origin policy).

script. Это строка, которая подключает на страницу программу поставщика. MDN на русском пишет о теге так:

«HTML-элемент <script> используется для встраивания или подключения исполняемого JavaScript кода.»

• MDN, 0: элемент для написания скриптов - HTML | MDN, страница изменена 15 апреля 2025; пометка о переводе сообществом

Вид кода - одна строка с адресом файла поставщика (адрес вымышленный):

<script src="https://example.com/widget.js"></script>

Что программа делает дальше, определяет поставщик. web.dev пишет, что некоторые поставщики дают script, который сам вставляет iframe: «a script snippet that dynamically injects an <iframe>» (перевод наш: фрагмент script, который динамически вставляет iframe). В целом о блоках страница пишет, что они «typically» (перевод наш: в типичном случае) загружаются в элементах iframe. Доли страница не называет.

Яндекс называет способ встраивания у каждого из четырёх своих инструментов для карты и отзывов. Строка таблицы «Технология добавления на сайт» на странице «Карты и геоссылки без программирования»:

Источник таблицы - Яндекс, Карты и геоссылки без программирования - API Яндекс Карт, страница открыта 06.10.2026. Различия внутри карты разобраны в статье Яндекс Карта на сайт: какие есть способы и что проверить заказчику, в разделе «Как вставить карту на сайт: script или iframe?».

Что страницы MDN и web.dev говорят о двух способах, собрано в таблице. В каждой ячейке указана страница.

Чем виджет нагружает страницу?

Коротко: web.dev пишет, что стороннее содержимое влияет на страницу несколькими способами: может блокировать отрисовку, делить с важными ресурсами сеть и пропускную способность, менять показатели Core Web Vitals и сдвигать содержимое при загрузке. MDN предупреждает, что каждый iframe требует памяти и ресурсов. Цифры web.dev даны с годом страницы: 2019 и 2021.

Главный источник - страница web.dev о встраиваемом содержимом, обновлённая 5 октября 2021 года. Она описывает влияние так:

«Third-party content can impact the performance of a page in many ways. It can be render-blocking, contend with other critical resources for network and bandwidth, or affect the Core Web Vitals metrics. Third-party embeds may also cause layout shifts as they load.» Перевод наш: стороннее содержимое может влиять на производительность страницы многими способами. Оно может блокировать отрисовку, спорить с другими важными ресурсами за сеть и пропускную способность или влиять на показатели Core Web Vitals. Встраиваемые сторонние блоки могут также вызывать сдвиги макета при загрузке.

• web.dev, Best practices for using third-party embeds | Articles | web.dev, страница 2021-10-05

Core Web Vitals - название группы показателей, которое использует страница; здесь они не разбираются. Сдвиг макета (layout shift) страница объясняет как «unexpected movement of page content» (перевод наш: неожиданное движение содержимого страницы): текст или кнопка смещаются, когда блок догружается.

Для скрипта страница web.dev о сторонних скриптах (2019) перечисляет, чем такие скрипты, по её словам, «often» (перевод наш: часто) нагружают сеть: дополнительными запросами, неоптимизированными изображениями и видео, несколькими копиями библиотек, которые подтягивают разные встроенные блоки.

Для iframe нагрузку описывает MDN. Каждый контекст просмотра - «a complete document environment» (перевод наш: полноценная среда документа), поэтому каждый iframe на странице требует больше памяти и других вычислительных ресурсов. Теоретически iframe можно ставить сколько угодно, но MDN советует: «check for performance problems» (перевод наш: проверяйте, нет ли проблем с производительностью).

Три цифры из web.dev. В таблице они даны дословно, с годом страницы.

Слова many и sometimes в первой цитате принадлежат странице: доли блоков она не называет. Цифры стоят на страницах с пометками Last updated 2019 и 2021 года. Когда и на каком наборе блоков и устройств они получены, страницы не сообщают. Для вашего сайта они не заменяют замера. Сколько секунд или килобайт добавляет конкретный виджет, источники не называют.

Что будет, если сервис виджета не отвечает?

Коротко: web.dev пишет о синхронной загрузке стороннего скрипта в критическом пути отрисовки: она задерживает разбор остальной страницы, а при сбое у поставщика отрисовка блокируется до истечения времени ожидания, которое по странице 2019 года может составлять от 10 до 80 секунд. MDN: скрипт без атрибутов async, defer и type="module" выполняется до продолжения разбора страницы.

Сбой чужого сервера затрагивает вашу страницу, если блок загружается определённым способом. Страница web.dev 2019 года о сторонних скриптах описывает условие: загрузка синхронно, в критическом пути отрисовки, задерживает разбор остальной части документа. Критический путь отрисовки страница объясняет так: «all resources that the browser needs to display the first screen's worth of content» (перевод наш: все ресурсы, которые нужны браузеру, чтобы показать содержимое первого экрана). Следом идёт сбой поставщика.

«If a third party has server issues and fails to deliver a resource, rendering is blocked until the request times out, which can be anywhere from 10 to 80 seconds.» Перевод наш: если у третьей стороны проблемы с сервером и она не отдаёт ресурс, отрисовка блокируется до истечения времени ожидания запроса, которое может составлять от 10 до 80 секунд.

• web.dev, Third-party JavaScript performance | Articles | web.dev, страница 2019-08-13

Условие цитаты - синхронная загрузка. На русскоязычной странице MDN про такой скрипт сказано: элемент script без атрибутов async, defer или type="module" «загружается и выполняется сразу, до того как браузер продолжит разбор документа». Для скриптов с async и defer web.dev описывает другое поведение, оно разобрано в разделе «Какие приёмы загрузки называет web.dev?». Вопрос подрядчику отсюда один: как подключён скрипт виджета и что увидит посетитель, если сервис поставщика не ответит.

Какие приёмы загрузки называет web.dev?

Коротко: web.dev называет приёмы от отказа от блока до периодического пересмотра: async или defer для script, loading для iframe, заглушку с загрузкой по клику, размеры, ссылку вместо блока. По оговорке web.dev, приёмы страницы лучше применять только к содержимому вне экрана или неосновному: так индексируется всё критически важное содержимое.

Страницы web.dev 2019 и 2021 годов называют несколько приёмов. В одну инструкцию они не складываются: подрядчик выбирает те, что подходят блоку.

• Убрать блок. Страница об эффективной загрузке (2019-08-14) начинает с двух вариантов для тормозящего стороннего скрипта. Первый - убрать скрипт, если он не добавляет сайту ясной пользы («Remove it»). Второй - оптимизировать загрузку.
• Не ставить два сервиса с одной функцией. Страница о сторонних скриптах (2019-08-13) советует не брать одну функцию у двух поставщиков и в пример приводит два менеджера тегов или две платформы аналитики.
• Поставить блок после основного содержимого. Страница 2021 года описывает хорошо продуманную страницу так: основное собственное содержимое в центре, сторонние блоки в боковых колонках или после него.
• Для script - async или defer. Страница 2021 года советует ставить теги сторонних скриптов после основных тегов страницы и использовать «async or defer». Различие описывает страница об эффективной загрузке: скрипт с async выполняется, как только скачан, и может прервать построение страницы, если скачался, пока разбор идёт; скрипт с defer выполняется после полного разбора. Для некритичного блока страница советует defer, например для видеоплеера ниже первого экрана. На русском MDN определяет defer так: «Это логический атрибут, указывающий браузеру, что скрипт должен выполняться после разбора документа, но до события DOMContentLoaded.»
• Для iframe - loading. Страница 2021 года советует отложить загрузку iframe вне экрана, пока пользователь не прокрутит страницу поближе: «browser-level lazy-loading» (перевод наш: ленивая загрузка на уровне браузера). MDN описывает значение lazy как отсрочку загрузки до расчётного расстояния от видимой области, которое определяет браузер.
• Заглушка и загрузка по клику. Заглушка (facade) - статичный элемент, похожий на настоящий блок, но нефункциональный и потому, по странице 2021 года, «much less taxing on the page load» (перевод наш: намного менее нагружающий загрузку страницы). По клику заглушку заменяет настоящий блок. Страница называет видеоплееры, чат-виджеты, сервисы входа и виджеты соцсетей.
• Статичная картинка вместо карты. Страница 2021 года допускает её там, где карта не обязана быть интерактивной.
• Ссылка вместо блока. Если блок мешает загрузке и приёмы не подходят, страница советует убрать блок целиком и дать ссылку на содержимое, которая откроется в другой вкладке.
• Размеры. Чтобы страница не сдвигалась, место под блок резервируют. Браузер вычисляет его по ширине и высоте элементов, и у iframe для этого задают атрибуты width и height. По странице, у популярных блоков, включая YouTube и Google Maps, код с размерами уже есть, а у некоторых поставщиков его может не быть.
• Пересматривать блоки. Страница 2021 года советует «periodically» (перевод наш: периодически) проверять влияние блоков и стороннего кода, потому что исходный код блока может меняться.

Оговорка web.dev об индексации относится к приёмам этой страницы. Во вступлении страницы 2021 года стоит такая запись:

«Note: It's best to use the techniques described in this post to load only offscreen or non-primary page content. This ensures that all the critical content gets indexed by search engines.» Перевод наш: примечание: лучше использовать приёмы из этой статьи только для содержимого вне экрана или неосновного содержимого страницы. Это обеспечивает индексацию всего критически важного содержимого поисковыми системами.

• web.dev, Best practices for using third-party embeds | Articles | web.dev, страница 2021-10-05

Что считать основным содержимым страницы, решаете вы вместе с подрядчиком: определения источник не даёт. Что отложенная загрузка или отказ от виджета сделают с позициями, трафиком или заявками, источники не говорят, и статья этого не обещает.

Что с cookie и данными посетителей?

Коротко: MDN пишет, что при встраивании компонентов других сайтов, например документов в iframe, сторонние cookie отправляются, а сами компоненты могут делать запросы, которые ставят ещё сторонние cookie. Какие cookie и данные у конкретного виджета, зависит от поставщика: источники этого не называют. Вопрос подрядчику - какие данные и куда передаёт виджет.

Что такое cookie, разобрано в статье Cookie на сайте: что это и нужно ли уведомление об использовании. MDN разделяет cookie по адресу. Если домен и схема совпадают с адресом страницы, это cookie первой стороны. Если различаются, cookie называется сторонней.

Страница MDN перечисляет ситуации, в которых сторонние cookie отправляются. Одна из них - встроенное содержимое.

«When a page embeds components from other sites, such as images or other documents embedded in <iframe>s (often referred to as third-party content). As well as the original request for the component, these components may generate further requests that set more third-party cookies.» Перевод наш: когда страница встраивает компоненты других сайтов, например изображения или другие документы в iframe (их нередко называют сторонним содержимым). Помимо исходного запроса за компонентом, эти компоненты могут порождать дальнейшие запросы, которые ставят ещё сторонние cookie.

• MDN, Third-party cookies - Privacy on the web | MDN, страница изменена 15 июня 2026

Это факт о механизме. Какие именно cookie ставит выбранный вами виджет и что поставщик делает с данными посетителей, MDN не описывает.

Что закон требует от cookie, согласия и хранения данных, здесь не пересказывается. Эти темы разобраны отдельно:

• Локализация персональных данных: что говорит закон о данных с сайта - куда уходят данные заявки в стороннем сервисе;
• Капча на сайте: что это, какой бывает и нужна ли она форме - виджет капчи;
• Как подключить оплату на сайт: что просят ЮKassa и Robokassa - платёжный виджет и ввод данных.

Что такое sandbox у iframe и integrity у script?

Коротко: у iframe есть атрибут sandbox, у script - атрибут integrity. По MDN, sandbox задаёт ограничения для встроенного содержимого, а integrity позволяет браузеру сверить скрипт с заданным хэшем. Подходят ли они конкретному виджету, на страницах MDN не сказано: это вопрос подрядчику.

sandbox. Атрибут ограничивает то, что может делать встроенное содержимое. MDN: «Controls the restrictions applied to the content embedded in the <iframe>.» Перевод наш: управляет ограничениями, применяемыми к содержимому, встроенному в iframe. Значение атрибута может быть пустым, и тогда применяются все ограничения, либо списком слов через пробел, которые снимают отдельные ограничения. Список слов и их действие - на странице MDN об iframe.

integrity. Атрибут описан на странице MDN о проверке целостности подресурса (Subresource Integrity, SRI). Это функция безопасности, которая позволяет браузерам убедиться, что загружаемые ресурсы, например с CDN, доставлены без неожиданных изменений. Если файл не совпадает с указанным хэшем, браузер, по странице, отказывается его загружать: «it will refuse to load the resource» (перевод наш: он откажется загружать ресурс). Подходит ли атрибут скрипту виджета, который поставщик обновляет сам, на странице не сказано. Подробности - на странице MDN.

Что решить заказчику на шаге «Разработка»?

Коротко: заказчик решает по каждому виджету: нужен ли он, нет ли второго с той же функцией, где он стоит, что показывать вместо него, пока он не загрузился, и какие данные он передаёт. Опора - советы web.dev и MDN из этой статьи.

На главной странице BITSPARK шаг «Разработка» описан словами: «Верстаем, программируем и подключаем сервисы. Технологии выбираем под задачу.» Виджет - сервис, подключаемый к странице, поэтому решения о нём удобно принять вместе с подрядчиком к моменту подключения. Список составлен автором по советам web.dev и MDN, названным в этой статье.

1. Нужен ли виджет. web.dev: убрать блок, если он не добавляет ясной пользы.
2. Нет ли второго виджета с той же функцией. web.dev: не использовать одну функцию от двух поставщиков.
3. Где на странице он стоит. web.dev: основное содержимое должно загружаться быстро и раньше вспомогательного, а сторонние блоки занимают боковые колонки или идут после него.
4. Что показывать вместо блока. web.dev: заглушку с загрузкой по клику, статичную картинку или ссылку.
5. Какие данные и куда передаёт виджет. MDN: компоненты других сайтов могут ставить сторонние cookie.
6. Кто и когда пересматривает подключённые блоки. web.dev: периодически проверять влияние блоков, потому что их код может меняться.

Сколько виджетов держать на странице, источники не называют. Страница web.dev завершается выводом: «as the number and size of embeds on a page increases, performance can suffer» (перевод наш: по мере роста числа и размера встроенных блоков на странице производительность может страдать). Страница советует «measure, judge, and use appropriate loading strategies» (перевод наш: измерять, оценивать и применять подходящие стратегии загрузки) с учётом положения блока, его значимости и потребностей пользователей.

Пример на вымышленном сайте example.ru: веломастерская планирует четыре блока.

Что спросить у подрядчика по каждому виджету?

Коротко: одиннадцать вопросов по страницам источников: зачем нужен блок, как подключён, где стоит, как загружается, что при сбое, какие данные уходят, есть ли title у iframe, сколько добавляет к загрузке и кто пересматривает. Способ замера выбирает подрядчик: просите показать результат замера с виджетом и без него.

Задавайте вопросы по каждому виджету отдельно.

1. Какую задачу решает виджет и есть ли на странице другой блок с той же функцией? (web.dev, 2019.)
2. Как он подключён: через iframe или script? (MDN; для инструментов Яндекса способ назван в таблице.)
3. Где на странице он стоит и грузится ли после основного содержимого? Есть ли у скрипта async или defer, у iframe - loading? (web.dev, 2021 и 2019.)
4. Можно ли показать заглушку, картинку или ссылку, пока посетитель не нажал? (web.dev, 2021.)
5. Заданы ли у iframe width и height и смещается ли страница при появлении блока? (web.dev, 2021.)
6. Что увидит посетитель, если сервис поставщика не ответит? (web.dev, 2019: при синхронной загрузке отрисовка может блокироваться на время ожидания, которое страница оценивает от 10 до 80 секунд.)
7. Какие данные и куда передаёт виджет, какие cookie ставит? (MDN, сторонние cookie.)
8. Есть ли у iframe атрибут title? MDN пишет, что люди с программой чтения с экрана могут по нему узнать, что внутри рамки. Без заголовка, по странице, им приходится заходить внутрь iframe: «they have to navigate into the <iframe>» (перевод наш: им приходится переходить внутрь iframe).
9. Применимы ли к этому виджету sandbox или integrity? (MDN, страницы об iframe и о проверке целостности.)
10. Сколько этот виджет добавляет к загрузке страницы и как это показано? Просите замер с виджетом и без него.
11. Кто и когда пересматривает подключённые блоки?

Способ замера описывает страница web.dev «Identify slow third-party JavaScript» (2019-08-14): измерить время загрузки страницы при включённом замедлении сети и процессора, заблокировать запросы подозрительных сторонних скриптов, загрузить страницу заново и сравнить. Страница добавляет, что не менее трёх прогонов и медиана значений, по её словам, вероятно, дадут более устойчивый результат. Пункты меню DevTools и названия аудитов Lighthouse здесь не приводятся: на страницах Chrome for Developers об аудитах стороннего кода (Last updated 2019-05-02) и заглушек (Last updated 2020-12-01) стоит предупреждение о Lighthouse 13. По нему первый аудит перенесён в другой пункт отчёта, второй удалён. Какой инструмент подрядчик применит сегодня, решает он.

Что проверить перед запуском?

Коротко: для виджетов проверка перед запуском сводится к шести действиям. Открыть страницу на компьютере и телефоне, убедиться, что основное содержимое видно раньше блока, что страница не сдвигается, что у iframe есть title, что заглушка и ссылка работают и что подрядчик дал замер с виджетом и без него.

На главной странице BITSPARK шаг «Запуск» описан так: «Проверяем desktop и mobile, скорость, формы и ключевые сценарии - затем запускаем.» Для виджетов проверку можно разложить на действия. Список составлен автором по источникам этой статьи.

1. Откройте страницу на компьютере и на телефоне. Каждый виджет виден, работает и помещается на экран. Как проверять страницу на экране телефона, описано в статье Адаптивный сайт: что это и как проверить адаптив до приёмки.
2. Перезагрузите страницу и посмотрите, что видно раньше. Основное содержимое должно быть видно до блока (web.dev, 2021).
3. Следите, не сдвигается ли текст или кнопка, когда блок догружается. Сдвиг макета - то, что web.dev называет layout shift.
4. Проверьте, что у каждого iframe есть title (MDN, раздел Accessibility).
5. Если вместо блока стоит заглушка, нажмите на неё: блок должен загрузиться. Если стоит ссылка, она должна открывать содержимое в другой вкладке.
6. Запросите у подрядчика ответы на вопросы из раздела «Что спросить у подрядчика по каждому виджету?», включая замер с виджетом и без него.

Источники

Страницы открыты 06.10.2026. Страницы web.dev, MDN (кроме страницы о script) и Chrome for Developers - на английском.

• Best practices for using third-party embeds | Articles | web.dev - определение third-party embed, приёмы загрузки, размеры, оговорка об индексации; Last updated 2021-10-05.
• Third-party JavaScript performance | Articles | web.dev - сторонний скрипт, блокировка отрисовки, 10-80 секунд; Last updated 2019-08-13.
• Efficiently load third-party JavaScript | Articles | web.dev - убрать или оптимизировать, async и defer; Last updated 2019-08-14.
• Identify slow third-party JavaScript | Articles | web.dev - принцип замера с блокировкой запросов; Last updated 2019-08-14.
• 0 HTML inline frame element - HTML | MDN - iframe, ресурсы, loading, sandbox, title; страница изменена 1 октября 2026.
• 0: элемент для написания скриптов - HTML | MDN - script, async, defer; на русском, перевод сообщества, страница изменена 15 апреля 2025.
• Third-party cookies - Privacy on the web | MDN - сторонние cookie от встроенного содержимого; страница изменена 15 июня 2026.
• Subresource Integrity - Security | MDN - атрибут integrity; страница изменена 14 апреля 2026.
• Карты и геоссылки без программирования - API Яндекс Карт - таблица «script или iframe», Виджет отзывов; на русском.
• Reduce the impact of third-party code | Lighthouse | Chrome for Developers - предупреждение о Lighthouse 13; Last updated 2019-05-02.
• Lazy load third-party resources with facades | Lighthouse | Chrome for Developers - предупреждение о Lighthouse 13; Last updated 2020-12-01.
• Яндекс Карта на сайт: какие есть способы и что проверить заказчику - карта.
• Cookie на сайте: что это и нужно ли уведомление об использовании - cookie.
• Локализация персональных данных: что говорит закон о данных с сайта - данные заявки.
• Капча на сайте: что это, какой бывает и нужна ли она форме - капча.
• Как подключить оплату на сайт: что просят ЮKassa и Robokassa - оплата.
• Адаптивный сайт: что это и как проверить адаптив до приёмки - экран телефона.
• BITSPARK - Digital studio - шаги «Разработка» и «Запуск».

Обсудить проект в Telegram: t.me/billioniks