Для чего нужен JavaScript: объяснение для владельца сайта и маркетолога

Что такое JavaScript

JavaScript нужен, чтобы страница реагировала на действия человека. Справочник MDN описывает его как третий слой слоёного пирога стандартных веб-технологий: HTML размечает структуру, CSS задаёт оформление, а JavaScript позволяет создавать динамически обновляемый контент, управлять мультимедиа и анимировать изображения. Если на странице что-то происходит без перезагрузки, за этим стоит скрипт.

Масштаб использования огромен. По данным W3Techs, клиентский JavaScript работает на 98,9% сайтов из их выборки. Поэтому вопрос владельца звучит иначе: сколько скриптов загружает каждая страница и что именно они делают с точки зрения скорости, поиска и заявок.

Язык родился в спешке. По материалу Википедии, Брендан Эйх реализовал первую версию в компании Netscape за десять дней, и тогда она называлась Mocha. Позже язык переименовали, а имя JavaScript появилось потому, что Java в то время было модным словом. Общего у двух языков мало: тот же материал упоминает и стандарт ECMAScript, по которому сегодня описывают язык.

Сегодня область применения шире браузера. Практикум перечисляет расширения для браузера, небольшие мобильные интерфейсы, серверную часть и простые игры. Для маркетолога это означает, что один специалист по JavaScript часто закрывает сразу несколько задач проекта: от формы на лендинге до внутреннего сервиса отчётов.

Эта история объясняет две привычные путаницы. Название вводит в заблуждение, и Java с JavaScript часто путают, хотя это разные инструменты для разных задач. Вторая путаница касается стандарта: когда разработчик говорит про версию ECMAScript, он имеет в виду набор возможностей языка, которые должен поддерживать браузер.

Как JavaScript работает на странице

Сервер отдаёт браузеру HTML, CSS и файлы скриптов, а дальше всё происходит на устройстве посетителя. По описанию MDN, код выполняет движок браузера уже после того, как обработаны HTML и CSS и сформирована страница. Поэтому скрипт может менять готовую страницу: показывать блок, подставлять данные, менять текст кнопки.

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

Браузер строго ограничивает скрипты. Как пишет Практикум в том же материале, в браузере JavaScript работает с камерой и микрофоном только с разрешения пользователя, и данные других сайтов получает лишь с согласия их владельца. MDN добавляет, что каждая вкладка выполняет код в отдельной среде и код одной вкладки не влияет напрямую на код другой. Для посетителя это защита, для разработчика ограничение, которое надо учитывать при интеграциях.

Ещё одна особенность языка касается типов данных. В том же материале Практикума типизация названа динамической: в переменную можно положить что угодно. Это ускоряет разработку, но допускает ошибки, поэтому формы и калькуляторы нужно тестировать руками. Для строгости разработчики подключают надстройки вроде TypeScript, которые делают код чище.

Тот же язык используют и на сервере: для этого нужен движок Node.js, как отмечает Практикум. Одна и та же команда разработчиков способна писать и интерфейс, и серверную часть, что удешевляет небольшие проекты.

Какие задачи JavaScript решает на коммерческой странице?

Скрипты закрывают задачи, которые видит и посетитель, и владелец. Типичный набор для коммерческой страницы выглядит так:

• Формы заявок: проверка полей до отправки, маска телефона, подсказки адреса.
• Калькуляторы и подборщики: расчёт стоимости без перезагрузки и перехода на другую страницу.
• Подгрузка контента: каталог, отзывы, фильтры, пока человек листает страницу.
• Интерактив интерфейса: меню, вкладки, слайдеры, всплывающие окна.
• Интеграции: чаты, счётчики аналитики, виджеты записи и оплаты.

Хороший пример даёт форма входа. В разборе Kokoc описана проверка почты: при неверном формате ошибка появляется сразу, и это делает скрипт в браузере. Такая клиентская проверка экономит ресурсы сервера и ускоряет ответ человеку. Серверная проверка при этом остаётся обязательной, потому что скрипт в браузере можно обойти.

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

Как JavaScript влияет на скорость страницы?

Браузер выполняет большую часть скриптов в одном потоке, и пока идёт тяжёлая задача, страница не отвечает на клики. Авторы web.dev называют длительной любую задачу дольше 50 миллисекунд и напоминают: когда таких задач много, интерфейс кажется неотзывчивым.

Основной поток может обрабатывать только одну задачу за раз.

Джереми Вагнер и Брендан Кенни, авторы материала на web.dev

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

Практическое следствие понятно: скрипты чата, виджета отзывов, аналитики и баннера конкурируют с кнопкой «Заказать» за один поток. Откройте отчёт PageSpeed Insights, найдите сторонние скрипты, которые занимают больше всего времени, и отключите те, что не приносят заявок.

Redbus показал, что чистка скриптов окупается. В исследовании web.dev команда убрала неоптимизированные скрипты вставки тегов, и это улучшило CLS. Оптимизация сторонних скриптов сократила время до интерактивности с 8 до 4 секунд, а общее время блокировки с 1200 до 700 миллисекунд. Мобильная конверсия по всему миру выросла на 80-100 процентов.

