Время старта и первый кадр: что это и зачем

Кратко

Время старта – его же называют временем до первого кадра (time to first frame, TTFF) – это ожидание зрителя между запросом видео и появлением его первого кадра, и это первая оценка качества, которую вообще получает любой поток. Причинно-следственное исследование большого набора Akamai показало, что зрители терпят около двух секунд, после чего каждая лишняя секунда задержки поднимает долю уходящих на 5,8% (Krishnan & Sitaraman, IMC 2012). Измеряйте старт по событиям плеера как интервал от намерения играть до первого отрисованного кадра – не до первого байта и не до загрузки манифеста – и всегда смотрите его рядом с долей сбоев и ухода, потому что быстрая медиана скрывает тех, кто так и не начал. Эта статья определяет метрику, разбирает, куда уходят секунды, показывает арифметику ухода и объясняет компромисс быстрого старта, который плеер делает в момент нажатия на «играть».

Почему это важно

Время старта – единственная метрика качества, которую зритель переживает до того, как увидел хоть один кадр, поэтому она решает, станет ли он зрителем вообще. Безупречный энкод с высокой оценкой VMAF не даст ничего, если аудитория ушла до появления картинки. Эта статья – для стриминг-инженера, разработчика плеера, QoE-аналитика и продакт-оунера, которые отвечают за удержание и которым нужно измерять первое впечатление правильно: запускать таймер в нужный момент, читать медиану и хвост и понимать, почему плеер не может просто загрузить самый качественный кадр первым. Это глубокий разбор за строкой старта из обзорной статьи о метриках QoE стриминга: там метрика названа, здесь – разобрана, и это близнец ребуферинга, остановки, которая случается уже после начала игры.

Что на самом деле измеряет время старта

Начнём с определения, потому что неверная стартовая черта тихо портит все числа, идущие следом. Время старта – это время от момента, когда зритель запросил видео, до момента, когда его первый кадр отрисован на экране. Та же метрика ходит под несколькими именами – video startup time, video start time, join time и время до первого кадра (time to first frame, TTFF), – но измеряемая величина одна: намерение играть на входе, первый видимый кадр на выходе (CTA-2066, CTA, 2020; Mux, 2025).

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

Полезное разделение приходит из практики аналитики плееров. Video startup time покрывает только видеопуть – от «play» до «playing», – а aggregate startup time добавляет ещё загрузку самой веб-страницы и инициализацию плеера (Mux, 2025). Различие важно, потому что медленная часть – часто не видео. Разберём арифметику: video startup time 0,04 с и старт плеера 0,46 с звучат отлично, но если сама страница грузится 2,00 с, зритель ждал

агрегатный старт = загрузка страницы + старт плеера + старт видео
                 = 2,00 с           + 0,46 с       + 0,04 с
                 = 2,50 с

Две с половиной секунды – за порогом ухода, который мы встретим ниже, – несмотря на почти мгновенный видеопуть. Измеряйте видеопуть, чтобы чинить доставку; измеряйте агрегат, чтобы видеть, что зритель реально почувствовал.

Ещё одна граница держит эту статью отдельно от близнеца. Старт – это не ребуферинг. Старт – это первое заполнение буфера, до первого кадра; ребуферинг – остановка после того, как игра уже началась, когда буфер позже пересыхает. Они случаются в разные моменты, зритель судит их по-разному, и лечатся они по-разному – поэтому измеряются как отдельные метрики. Свести одно к другому – значит размазать две проблемы в число, которое не чинит ни одну.

Куда уходят секунды

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

Первый этап – сетевая подготовка: разрешение имени (DNS), открытие соединения (TCP) и согласование шифрования (TLS). Он обычно мал, но не бесплатен; переход на TLS 1.3, чьему рукопожатию нужен один круг вместо двух, экономит около 100 мс в регионах с высокой задержкой (Fastpix, 2025). Второй этап – загрузка манифеста: скачивание плейлиста, который сообщает плееру, какие рендиции и сегменты есть. Третий этап – первая медиазагрузка: плеер тянет данные инициализации и столько первого сегмента, чтобы достичь своего порога стартового буфера – минимума декодированного видео, который он настаивает держать, прежде чем начать. Финальный этап – декод и отрисовка этого первого кадра.

