Стоит ли gzip JavaScript-файл в Chrome Extension?

Question

Есть ли какая-нибудь причина для gzip массивного js-файла, загружаемого локально хром-расширением? Увеличит или уменьшит скорость загрузки? Зачем?

Google рекомендует использовать Gzip для сжатия файлов. Но действительно ли это имеет значение, когда файлы передаются по сети? Или также быстрее обрабатывать gzip-файл локально?

Answer 1

При загрузке сценария существует как минимум две фазы, которые могут повлиять на скорость загрузки скрипта: время передачи данных и время разбора/оценки.

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

Я думаю, что суть вашего вопроса в том, сохранится ли это, когда передача данных происходит с локального диска. Локальный диск будет, как правило, быстрее, чем сеть, и поэтому возникает вопрос, является ли локальный диск более быстрым, чем сеть, что дополнительное время обработки декомпрессии gzip начинает превышать стоимость чтения дополнительных байтов из несжатого файла из диск.

Ответ на этот вопрос должен обязательно зависеть от диска и процессора, поэтому не может быть окончательного ответа. Вы можете, однако, сделать образованный выбор, попробовав оба варианта и используя инструменты разработчика Chrome, которые доступны для фоновых страниц, используемых расширениями, а также для обычных веб-страниц. Вы можете найти инструменты для разработчиков фона страницы путем доступа к chrome://extensions страницу и нажмите на ссылку фон страницы рядом с «Осмотреть видом», как показано на скриншоте, как «background.html»:

Вопросы к попытаться ответить инструментами для разработчиков:

• Имеет ли какой-либо вариант достаточно долго, чтобы оценить это дальше? Если оба подхода приводят к фоновой странице, которая загружается достаточно быстро для ваших нужд, тогда вы можете просто сделать все, что проще всего для вашего рабочего процесса разработки.
• Есть ли существенная разница во времени между двумя вариантами? Конечно, то, что является «значительным», будет зависеть от вашего прецедента, но если разница небольшая, то снова вы можете выбрать наиболее удобный подход.
• Предполагая разницу во времени является значительным, что было быстрее?

Хорошее место для начала, чтобы выбрать вкладку «Timeline» в рамках инструментов разработчика для вашего фона страницы, и нажмите клавишу F5, чтобы обновить страницу фона и сбор информации о его использовании ресурсов в процессе начальной загрузки:

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

• «Отправить запрос» для файла JavaScript, который вы рассматриваете.Это будет очень маленький «бар» в визуализации, потому что Chrome считает это мгновенным событием, которое начинает фоновое задание, которое не отображается.
• «Завершить загрузку» для того же файла. Разница во времени между «Send Request» и «Finish Loading» - это время, необходимое для чтения файла с диска.
• «Оцените сценарий» для этого файла. (обратите внимание, что декодирование gzip обычно выполняется одновременно с загрузкой данных из сети/диска, поэтому время gzip, вероятно, будет включено в пробел между «Request Request»/«Finish Loading», а не в этом блоке «Evaluate Script» .)

Время, которое имеет значение для вашего вопроса, это разность во времени между началом «Отправить запрос» и окончанием «Оценить сценарий». В моем примере здесь с расширением Cast Google:

• «Отправить запрос» началась в 95.2ms
• «Оценка сценария» началась в 103.1ms и побежал за 174ms, поэтому она закончилась в 277.1ms
• Таким образом, общее время было 277,1 - 95,2 = 181.9ms

Пробуя это как с расширением с несжатым JS и расширение с тем же JS с gzip'нутыми вы можете получить два значения временных и ответить на поставленные выше вопросы, и, таким образом, в свою очередь, найти ответ на ваш первоначальный вопрос о том, будет ли сжатие JS стоит.

---

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

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