jQuery для мобильных устройств, все за и против

image

Это довольно вольный перевод статьи, которая попалась мне на просторах интернета. Её автор — TJ VanToll. Он уже много лет занимает веб-разработкой и, в частности, оптимизацией сайтов для большей производительности на мобильных телефонах. Под катом рассмотрены несколько способов оптимизации, а так же приведены результаты тестирования на различных устройствах.

Стоит ли использовать jQuery для мобильных устройств?


Мне часто задают этот вопрос, но за все это время не было проведено ни одного исследования, которое могло бы это объяснить. О библиотеке jQuery часто говорят, что она «большая» и «раздутая», но эти понятия относительны, они ничего не доказывают без экспериментального подтверждения. Правильно было бы задавать этот вопрос так: «Влияют ли размеры jQuery настолько сильно, чтобы мы могли отказаться от использования этой библиотеки в ущерб функциональности?». Чтобы ответить на этот вопрос, мы должны определить скорость загрузки библиотеки на мобильное устройство. Эта статья посвящена как раз этому вопросу, но с начала нам необходимо разобраться в том, что происходит внутри тега <script>.

Тег <script>


<script src="jQuery.js"></script>

Все мы видели этот код большое количество раз, но что происходит в браузере, когда он видит эту строку? На самом деле, происходит много событий, но нас интересуют лишь два наиболее важных процесса.
  • Получение файла (тут есть два варианта: из кэша или из сети);
  • Парсинг и выполнение скрипта.

Давайте разберем каждый из этих пунктов по отдельности.

Загрузка jQuery


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

Пропускная способность.


Пропускная способность — это скорость, с которой браузер может скачать файл с сервера, чаще всего измеряется в Мбит.
В 2012 году средняя скорость мобильных сетей по всему миру варьировалась от ~2 Мбит в некоторых азиатских странах до ~1 Мбит в России и Индии. Конечно, эти данные немного устарели, новые сети обещают большую скорость, например:
  • Virgin Mobile утверждает, что её сеть 4G имеет скорость загрузки 3-6 Мбит;
  • Verizon Wireless утверждает, что её сеть 4G имеет скорость загрузки 5-12 Мбит;
  • LTE сети предлагают скорость ~6.5 Мбит в США и ~24.5 Мбит в Австралии.

Так как эта статья о jQuery, давайте использовать эти цифры, чтобы определить, как долго загружается jQuery. Мы основываемся на сжатой версии библиотеки 2.1.0, которая весит 28.65 КБ.

Сеть со скоростью загрузки 1 Мбит может скачивать 125 КБ в секунду, это означает, что за одну секунду вы можете скачать jQuery 4.36 раза. Или говоря более конкретным языком:
  • 229мс, чтобы загрузить на самой плохой скорости (1 Мбит);
  • 46мс, чтобы загрузить на средней скорости (5 Мбит)
  • 19мс, чтобы загрузить на высокой скорости (12 Мбит).

Позже мы вернемся к этим вычислениям, но, согласитесь, это уже более менее конкретная информация? Но на самом деле пропускная способность сети — не самая главная проблема мобильной веб-произвоительности. Например, Илья Григорик (Google) заметил, что при переходе из сети со скоростью 5 Мбит на сеть со скоростью 10 Мбит время загрузки сокращается всего на 5%.

Итак, мы выяснили что пропускная способность сети не является узким местом, тогда в чем причина?

Задержка


В контексте веб-приложений задержка — это время, необходимое для того, чтобы соединиться с сервером. Задержка обычно измеряется в RTT (Round Trip Time) — это время, за которое сигнал достигает сервера и возвращается обратно клиенту.

Исторически так сложилось, что мы не сильно беспокоились о времени задержки на персональных компьютерах, так как RTT мало, порядка 50мс. Но с мобильными телефонами нам повезло меньше. В 2012 году среднее время RTT мобильных сетей в США было около 344мс. И это время задержки не только HTTP запросов, которое сейчас составляет 93мс, но так же и каждого DNS и TCP запроса.

Сейчас средний показатель RTT несколько улучшился. Virgin Mobile объявляет, что средняя задержка в сети 4G теперь составляет ~150мс. Пока что средние показатели задержки улучшаются, но существует проблема, связанная с конечным пределом скорости передачи, что не дает нам свести задержку к минимуму.