Нажмите, чтобы увеличить

Из этой стопки следуют два практических вывода. Первый: время до первого байта (TTFB) – это один ранний этап, а не вся дистанция. TTFB меряет время от отправки запроса до прихода первого байта ответа; для веб-ответа меньше 800 мс считается здоровым (Core Web Vitals, 2025). Но TTFB кончается задолго до появления кадра на экране – он не включает заполнение буфера, декод и отрисовку. Выдавать TTFB за «время старта» – значит занижать ожидание зрителя, нередко сильно.

Второй: порог стартового буфера – обычно самый большой управляемый этап. Большинство плееров ждут, пока не наберут заданный объём медиа – число сегментов, секунд или мегабайтов, – прежде чем начать игру, как подушку против немедленной остановки (RFC 9317, IETF, 2022). Разберём пример. Пусть плеер стартует, лишь набрав две секунды медиа, начальная рендиция скромная, а сеть способна передавать данные вчетверо быстрее битрейта этой рендиции. Тогда загрузка двух секунд медиа займёт примерно

время набора = набранное медиа ÷ (скорость сети ÷ битрейт рендиции)
             = 2 с ÷ 4
             = 0,5 с   (плюс ~0,1–0,2 с накладных на запрос)

Добавьте ~90 мс сетевой подготовки, ~160 мс на манифест и ~100 мс на декод и отрисовку – и бюджет ложится около 1,0–1,1 с. Теперь срежьте порог старта с двух секунд медиа до одной: этап набора примерно вдвое уменьшается до ~0,25 с, и весь старт падает к ~0,8 с. Рычагом, что сдвинул число, оказался не кодек и не CDN, а то, сколько подушки плеер потребовал, прежде чем рискнуть начать. Эта же подушка защищает и от немедленной остановки – поэтому старт и ребуферинг настраивают вместе, никогда по отдельности.

Как измеряют это число

Время старта никогда не считывают из видеофайла; в пикселях нет ничего о том, как долго ждал зритель. Оно берётся из событий плеера. Плеер ставит метку времени на намерение играть и на первый отрисованный кадр, и разность – это метрика. Откуда эти события берутся в разных плеерах и у разных вендоров аналитики – инструментирование и таксономия событий – разбирает статья метрики на стороне плеера.

Два стандарта держат числа сопоставимыми между командами. CTA-2066 определяет события и метрики QoE стриминга – включая video start time и события сбоя старта – и задаёт, как каждую вычислять, чтобы «время старта» на одном дашборде значило то же, что на другом (CTA-2066, 2020). CTA-5004 (Common Media Client Data, CMCD) стандартизирует поля, что плеер прикрепляет к каждому медиазапросу, чтобы данные для восстановления последовательности старта доходили до любого бэкенда в одном виде (CTA-5004, 2020; ревизия CMCDv2 CTA-5004-A вышла в 2026). Правило из статьи о ребуферинге работает и здесь: используйте стандартные определения, иначе две команды будут тихо оптимизировать разные числа.

Для оценки опыта на уровне сессии параметрическая модель ITU-T P.1203 сворачивает начальную задержку загрузки – ваше время старта – в единую оценку 1–5 для сессии, рядом с картинкой, переключениями битрейта и остановками (ITU-T Rec. P.1203, 2017). Но здесь модель несёт тонкий и важный урок: одноразовое ожидание в начале весит на внутрисессионной оценке меньше, чем остановка посреди просмотра, потому что зритель прощает начальную паузу охотнее, чем прерывание, когда уже вовлечён. Это не повод расслабляться по поводу старта – наоборот. Настоящий урон старта – не очки, что он снимает с оценки сессии, а зрители, которые уходят до того, как есть сессия, которую вообще оценивать. Цена живёт выше по течению от метрики – в людях, что так и не стали аудиторией.

И последняя дисциплина измерения: приводите медиану и 95-й процентиль, никогда одну медиану. Здоровая медиана может сидеть поверх длинного медленного хвоста, а зрители, ждавшие дольше всех, – те самые в этом хвосте, – это и есть ушедшие. Тот же принцип «обобщай пол, а не только центр», что движет статьёй отчёт о контроле качества, относится и ко времени старта.

Почему первые секунды решают удержание

