Скролл-фильм на лендинге весил 84 МБ. WebCodecs ужал его до 18 — вот что сработало, а что нет

Значимый прорыв формирует отрасль ИИ: r_o_m_k_o_l_a 13 минут назад Скролл-фильм на лендинге весил 84 МБ. WebCodecs ужал его до 18 — вот что сработало, а что нет Средний 5 мин 352 JavaScript * Веб-разработка * Клиентская оптимизация * Работа с видео * Кейс Из песочницы У меня лендинг устроен как «фильм, который листаешь»: крутишь колесо — камера едет по сцене. Классическая реализация такого — секвенция кадров: сотни WebP, по картинке на каждую позицию скролла.

Работает, но на мобильной версии это выливалось в 84 МБ трафика. Для лендинга, который человек открывает с рекламы на телефоне где-нибудь в лифте, — приговор. Расскажу, как я заменил секвенции кадров на видеопоток, который декодируется прямо в браузере через WebCodecs, почему выбросил контейнер mp4 целиком, и про три тупика, в которые успел сходить: два из них выглядят как очевидные улучшения, а на деле не дают ничего, третий вообще сломал сайт на живом iPhone так, что ни один автотест этого не увидел.

Технические детали

Почему не Первый вопрос, который задают все: «а чего не обычный видеотег с привязкой currentTime к скроллу? »Пробовали — и это известная боль. Скролл-фильму нужен произвольный доступ к конкретному кадру: пользователь дёргает страницу вверх-вниз, и на каждую позицию нужен свой кадр, мгновенно и точно.

currentTime для этого не предназначен: seek асинхронный, точность зависит от расстановки опорных кадров, на мобильных Safari всё это ещё и подтормаживает и мерцает. Получается кисель вместо фильма. Поэтому все и держат секвенции картинок: JPEG/WebP на каждый кадр, рисуем в canvas.

Плавно, точно — и чудовищно тяжело, потому что каждый кадр сжат независимо, а межкадровую избыточность (в соседних кадрах 95% пикселей совпадают) никто не использует. WebCodecs — ровно недостающее звено: это доступ к аппаратному видеодекодеру браузера из JS, без видеотега. Скармливаешь сжатые кадры — получаешь VideoFrame, который рисуется в canvas.

Отраслевые последствия

Межкадровое сжатие работает, покадровый контроль остаётся у тебя. Поток без контейнера — и зачем такОбычно H. 264 живёт в контейнере: mp4, mkv.

Чтобы достать из mp4 отдельные сжатые кадры для WebCodecs, нужен демуксер — почти все туториалы тянут mp4box. Я контейнер выбросил целиком. На сцену — один файл: сырой H.

264 Annex-B, то, что ffmpeg отдаёт при -f h264. В этом формате кадры разделены стартовыми кодами 00 00 01 — и страница просто ищет их в ArrayBuffer и режет поток на кадры сама. Это ~30 строк кода вместо целой библиотеки-демуксера.

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