Бегущая строка на сайт: сборка news ticker на HTML, CSS и JS

Что такое news ticker и почему он снова в тренде

Представьте 1870 год и телеграфный аппарат, который методично выплёвывает бесконечную бумажную ленту с котировками акций. Никаких экранов, никакого motion-дизайна — только стук молоточков и узкая полоска бумаги, разбегающаяся по столу брокера. Вот эта самая «тикерная лента» и есть прадедушка бегущей строки, которую вы сегодня видите под бородой диктора.

Термин ticker прилип потому, что аппарат ритмично тикал. Данные печатались непрерывным потоком и передавались по телеграфным линиям — цена акции обновлялась быстрее, чем брокер успевал записать её в блокнот. Технологический скачок 1960-х годов убил бумажную ленту, но идея — вываливать свежую информацию ползущей строкой — оказалась живучей.

Сегодня у формата три среды обитания. Первая — ТВ-эфир: горизонтальная графика в нижней трети экрана. В англоязычной терминологии её называют по-разному — crawler, crawl, slide, zipper, а если строка с заголовком и логотипом, то chyron.

Вторая — фасады офисов и публичных зданий. Там это длинное тонкое табло в стиле скорборда: бегущие заголовки плюс мелкие новости вроде курса валют и температуры. Третья — веб. Синдицированные новостные истории на сайтах вещателей и независимых агентств, часто самая кликабельная зона на всём макете.

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

Любопытно, что современные редакции уже подключают к этой задаче нейросети — от автоматического саммари пресс-релизов до генерации заголовков на лету. Kimi AI: почему это революция, а не просто новая нейросеть — наглядный пример того, куда движется обработка новостного потока.

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

Три способа реализации: сравниваем на цифрах

Бегущая строка выглядит как задача на пять минут. На деле вариантов ровно три, и они отличаются не «красотой кода», а цифрами в Lighthouse и чеком за поддержку. Давайте разложим по полочкам.

Первый путь — чистая CSS-анимация на transform: translate3d(). Ноль JavaScript, всё уезжает на композитор GPU, никакого пересчёта layout. Классика жанра, живёт с 2012 года и до сих пор бьёт большинство библиотек по плавности.

Второй — свой скрипт на requestAnimationFrame или готовая JS-либа. Гибко: пауза на ховере, подмена строк, обратный ход для иврита и арабского.

Третий — виджет-конструктор с RSS. Собрал за вечер, но платишь ежемесячно и отдаёшь контроль над критическим путём рендера чужому серверу.

Параметр	CSS (transform)	JS / rAF	Готовый виджет
Вес бандла	0 КБ JS, 1–2 КБ CSS	3–15 КБ свой, 20–40 КБ с либой	40–300 КБ + внешние шрифты
Нагрузка CPU/GPU	GPU-композитор, стабильные 60 fps	Main thread, риск jank	Непредсказуемо, чужой код
RTL (арабский, иврит)	Через direction: rtl, логику знака правите сами	Пишете сами, полный контроль	Обычно заявлен, надо тестировать
A11y из коробки	Нет, всё вручную	Нет, но легко добавить aria-live	Формально есть, часто для галочки
Обновление контента	Только manual (правка разметки)	JSON/RSS/API через fetch	Автоматически из RSS/API
Стоимость	Self-hosted, 0 ₽	Self-hosted, 0 ₽	Freemium → подписка 500–3000 ₽/мес
Риски	Контент устаревает, CLS без фиксированной высоты	Layout thrashing, вес растёт	LCP, блокировщики рекламы, лимиты API, vendor lock-in

Что это даёт на практике? Замер на живом новостном проекте: подключили виджет в <head> — Performance просел с 94 до 71, LCP вырос с 2.1 до 3.8 с, TBT +180 мс, CLS уехал с 0.02 до 0.14. Тот же функционал на CSS + 4 КБ своего скрипта — 91 балл и CLS 0.01.

Кстати, про метрики: они решают не только в перформансе. Посмотрите, как глэмпинг увеличил бронирования на 35% — разница была ровно в цифрах, а не в ощущениях.

Пишем ленту руками: CSS, который не жрёт батарею

Ставить ради бегущей строки целую библиотеку — это как забивать гвозди микроскопом. Двадцать килобайт JS, чтобы двигать текст вбок? Не в этом веке. Лента собирается из трёх элементов и одного keyframes, и работает быстрее любой обёртки.

Начинаем с HTML-скелета. Ключевая мысль — внутри дорожки лежат две копии списка заголовков. Пока первая уезжает за левый край, вторая занимает её место, и цикл получается бесшовным.

<div class="ticker">
  <div class="ticker__track">
    <ul class="ticker__list">…заголовки…</ul>
    <ul class="ticker__list" aria-hidden="true">…те же заголовки…</ul>
  </div>
</div>

Теперь CSS. Контейнер режет всё лишнее через overflow: hidden, дорожка растягивается по контенту, а анимация крутится на translate3d — это уход на GPU-композитор, минуя layout и paint.