Причина, по которой время старта стоит рядом с ребуферингом на верхней строке любого дашборда QoE, – измерена, а в самом сильном исследовании – причинна.

Ключевой результат пришёл из квазиэкспериментального исследования большого набора Akamai (Krishnan & Sitaraman, IMC 2012). Авторы разложили просмотры по корзинам задержки старта и для каждой вычислили долю ухода – часть несостоявшихся зрителей, сдавшихся до начала видео. Форму этой кривой стоит запомнить: уход близок к нулю первые две секунды, затем круто растёт, и регрессия на растущей части показывает, что каждая дополнительная секунда задержки старта поднимает долю ухода примерно на 5,8 процентного пункта (Krishnan & Sitaraman, 2012). Поскольку исследование использовало сопоставленные пары для контроля над искажающими факторами вроде типа соединения и географии, этот наклон причинный – медленный старт заставляет зрителей уходить, а не просто совпадает с уходом.

Нажмите, чтобы увеличить

Поставим число. Пусть ваш плеер показывает первый кадр за 3,5 секунды. Это 1,5 секунды за двухсекундным изломом, так что модель предсказывает дополнительные

уход из-за старта ≈ 5,8% × (3,5 с − 2,0 с)
                  ≈ 5,8% × 1,5
                  ≈ 8,7%

Теперь масштабируем на вечер запуска в 1 000 000 попыток воспроизведения:

потеряно зрителей ≈ 8,7% × 1 000 000
                  ≈ 87 000 ушли до начала видео

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

Два уточнения из той же работы заостряют, где падает цена. Зрители менее терпеливы к короткому контенту, чем к длинному – ради полнометражки они переждут медленный старт, но бросят новостной ролик (Krishnan & Sitaraman, 2012, утверждение 5.2), и авторы связывают это с психологией очередей, где более долгая ожидаемая отдача покупает больше терпения. И, что контринтуитивно, лучше подключённые зрители уходят раньше: на оптоволокне терпения меньше всего, а на мобильном ждут дольше всех, потому что ожидания заданы привычной скоростью (Krishnan & Sitaraman, 2012, утверждение 5.3). Предшествовавшая корреляционная работа согласна, что задержка старта (там – join time) среди метрик, что двигают вовлечённость, хотя наибольший единичный эффект несёт доля буферизации (Dobrian et al., SIGCOMM 2011).

Компромисс, который плеер делает в момент нажатия

Если старт так дорог, почему бы не показать самый качественный первый кадр сразу? Потому что качество первого кадра и скорость его показа тянут в разные стороны, и плеер должен выбрать между ними прежде, чем хоть что-то узнает о сети. Это стартовое лицо адаптивного стриминга по битрейту (ABR): плеер выбирает рендицию для того самого первого сегмента с пустым буфером и без истории пропускной способности.

Выберите низкую начальную рендицию – и первый сегмент мал, грузится быстро, видео стартует быстро, но первые секунды выглядят мягко, а именно первые секунды задают ожидание качества у зрителя. Выберите высокую начальную рендицию – и первый кадр чёткий, но докачать до порога буфера нужно больше, поэтому старт медленнее, а риск немедленной остановки выше. Большинство плееров в продакшене решают это, стартуя низко ради быстрого старта, а затем переключаясь вверх, как только измеренная полоса или заполнение буфера это оправдывают (Mux, 2026). Как часто и как заметно они переключаются – отдельный вопрос QoE, разобранный в статье битрейт, переключения и компромисс ABR.

Нажмите, чтобы увеличить

Рычаги, что сокращают старт, не роняя просто качество, все бьют по самым большим этапам с Рисунка 1: понизить порог стартового буфера, взять более короткий первый сегмент, чтобы докачивать меньше до начала, держать сегменты короткими и применить low-latency HLS или DASH, чтобы плеер мог начать с частичного сегмента. Вывод про измерение, который и относится к этому разделу: время старта – не число, которое минимизируют в вакууме. Загоните его в ноль, всегда стартуя на низшей рендиции, – и вы поменяли проблему старта на проблему первого впечатления; гонитесь за безупречным первым кадром – и зовёте уход обратно. Читайте старт вместе с метриками картинки из статьи как выбрать правильную метрику и остальной доставкой, и помните, что как алгоритм делает выбор – территория раздела «Видеостриминг»; этот раздел владеет тем, как вы измеряете результат.