Vodafone в Италии пошла по другому пути. В том же материале web.dev сказано, что компания улучшила LCP на 31% и получила рост продаж на 8%: сервер отдавал критический HTML готовым, а скрипты меньше блокировали отрисовку. Там же есть совет для экспериментов: A/B-тест стоит проводить на стороне сервера, чтобы скрипты тестирования не вносили затрат в рендеринг.

Видят ли поисковики контент, который строит JavaScript?

Видят, но не всегда сразу и не всё. По документации Google, робот Googlebot обрабатывает такие приложения в три этапа: сканирование, отрисовка и индексирование. Страница может задержаться в очереди на отрисовку на несколько секунд, а в некоторых случаях дольше. Поэтому Google рекомендует по возможности использовать серверную или предварительную отрисовку, и отмечает, что не все роботы выполняют JavaScript.

Из этого вытекают правила для разработчика. Ссылки, по которым робот должен пройти, пишите обычным атрибутом href: именно в нём Googlebot находит новые адреса, а кнопка с обработчиком клика вместо ссылки остаётся тупиком. Канонический адрес задавайте в HTML, как советует тот же документ, и не подменяйте его скриптом. Заголовок и описание страницы тоже стоит отдавать в исходном HTML.

У Яндекса есть отдельная настройка. В справке Вебмастера сказано, что по умолчанию включена опция «На усмотрение робота Яндекса», а при серверной отрисовке или пререндеринге рендеринг советуют запретить. Там же предупреждают, что выполнение JavaScript может создавать дополнительную нагрузку на ваш сервер.

Показательный случай описало агентство Kokoc.com в кейсе онлайн-школы. Проект выглядел здоровым, но Вебмастер показывал дубли метатегов, хотя в коде они были уникальными, а внутренние ссылки не сканировались. Причину нашли, сравнив код в панели разработчика и в просмотре кода страницы: контент достраивался в браузере. Разработчики клиента перенесли рендеринг на сервер за две итерации. Агентство сообщает, что число запросов в топ-10 Google выросло в 14,5 раза, а трафик за год в 2,28 раза.

Проверить свой проект можно за пять минут. Откройте страницу, посмотрите её исходный код и найдите в нём главный заголовок и текст. Если их там нет и они появляются только после загрузки, обсудите с разработчиком серверную отрисовку, о которой подробнее написано в разборе про рендеринг и SSR.

Какие ошибки с JavaScript чаще всего стоят заявок?

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

• Контент только в скрипте. Заголовки и тексты появляются после загрузки, и робот, который не выполняет скрипты, видит пустую оболочку.
• Кнопки вместо ссылок. Навигация без атрибута href не даёт роботу найти страницы.
• Тяжёлые сторонние виджеты. Каждый чат и баннер добавляет длинные задачи в основной поток.
• Файлы скриптов без отпечатка в имени. Google рекомендует включать цифровой отпечаток содержимого в название файла, например main.2bb85551.js, чтобы робот не брал устаревшую версию из кэша.
• Тяжёлые изображения без отложенной загрузки. Google советует применять её, чтобы графика скачивалась, только если пользователь должен её увидеть.

Базовая разметка остаётся основой, а скрипты её дополняют. Прежде чем что-то решать скриптом, проверьте, нельзя ли обойтись обычными тегами HTML и стилями: это быстрее и надёжнее для поиска.

Хороший пример с рекламой привёл тот же web.dev. Проект iCook улучшил CLS на 15% и получил рост дохода от рекламы на 10%. Для этого команда зафиксировала размеры рекламных мест и изменила логику загрузки рекламного скрипта: приоритет получили ставки, а некритический JavaScript отложили. Авторы материала отмечают, что заполняемость при этом может снизиться, но доход растёт за счёт более заметной рекламы.

Что проверить владельцу сайта вместе с разработчиком

Писать код самому необязательно, но задавать правильные вопросы стоит уметь. Короткий чек-лист для разговора с разработчиками или подрядчиком, который поддерживает проект:

1. Сравните исходный код страницы с тем, что видно в браузере, и убедитесь, что заголовок и основной текст есть в исходном коде.
2. Прогоните страницы через PageSpeed Insights и выпишите три самых тяжёлых скрипта.
3. Проверьте в Яндекс Вебмастере настройку рендеринга страниц JavaScript и решите, нужна ли она при серверной отрисовке.
4. Убедитесь, что все важные переходы сделаны ссылками с href, а не кнопками.
5. Внесите в таблицу все сторонние скрипты с владельцем и целью каждого.

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

Такой подход экономит бюджет. Разработчик получает конкретные задачи с проверяемым результатом, а владелец видит, как каждая правка отражается на скорости и видимости в поиске. Повторяйте проверку после каждого крупного релиза, потому что новые скрипты появляются незаметно.

Частые вопросы