Но во всем этом есть и светлая сторона. Помните, мы говорили о том, что есть простой способ избежать больших задержек при использовании jQuery: вместо того, чтобы загружать библиотеку отдельным файлом, вложите содержимое в файл вашего скрипта и загружайте их вместе! Так, как показано ниже:

<!-- Before -->
<script src="jQuery.js"></script>
<script src="app.js"></script>

<!-- After -->
<script src="app.js"></script>

Это простое изменение сводит на нет задержку, возникающую при отдельной загрузке jQuery в ваше приложение. Это же можно осуществить и при загрузке библиотеки из внешнего CDN. Из-за фрагментации у CDN-провайдеров шансы на использование кэш-памяти CDN являются низкими — и загрузка с сервера может выполняться в несколько шагов (DNS поиск, подключение TCP, и отправка GET-запроса HTTP).

Ранее мы вычислили время, необходимое для скачивание файла jQuery из сети. Получается, что мы можем загрузить файл за 50мс, используя сети среднего качества, если избежим задержки, загружая объединенный файл JavaScript. Но, скачав файл, браузер его обрабатывает. Давайте рассмотрим этот момент более подробно.

Парсинг и выполнение скрипта


После того, как браузер скачал файл, он должен превратить код на JavaScript в байт-код и выполнить его. Этот процесс довольно сложный и если попытаться рассмотреть его детально, то мы выйдем далеко за рамки этой статьи; нас интересует другое.

Так сколько же времени занимает этот процесс?

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

<script>var start = new Date();</script>
<script>
    /* jQuery's minified source code in its entirety */
</script>
<script>alert( new Date() - start );</script>

Я экспериментировал с console.time() и console.timeEnd(), но не использовал их, потому что они не поддерживаются в более старых мобильных браузерах. В браузерах, которые поддерживали эти методы, я получил почти идентичный результат предложенному ранее.

Для того, чтобы выделить время парсинга и выполнения, я записал jQuery как инлайн скрипт (т.е. непосредственно вставленный код в html разметку). Результаты выполнения в различных браузерах показаны ниже.
Браузер ОС Время парсинга/выполнения jQuery 2.1.0 (в мс)
IE 11 Windows 8.1 18, 21, 14, 16, 15
Chrome 33 OS X 10.9.2 15, 8, 5, 7, 6
Safari 7 OS X 10.9.2 9, 5, 3, 3, 2
Firefox 27 OS X 10.9.2 12, 12, 11, 12, 12
Safari iOS 7 178, 125, 44, 87, 96
Default Android Android 2.2 1184, 268, 299, 216, 422
Default Android Android 4.0 603, 465, 106, 145, 243
Chrome 33 Android 4.4 219, 86, 38, 86, 123
Firefox 27 Android 4.4 269, 367, 400, 381, 264

Тесты десктопного браузера были проведены на MacBook Pro, испытания мобильных браузеров я проводил на подручных устройствах. Я не очищал кэш-браузера между загрузками, я просто несколько раз нажал на кнопку «Обновить». Это привело к интересным результатам: браузеры на WebKit (Chrome, Safari) при первой загрузке сохраняют данные в кэш и скорость при последующих загрузках значительно выше, в тоже время браузеры на Trident (IE) и Gecko (FireFox) так не делают. Если какие-нибудь разработчики этих движков читают эту статью, я бы хотел по подробней узнать детали парсинга. Так же если у вас есть другие предложения, как вычислить время, прошу поделиться ими в комментариях.

Все браузеры для настольных ПК — IE, Chrome, Safari и Firefox — с легкостью справились с этой задачей. Даже IE показал довольно хороший средний результат ~17мс.

Но мобильные браузеры показали совсем другой результат. В то время как Mobile Safari на iOS7 и Chrome на Android справились с этой задачей достойно. Стандартный браузер на Android показал очень плохие результаты. Мой первый запуск этого теста на моем Android 2.2 занял целую секунду. И хотя у меня не было большого разнообразия устройств для проверки, я подозреваю, что на многих других устройствах результаты будут еще хуже.

На мой взгляд, такой медленный парсинг и выполнение скриптов на мобильных браузерах, в особенности на стандартных браузерах Android — это большой плюс в копилку тех, кто предпочитает использовать маленькие библиотеки JavaScript, вместо jQuery.

Однако в нашем тесте прослеживаются и хорошие моменты. Здесь налицо закон Мура, явно заметна разница между Android 2.2 и Android 4.0, и скорее всего такая тенденция будет прослеживаться и дальше.