Ловушка выжившего: время старта, сбои и уходы

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

Время старта можно вычислить только для сессии, которая реально началась. Каждый зритель, который так и не получил первого кадра, по определению отсутствует в вашем среднем времени старта. Так исчезают две группы. Первая – сбой старта видео (video startup failure, VSF): попытки воспроизведения, оборвавшиеся при старте с фатальной ошибкой, до появления кадра (CTA-2066, 2020; Conviva, 2026). Вторая – уход до старта видео (exit before video start, EBVS): зрители, сдавшиеся добровольно во время ожидания, – тот самый уход, что считает кривая Krishnan–Sitaraman. Ни одной из групп нет в вашем числе старта, потому что ни одна не дала первого кадра, который можно было бы засечь.

Следствие – ошибка выжившего: оптимизируя только медиану времени старта, вы можете полировать опыт выживших, пока сбои и нетерпеливые тихо уходят. Сервис может показывать аккуратную секундную медиану старта поверх жестокой суммы сбоев и ухода, и дашборд будет выглядеть нормально. Лечение – мерить все три вместе: время старта для тех, кто начал, VSF для тех, кто сбойнул, и EBVS для тех, кто бросил ждать, – чтобы хорошо выглядящее число не могло спрятать зрителей, которых оно исключает.

Нажмите, чтобы увеличить

Частые ошибки при измерении времени старта

Та же метрика, что предсказывает удержание, легко читается неверно. Повторяются шесть ловушек.

Первая – мерить время до первого байта и звать его временем старта: TTFB – один ранний этап с Рисунка 1, и он кончается до появления кадра. Вторая – запускать таймер не в тот момент: отсчёт от загрузки манифеста, а не от намерения играть, стирает ожидание, которое зритель реально почувствовал. Третья – приводить одну медиану, которая прячет медленный хвост, где живут уходящие; смотрите её вместе с 95-м процентилем, как настаивает статья мониторинг качества в продакшене для любой метрики флота. Четвёртая – ловушка выжившего выше: время старта без VSF и EBVS. Пятая – позволить предзагруженному видео испортить число: видео, что начало грузиться до клика, сообщает обманчиво быстрый старт и портит любое сравнение CDN (Mux, 2025); пре-роллы искажают так же. Шестая – путать старт с ребуферингом: разный момент, разная метрика, разное лечение, – что статья о ребуферинге аккуратно держит раздельно.

Где здесь Фора Софт

Фора Софт строит продукты для видеостриминга, OTT, конференций, онлайн-обучения, телемедицины и видеонаблюдения с 2005 года, и в каждом из них время до первого кадра – одно из первых чисел, что мы выносим на дашборд. Мы инструментируем старт из событий плеера по стандартным определениям (CTA-2066) и клиентским данным (CMCD), чтобы метрика значила одно и то же на вебе, мобайле и ТВ, – и всегда читаем её рядом с долей сбоев старта и ухода до старта, чтобы быстрая медиана не могла спрятать зрителей, что так и не дошли до кадра. В live- и конференц-продуктах, где первый кадр и есть опыт входа и второго дубля нет, эта телеметрия – главный сигнал качества. Задача не в более красивом графике старта, а в том, чтобы поймать устройство, CDN или регион, чьи первые кадры приходят слишком поздно, прежде чем эта аудитория решит, что продукт медленный.

Ключевые выводы

• Время старта (время до первого кадра) – ожидание от намерения играть до первого кадра.
• Меряйте его по событиям плеера – не по TTFB и не по загрузке манифеста.
• Уход почти ноль до ~2 с, затем растёт ~5,8% за секунду (Krishnan & Sitaraman, 2012).
• Порог стартового буфера – обычно самый большой управляемый компонент.
• Старт на низкой рендиции даёт быстрый старт, но мягче первое впечатление – реальный компромисс.
• Всегда приводите время старта вместе с долей сбоев (VSF) и ухода до старта (EBVS).

Что почитать дальше

• Метрики QoE стриминга: что предсказывает, останется ли зритель – рамка для всего Блока 6.
• Доля ребуферинга и цена остановки – вторая половина первого впечатления.
• Битрейт, переключения и компромисс ABR – что происходит после быстрого старта.