Современные веб-технологии активно развиваются, и API Fetch становится одним из ключевых инструментов для работы с сетевыми запросами и потоками данных. Fetch streams, или потоки Fetch, обеспечивают удобный и эффективный способ обработки данных во время загрузки и выгрузки, что позволяет приложениям работать более плавно и эффективно. Однако, несмотря на преимущества Fetch streams, их использование для измерения прогресса загрузки и скачивания данных вызывает определённые сложности и неточности. В этой статье мы подробно рассмотрим, почему потоки Fetch не подходят для точного измерения прогресса, как эту задачу решают другие инструменты, а также о текущем состоянии и будущих перспективах в этой области. Fetch streams и их возможности Fetch API уже долгое время используется веб-разработчиками для отправки сетевых запросов и получения ответов.
Возможность работы с потоками в Fetch появилась, в основном, для ответов (response streams). Это позволяет получать данные порциями, по частям, что значительно улучшает взаимодействие с большими ресурсами и позволяет начать обработку данных, не дожидаясь полной загрузки. С точки зрения загрузки данных, когда вы запрашиваете ресурс с сервера, браузер предоставляет доступ к телу ответа в виде ReadableStream. Через чтение этих потоков по частям можно получать данные постепенно и, например, отображать прогресс загрузки или обрабатывать информацию по мере её поступления. Однако для измерения прогресса скачивания ключевой проблемой становится корректность подсчёта загруженных данных.
Точность зависит от нескольких факторов, таких как правильное определение общего размера файла и влияние сжатия данных на канале передачи. Проблемы с измерением прогресса скачивания Одна из распространённых идей - узнать содержимое заголовка Content-Length, который сообщает общий размер передаваемого контента в байтах, и затем накапливать размер получаемых в потоках чанков данных. Итоговый результат помогает вычислить, какой процент файла был уже загружен. На практике этот метод часто даёт неверные результаты, особенно если сервер или браузер применяют сжатие (например, brotli, gzip или deflate). Дело в том, что Content-Length отражает размер оригинальных сжатых данных, тогда как поток fetch предоставляет уже распакованные чанки.
То есть фактически происходят разные измерения: общий размер соответствует сжатому файлу, а загрузка меряется по распакованным данным. Следствием становится ситуация, когда накопленная длина чанков превышает значение Content-Length, и вычисленный процент прогресса скачивания может превысить 100%. Это создаёт плохой пользовательский опыт и вводит в заблуждение. Хотя проблемы с прогрессом скачивания сжатых данных известны давно, в стандартах и браузерах пока не разработано универсальное решение. В интернете можно найти запросы на добавление механизмов для получения необработанных (raw) данных потоков до распаковки, но это пока остаётся на уровне предложений и обсуждений среди разработчиков.
Потоки Fetch для загрузки: почему они не подходят для точного прогресс-мониторинга С развитием Fetch API появилась возможность создавать запросы с потоками тела (request streams). Это особенно удобно для приложений, которые хотят отправлять данные частями - например, видео редакторы или системы, которые обрабатывают медиафайлы на стороне клиента и сразу же начинают их отправку по частям. Суть в том, что при использовании request streams браузер принимает данные из пользовательского потока и работает с ними дальше, отправляя их на сервер. Однако попытка отследить прогресс загрузки по мере извлечения чанков из пользовательского потока - это лишь фиксация момента, когда браузер берёт данные, а не когда они достигли сервера или были успешно переданы по сети. Иными словами, если представить эту ситуацию с почтой, измерение через потоки - это отслеживание момента передачи пакета курьеру, а не момента доставки до адресата.
Между этими двумя моментами могут быть значительные задержки, связанные с физическими сетевыми условиями, буферизацией и организацией транспортного уровня. Из-за этого значения прогресса загрузки, вычисляемые на базе request streams, получаются неточными и даже вводящими в заблуждение. Кроме того, существующая архитектура браузеров предусматривает различные механизмы внутреннего буферизации, что дополнительно усложняет корректный учёт фактически переданных байтов. Данная проблема не только техническая, но и концептуальная. Если разработчики возьмут за основу именно эти данные для отображения прогресса, это может сформировать у пользователей ложные ожидания, а также ограничить возможности браузеров по оптимизации сетевых передач - например, по увеличению размера внутренних буферов.
Текущее решение: XMLHttpRequest и его прогресс-события Несмотря на то, что Fetch API считается более современным и удобным инструментом, именно XMLHttpRequest (XHR) остаётся сегодня лучшим способом для точного измерения прогресса загрузки и скачивания. XHR поддерживает события прогресса, которые работают корректно и позволяют с высокой точностью отслеживать переданные и полученные байты. С помощью XHR можно подписаться на событие onprogress как для загрузки, так и для выгрузки. При этом объект события содержит сведения о `loaded` - сколько байт передано или получено и `total` - общий размер данных; при условии, что браузер смог определить общий размер. Эти события позволяют создавать удобные и точные индикаторы прогресса, насколько это возможно в современных браузерах.
Парадокс в том, что несмотря на всю новизну Fetch, именно старая проверенная технология продолжает оставаться оптимальной для задач прогресс-отслеживания. Это объясняется зрелостью и временем отладки XHR в различных браузерах. Будущее API прогресса в Fetch Чтобы устранить существующие недостатки и наконец предоставить пользователям удобные и современные инструменты, идут разработки новой функциональности в Fetch, которая позволит отслеживать прогресс загрузки и скачивания на уровне API Fetch. Ярким примером стал проект, инициируемый разработчиком Luke Warlow из компании Igalia, который разрабатывает API с событиями прогресса для запросов и ответов. В предлагаемом API разработчик сможет указать наблюдателя (observer), который предоставит доступ к событиям прогресса с подробными сведениями о загруженных и отправленных байтах.
Такой подход позволит объединить удобство Fetch с необходимостью точного мониторинга состояния передачи данных без искажений и сложностей, характерных для потоков. Этот API ещё находится в стадии разработки, и некоторые детали могут измениться, но он обещает стать тем решением, которого долго ждут разработчики. Поддержка прогресса часто является крайне важной для пользовательского интерфейса, особенно в приложениях, где выгрузка и загрузка больших ресурсов напрямую влияет на восприятие качества и скорости работы. Сценарии использования потоков Fetch, где прогресс не нужен Хотя потоки Fetch не подходят для измерения прогресса, они остаются очень полезными для множества других задач. К примеру, потоковая передача данных, обработка и трансформация ресурсов на лету, интеграция с потоковыми API других браузерных и JavaScript-сред, таких как Web Streams API и TextDecoderStream.
Для приложений, где важна задержка между приходом данных и их началом обработки - например, медиа-приложения, онлайн-редакторы, трансляции - Fetch streams предоставляют огромный простор для оптимизации и повышения скорости отклика без необходимости ожидать полной загрузки файлов. В случаях, когда прогресс имеет второстепенное значение или реализуется через иные механизмы (например, мониторинг состояния соединения, сигналы непосредственно от сервера), использование потоков будет вполне оправданным и эффективным. Заключение Потоки Fetch - это мощный инструмент в арсенале современных веб-разработчиков, который предоставляет гибкие возможности для работы с данными как на стороне загрузки, так и выгрузки. Однако их архитектурные особенности и особенности реализации в браузерах делают их неподходящими для точного измерения прогресса передачи данных. Такой прогресс требует специализированных механизмов, которые могут гарантировать корректность и точность учёта, что пока лучше всего решается через XMLHttpRequest.
Будущие расширения Fetch API, направленные на добавление прогресс-эвентов, обещают устранить этот пробел, объединив преимущества современного Fetch с необходимостью мониторинга передачи данных. Важный совет для разработчиков - не использовать потоки Fetch для реализации прогресс-бара или другого интерфейса, ориентированного на измерение передачи данных. Для этих целей сегодня лучше использовать XHR или ждать внедрения прогрессивных API в Fetch. Используя существующие знания и внимательно подходя к выбору инструментов, можно обеспечить пользователю качественный опыт без ложных ожиданий и технических ошибок. Прогресс веб-технологий очевиден, и Fetch API со временем станет ещё мощнее и удобнее, закрывая современные пробелы и открывая новые возможности для создания даже более быстрых и отзывчивых веб-приложений.
.