Подведем итоги, так ли страшен размер jQuery как о нем говорят?

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

Время загрузки jQuery 2.1.0 размером 28.56КБ занимает:
  • 229мс при скачивание в плохих сетях со скоростью 1Мбит;
  • 46мс при скачивание в нормальных сетях со скоростью 5Мбит;
  • 19мс при скачивание в хороших сетях со скоростью 12Мбит.

Время задержки при загрузке jQuery 2.1.0 составляет:
  • 0мс если вы вложили содержимое библиотеки в файл вашего скрипта;
  • 150-1000мс если вы загружаете библиотеку отдельным файлом.

Парсинг/Исполнение jQuery 2.1.0 занимает:
  • 15-20мс для десктопного браузерах;
  • ~270мс среднее время загрузки на всех исследуемых мобильных браузерах.

Эти цифры дают понять, что старые версии браузеров на Android 2.2 могут добавить нам лишнюю секунду на загрузку. Это необходимо учитывать при разработке, опираясь на целевую аудиторию, т.к. это может плохо повлиять на эффективность.

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

Но давайте вернемся к цифрам. Из приведенных выше данных следует, что в среднем загрузка jQuery из сети займет ~50мс, плюс время синтаксического анализа ~250мс. Давайте докажем, что время это деньги. Рассмотрим для примера Amazon. Там утверждают, что из-за каждых 100мс задержки при загрузке страницы на amazon.com они теряют 1% продаж. Несложно подсчитать, что подключенная библиотека jQuery стоит им 3% продаж. Это звучит ужасно, но следует рассмотреть и положительные моменты, так как при использовании jQuery улучшается производительность и функциональность сайта, достаточная, чтобы покрыть 3-х процентную потерю продаж.

Так же необходимо понимать, что библиотека состоит из модулей. Следовательно, если вас не устраивает скорость загрузки, вы легко можете удалить ненужные модули, оставив только необходимые. Но прежде чем это делать, давайте рассмотрим другие проблемы.

У вас наверняка есть еще много способов повысить эффективность ваших приложений


По данным HTTP archive, средняя веб-страница:
  • Весит более 1.7МБ;
  • Создает более 90 HTTP запросов;
  • Имеет больше 275КБ скриптов на JavaScript;
  • Создает 17 HTTP запросов только на один JavaScript;
  • Включает в себя 1МБ изображений;
  • Всего 46% страницы содержится в кэше.


Поэтому прежде всего необходимо обращаться внимание на следующие вещи.
  • Необходимо минимизировать CSS/JS;
  • Объединить все файлы CSS/JS в один;
  • Использовать специальные средства для компрессии HTML/CSS/JS документов;
  • Сжимать изображения;
  • Позволять браузеру сохранять файлы в кэш;
  • Удалить ненужные HTTP запросы.

Зачастую удалением нескольких изображений можно достичь гораздо больших результатов, чем удалением jQuery. Если вы выполнили некоторую оптимизацию, но все еще испытываете проблемы с производительностью на мобильных устройствах, и думаете об удалении jQuery — просто проверьте, сделали ли вы все возможное, или же еще остались другие способы?
Поделиться публикацией

Похожие публикации