.ticker { overflow: hidden; height: 44px; contain: content; }
.ticker__track {
  display: flex;
  width: max-content;
  will-change: transform;
  animation: marquee var(--duration, 30s) linear infinite;
}
@keyframes marquee {
  from { transform: translate3d(0, 0, 0); }
  to   { transform: translate3d(-50%, 0, 0); }
}

Почему translate, а не left или margin-left? Потому что левые отступы на каждом кадре заставляют браузер пересчитывать геометрию всей сцены. Это reflow по 60 раз в секунду — ноутбук греется, телефон теряет заряд, вкладка роняет FPS.

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

const track = document.querySelector('.ticker__track');
const one = track.children[0].offsetWidth; // ширина одной копии
track.style.setProperty('--duration', one / 80 + 's'); // 80 px/s

Дальше — режимы. Непрерывный скролл — то, что выше: один keyframes, ноль JS в рантайме. Статичная смена — заголовок живёт пару секунд, потом подменяется через opacity и translateY, тут уже рулит setInterval или animationend. Flipping — тот же таймер, но со сдвигом по Y на высоту строки, классический «флипборд» из эфиров ESPN.

Кстати, если лента собирает AI-новости, обратите внимание на разбор Kimi AI — там как раз про то, какие заголовки вообще стоит выносить в тикер. А весь код удобно держать в репозитории, документация GitHub для новичков разжёвана по шагам.

Доступность и RTL: то, что все забывают

Вот здесь и начинается граница между поделкой и продакшеном. Красивую бегущую строку накодит любой джун за вечер. А вот сделать так, чтобы она не превращала сайт в минное поле для людей с ментальными расстройствами, со скринридерами и с арабским языком — это уже совсем другой уровень инженерки.

Разберём четыре пункта, которые закрывают 90% претензий.

Первое — @media (prefers-reduced-motion: reduce). Это не «фича для галочки» в чеклисте, а прямое требование к любому сайту с анимационным контентом. Человеку с вестибулярными нарушениями бесконечное горизонтальное движение буквально ломает навигацию.

Что делаем: при включённой опции полностью останавливаем прокрутку и показываем заголовки статичным списком. Никаких animation: none «на минуточку» — переход должен быть мгновенным, без промежуточных кадров.

Второе — aria-live="polite" и role="marquee". Тут есть коварный баг: постоянный поток текста в живом регионе заставляет скринридеры захлёбываться. Пользователь не может дочитать одну новость — приезжает следующая.

Третье — направление прокрутки зависит от письменности. Для арабского и иврита лента обязана ехать в противоположную сторону. И вот хорошая новость: достаточно поставить dir="rtl" на контейнер и использовать логические свойства в CSS — animation-direction и translate сами развернутся. Хардкодить left со знаком минус — путь в ад.

Четвёртое — читаемость. Минимальный кегль, контраст по WCAG AA (4.5:1 для основного текста), и скорость прокрутки из расчёта простого правила: один заголовок читается за 4–6 секунд.

Хотите быстро накидать пул заголовков для тестов? Нейросети тут отлично выручают — у нас есть разбор, какой GPT выбрать для ваших задач.

И да, всё это стоит фиксировать в документации проекта — ровно как это делают в опенсорсе, см. Использование документов GitHub. Иначе через полгода никто не вспомнит, почему лента останавливается именно так.

Откуда брать новости: RSS, API и юридическая гигиена

Синдицированные ленты никуда не исчезли — они просто переехали. Сегодня они живут на сайтах вещателей и у независимых агентств, а крупные редакции отдают технологии и бизнес-разделы сразу по двум каналам: и через RSS, и через API. Reuters держит отдельный technology-раздел, у CNBC — свой tech-хаб. Только у каждого источника свои правила игры: где-то отдают всё, где-то только заголовки и ссылку.

Практика простая и проверенная. Тянем фид не в браузере, а на сервере — по крону или воркером. Дальше чистим и нормализуем всё в один плоский объект: title, url, published_at, source. Никакого «как пришло — так и покажем»: у разных фидов разные форматы даты, разные схемы ссылок, разная кодировка.

Нормализованный массив складываем в JSON-кэш, даём ему TTL минут на 10–15 и отдаём статикой в браузер. Фронтенд тогда вообще ничего не знает про фиды — он просто рендерит готовый список. Под капотом это обычный open-source парсер на сервере, обычно берут что-то из GitHub-экосистемы и не пишут свой велосипед.

Отдельная боль — парсинг с клиента. Это CORS-стена, открытые API-ключи прямо во вкладке DevTools и лимиты запросов, которые выбьет первый же `useEffect`. А потом прилетит бан по IP — и хорошо, если только на час.

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

Кстати, если нужен пример похожего подхода к переработке чужого контента — у нас был разбор про выбор GPT под конкретные задачи. Логика та же: сначала нормализовать вход, потом строить пайплайн.

Автоматизация и деплой: GitHub Actions вместо ручной правки

Ручная правка JSON руками — это весело ровно два дня. На третий вы про ленту забудете, на четвёртый она покажет заголовки недельной давности, на пятый это заметит кто-то из пользователей. Вывод простой: убираем человека из цикла.