Комментарии 20
    0
    Интересная статья, спасибо! Сразу вспоминается пара книг: «Реактивные веб-сайты» и «Разгони свой сайт».
      0
      RTT наше все. Сейчас быстрее вклеивать стили и скрипты внутрь, чем загружать отдельные файлы и надеяться найти их в кэше мобильного браузера.
      +1
      Интересно, но как-будто обрывается на середине.
      Кажется, что сейчас пойдет самое интересное, а тут… всё.
        0
        За переводом этой статьи я настолько углубился и заинтересовался данной темой, что планирую продолжить уже собственное исследование, возможно опубликую, если людям будет интересно.
        +4
        кривая статья. очень много допущений.
        очень умилило «за минимальную скорость мобильного интернета возьмем 1мбит» и выведение закона мура по версиям андроида без уточнения девайсов.

        а самого главного ответа — насколько jquery медленнее vanilla js — нет, чисто «да у наших пользователей, наверное, хорошие устройства с хорошим интернетом, они спокойно загрузят лишние 30кб жса». И да, «средняя страница — 1.7 мб» — это смешно. тут хорошо бы взять медиану, причем именно страницдля мобильных, а не всех сайтов мира
          +1
          Все же там написано: «средняя веб-страница весит более 1.7Мб», то есть просто обозначена некоторая граница. В заключительной части статьи упор делается на необходимость оптимизации сайта в целом. Несколько килобайт можно скинуть просто загрузив оптимизированное изображение, но почему то до сих пор существует много сайтов, которые даже этого не делают.
            0
            Субьективно (нужно реально будет поизучать, когда возникнет потребность — опубликую обязательно) — медиана средней мобильной страницы НЕ мобильного приложения укладывается в 150-250 кб на данный момент. Из них ассеты (подгружающееся парралельно содержимое: изображения, шрифты etc) занимают 100-150кб, и они не загружают основной поток загрузки содержимого.
            На JS, html и css в среднем для мобильной (не адаптивной, а именно мобильной версии) по факту занимают 50-150 Кб.(сразу говорю, я говорю гзипнутые размеры, по факту это до 500 кб спокойно может быть).
            Поэтому «средняя веб-страница весит более 1.7 МБ» в контексте мобильного jQuery — такое же лукавство, как и «на андроид 4.4 оно отрабатывает за столько-то секунд». Я могу для сравнения взять мой убитый Atrix 4g 2011 года выпуска — на нем для тестов сейчас Cyanogen 4.4 стоит, и Sony Z1 — на нем стоковый 4.4, и сравнить, за сколько тестовый скрипт загрузится и отработает. Уверен, разница будет в два раза минимум.
          0
          и про jquerymobile.com никто даже не вспомнил, которая работает на ajax-pages…
            +1
            Не стоит забывать и про работу сайта после загрузки jQuery, а он ни скоростью ни потреблением памяти похвастаться не может. Описанные проблемы с перформансом решает jBone, если конечно вы готовы пойти на менее богатый API.

            Еще могу добавить, что после перевода приложения с jQuery на jBone сократили время загрузки сайта, процессинг и потребление памяти в среднем в 2 раза. Не уверен, что дело только лишь в jBone, так как по пути переписали еще не мало всего, но результат радует. Уже давно думаю о полноценной статье об этом.
              –1
              del
                0
                «В то время как Mobile Safari на iOS7 и Chrome на Android справились с этой задачей достойно. Стандартный браузер на Android показал очень плохие результаты.»
                А в андроиде какой стандартный браузер если не Chrome?
                  +1
                  Не могу сказать что на всех, но на некоторых версия android, установлен по дефолту «Android Browser», в статье речь идет о нем.
                  • НЛО прилетело и опубликовало эту надпись здесь
                      0
                      > А в андроиде какой стандартный браузер если не Chrome
                      Вроде всю жизнь был «Интернет»? Хорошо хоть не «исследователь интернета»
                      0
                      За годы с момента написания статьи (судя по версиям андроида 2.2 и 4.0) все сильно изменилось. Теперь числа изменятся на десятичный порядок.
                        0
                        Из-за фрагментации у CDN-провайдеров шансы на использование кэш-памяти CDN являются низкими


                        — точка кипения, гы.
                          0
                          так поэтому и надо всем пользоваться cdnjs, не?
                          –4
                          В оригинале:
                          A network with download speeds of 1Mbps can download 125KB in a second, which means that for every 1 Mbps your mobile network provides, you can download 4.36 jQuery’s/second.
                          В Вашем переводе:
                          Сеть со скоростью загрузки 1 Мбит может скачивать 125 Кб в секунду, это означает, что за одну секунду вы можете скачать jQuery 4.36 раза.
                          И так далее по тексту… поправьте единицы измерения (Б=байт, б=бит).
                            0
                            А что если взять конкретный нужный нам скрипт, который использует jQuery, слить всё в один файл, скормить это дело в Google Closure, сжать gzip-oм и положить на сайт?

                            Лет 5-6 назад, когда jQuery был уже толстым, а Google Closure ещё не родился, я делал простенькую обертку над скриптами, которая компилировала все скрипты на странице в один сжатый gz-файлик и отдавала браузеру один раз. Сервер контролировал кэш, соответственно нормальные браузеры этот скрипт загружали и компилировали только 1 раз. Для браузеров без поддержки gzip (сейчас такие поискать надо) отдавалась просто минимизированная версия скриптов.
                              0
                              А я на Edge сижу, потому что 3G жрёт батарею. Может быть ради какого то особого сайта я включу 3G, но не рассчитывайте, что это будет ваш сайт. Edge это 2000+ пинг и скорость примерно 256 килобитов в секунду.

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

                              Самое читаемое