Схема до неприличия простая. Cron дёргает workflow, workflow тянет фиды, пересобирает data/ticker.json, коммитит и пушит. Если сайт живёт на GitHub Pages, деплоя как отдельного шага вообще нет — пуш в main и есть релиз.

name: refresh-ticker
on:
  schedule:
    - cron: '*/30 * * * *'
  workflow_dispatch:        # кнопка «запустить руками» — спасает при отладке
permissions:
  contents: write
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci && node scripts/build-ticker.mjs
        env:
          FEED_API_KEY: ${{ secrets.FEED_API_KEY }}
      - run: |
          git config user.name "ticker-bot"
          git commit -am "chore: refresh ticker" || exit 0
          git push

Почему логика уезжает на build-time, а не в браузер? Потому что страница остаётся чистой статикой. Никаких рантайм-запросов к чужому API с клиента, никакого танца с CORS, никакой утечки ключей через devtools. Токены живут в Secrets репозитория, попадают только на раннер и умирают вместе с job’ом.

Бонусом — скорость. Один статический JSON за кешем CDN отдаётся за доли миллисекунды, тогда как живой запрос к внешнему сервису — это секунды ожидания и чужой аптайм в вашей зоне ответственности.

Наблюдаемость тут — не роскошь, а половина задачи. Минимальный джентльменский набор выглядит так:

Сигнал	Зачем
Бейдж статуса в README	Видно с одного взгляда, жив ли крон
Алерт при падении job’а	Почта или вебхук — чем раньше, тем дешевле
Поле updatedAt в JSON	Фронт сам решает, показать ленту или заглушку
Fallback-заголовки в репозитории	Лента не превращается в дыру в вёрстке

Если интерфейс Actions кажется лабиринтом, начните с раздела Использование документов GitHub и обзора Изучение GitHub — там объясняют, как вообще навигировать по официальной документации, вместо того чтобы вслепую тыкать по вкладкам. Полный справочник по синтаксису воркфлоу лежит на GitHub Docs.

В сухом остатке: двадцать строк YAML, один секрет, один cron. И лента, которая обновляется сама — пока вы спите, пишете код или просто занимаетесь чем-то более интересным.

Чек-лист перед выкатом и типичные грабли

Лента готова, крутится, выглядит бодро. Дальше начинается самое скучное и самое важное — пройтись по мелочам, которые вылезают только на реальных устройствах, в Safari и на телефоне у бабушки с 3G.

Вот чек-лист, который я прогоняю перед каждым выкатом бегущей строки в прод.

• Формат ленты зафиксирован. Одна строка на элемент или HTML-блок? Как формируется массив? Если решаете это на этапе вёрстки — потом не придётся ломать CSS.
• Данные кэшируются. Заголовки тянутся один раз и лежат в переменной или сторе. Ререндер не должен дёргать сеть.
• Высота контейнера фиксирована. Иначе при смене шрифта или подгрузке контента лента прыгнет и утащит за собой всю страницу.
• prefers-reduced-motion: reduce отработан. Не просто «анимация отключена», а аккуратный статичный фолбэк с кнопками навигации.
• RTL проверен. Для арабского и иврита направление скролла инвертируется — иначе текст читается задом наперёд.
• Каждая новость кликабельна и ведёт на первоисточник. Лента без ссылок — просто декорация.
• CLS равен нулю. Место под ленту зарезервировано, шрифты подключены с font-display: swap и метриками.
• Есть автотест на длину заголовка. Особенно если текст генерит нейросеть — мы уже разбирали, какой GPT выбрать для ваших задач, но лимит по символам всё равно должен проверять CI, а не глаз редактора. Базовый пайплайн поднимается за вечер — [документация GitHub](https://docs.github.com/ru/get-started/using-github-docs) в помощь.

Теперь грабли. Все они одинаковые у всех и собираются на одних и тех же граблях.

• Анимация через left / margin-left. Это layout на каждый кадр. Только transform: translateX() — и лента уезжает в композитный слой.
• Бесконечный цикл без дублирующего блока. Контент заканчивается, анимация сбрасывается — на стыке виден рывок. Дублируем содержимое дважды и уезжаем ровно на -50%.
• Запрос к чужому API на каждый рендер. Быстрый путь к rate limit и бану по IP. Кэш и ретраи с бэкоффом — обязательно.
• Нет паузы при наведении. Читатель физически не успевает дочитать заголовок.
• Крошечный шрифт на мобильных. Всё, что меньше 14px, — это уже не информация, а текстура.
• Лента не останавливается при фокусе клавиатурой. Прямое нарушение WCAG 2.2.2 и боль для тех, кто ходит по табам.

В сухом остатке: бегущая строка — это 30 строк кода и 300 мелочей. Разметка пишется за полчаса, а вот пауза при наведении, RTL, reduced-motion и ноль CLS съедают остальное время. Выигрывает не тот, кто быстрее накидал анимацию, а тот, кто закрыл мелочи заранее.

Часто задаваемые вопросы (FAQ)