Я думаю, для этой статьи пришло время, особенно учитывая недавний доклад Keynone, согласно которому 64% пользователей смартфонов ждут загрузки сайта 4 секунды или меньше. Результаты исследования сюрпризом не стали. Ведь еще предыдущие результаты показывали, что люди считают, что сайты должны загружаться на их мобильные устройства с той же скоростью, что и на полноформатные компьютеры. Однако, это является тревожным звоночком для тех владельцев сайтов, кто по-прежнему пребывают в состоянии ленного благодушия. (Хотя, учитывая, какой сейчас месяц, все мы еще не отошли от летней безмятежности.)

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

• Снижение числа HTTP-запросов, необходимых для поставки ресурсов для каждой страницы.
• Снижение размера пакетов, необходимых для выполнения каждого из запросов.
• Оптимизация приоритетов обработки со стороны клиента и эффективности выполнения скриптов.

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

• Более медленные сети (именно поэтому так важно снижение числа запросов и размера пакетов).
• Мобильные браузеры медленнее оперируют HTML и медленнее выполняют JavaScript (поэтому оптимизация клиентской обработки невероятно важна).
• Кэш мобильного браузера много меньше, чем у полноформатных компьютеров (что требует новых подходов для увеличения локального хранилища повторно используемых ресурсов).

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

СОКРАЩАЕМ ЗАПРОСЫ

Консолидация ресурсов

Теперь это уже стандартная практика, так что я не собираюсь подробно расписывать ее здесь. Однако, хочу заметить, что консолидация ресурсов может быть для мобильных браузеров палкой о двух концах. Снижение числа запросов, может повысить скорость загрузки страницы, однако крупные блоки ресурсов не смогут быть кэшированы эффективно. Так что, при использовании этой техники, постарайтесь соединить ее с методикой оптимизации LocalStorage (она идет следующим пунктом).

Использование кэша браузера и LocalStorage

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

Встраивание разово используемых ресурсов в HTML

Если вероятность кэширования определенного ресурса не велика (в контексте мобильных), лучшим вариантом часто становится встраивание его в HTML страницы — техника, называемая «инлайнинг» — вместо хранения его отдельно и вызова по ссылке.

Недостатком инлайнинга является размер страницы, который может стать очень большим. Поэтому, для веб-приложений, использующих данную технику, крайне важно быть способными определять, какой из ресурсов нужен, а какой уже кэширован клиентом. Вдобавок, приложение должно генерировать клиентский код для хранения ресурса, после его первой инлайн-отправки. Именно поэтому использование LocalStorage HTML5 в мобильных устройствах (как уже было сказано) является отличным дополнением к инлайнингу.

Использование Server- sent в HTML5

Объекты EventSource и Server-Sent в HTML5 позволяют JavaScript-коду браузера открывать гораздо более эффективный канал, соединяющий сервер с браузером, который сервер может затем использовать для отправки данных по мере их поступления, ликвидируя тем самым перегруженность HTML от создания множественных повторяющихся запросов.

Избавление от переадресации

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

УМЕНЬШЕНИЕ ПАКЕТОВ

Сжатие и минимализация

Сжатие и минимализация являются лучшими базовыми методами. Технологии сжатия, такие как gzip, снижают загрузку, текстовые ответы сервера, включая HTML, XML, JSON, JavaScript и CSS, могут быть уменьшены с их помощью на 70%. Минимализация, применяемая обычно лишь к скриптам и таблицам стилей, удаляет ненужные знаки, такие как пробелы и символы перехода на новую строку; минимализированные файлы теряют в среднем 20% от своего размера.

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

Масштабирование изображений

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

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

Упрощение страниц с помощью HTML5 и CSS 3.0

Спецификации HTML5 включают новые структурные элементы, такие как header, nav, article, and footer. Использование этих семантических элементов позволяет создавать более простые и упорядоченные страницы, не прибегая к вездесущим тегам div и span. Упрощенные страницы занимают меньший объем и быстрее загружаются, также более простая объектная модель документа (DOM) означает ускоренное выполнение JavaScript. Новые теги были быстро усвоены большинством новых браузеров, включая мобильные версии. Максимилиано Фиртман создал превосходную таблицу, демонстрирующую какие из функций HTML5 поддерживаются компьютерными и мобильными браузерами.

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

ОПТИМИЗАЦИЯ РАБОТЫ КЛИЕНТА

Отсрочка визуализации HTML

Мобильные устройства, пытаясь одновременно загрузить и визуализировать страницу с большим объемом HTML, работают медленнее чем, когда сначала загружают страницу, а уже потом визуализируют. Одним из способов осуществления этого заключается в том, чтобы поместить HTML в тег комментария и затем использовать JavaScript, чтобы удалить комментарий, загрузить DOM и визуализировать страницу.

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

Отсрочка загрузочных и исполняемых скриптов

Парсинг JavaScript на некоторых мобильных устройствах может отнимать до 100 миллисекунд за каждый килобайт кода. Многие библиотеки скриптов (например, тех, что поддерживают интерактивные функции, такие как перетаскивание) не нужны до тех пор, пока страница полностью не визуализируется. Загрузка и исполнение этих скриптов может быть отложена до определенного момента. То же касается и исполняемых скриптов. Откладывайте как можно больше их до момента окончания загрузки основных элементов.

Отложенный скрипт может быть созданным вами или сторонними разработчиками. Слабооптимизированные скрипты для рекламы, соцмедиа виджетов или сбора аналитики могут полностью блокировать визуализацию страницы, порой добавляя целые секунды ко времени загрузки. Вам также следует осторожно относиться к использованию в своих мобильных сайтах больших наборов скриптов, таких как jQuery, в особенности, если вы используете лишь несколько объектов из них.

Использование Ajax для прогрессивного улучшения

Асинхронный JavaScript с XML (AJAX) — это техника использования объекта XmlHttpRequest для передачи данных с веб-сервера без обновления страницы, на которой исполняется код. AJAX позволяет демонстрировать на участке страницы обновляемые данные без необходимости перестраивать всю ее целиком. Это может позволить вашему приложению быстро загрузить каркас страницы и наполнять ее более детальным контентом в то время, как пользователь уже начнет ее просматривать.

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

Использование умной предварительной загрузки, адаптирующейся к типу сетевого соединения

Некоторые из техник должны использоваться лишь вместе с кодом для определения типа мобильного соединения. К примеру, предварительная загрузка ресурсов в ожидании будущих запросов — это хорошо, однако стратегия не оправдывает себя, если (1) пользователь платит за трафик или (2) некоторые из этих ресурсов могут не понадобиться.

На Android 2.2+ свойство navigator.connection.type возвращает значение, позволяющее вам отличить WiFi от 2G/3G/4G подключения. На Blackberry вы можете проверить значение blackberry.network для получения той же информации. Вдобавок, серверное определение User Agent данных заголовка или другой информации, включенной в запрос, может сообщить вашему приложению о типе используемого соединения.

Использование многопоточности HTML5 Web Workers

Спецификации HTML 5 Web Worker вносят многопоточное единовременное выполнение задач в мир JavaScript программирования. В плане улучшения производительности мобильных сайтов, код Web Worker может быть использован для предварительной загрузки ресурсов, которые могут понадобиться пользователю для завершения будущих действий, в особенности, когда траффик пользователя не тарифицируется. При использовании многопоточного кода, оперирующего объектами Web Workers (и, вероятно, LocalStorage для кэширования данных), предварительная загрузка ресурсов может осуществляться в несколько раздельных потоков, без снижения производительности операций пользовательского взаимодействия.

Замена событий «click» на «touch»

На устройствах с сенсорными экранами событие onclick не запускает операцию немедленно. Вместо этого, устройство ожидает почти полсекунды (300 миллисекунд на большинстве устройств), давая пользователю возможность выполнить другой, отличный от клика жест. Эта задержка может снизить ожидаемую пользователем производительность. Дабы избежать этого, используйте событие touchend. Оно начинает выполнение операции немедленно после прикосновения пользователя к экрану.

Вы по-прежнему можете использовать onclick, когда хотите, чтобы браузер менял внешний вид кнопки в нажатом состоянии или чтобы обеспечить поддержку браузеров, не работающих с событием touch. Чтобы избежать дублирования исполняемого кода в случае единовременного запуска кода touchend и onclick, добавьте preventDefault и stopPropagation если клик стал результатом повторного прикосновения пользователя к экрану во время выполнения touchend.

Поддержка протокола SPDY

Некоторые спады производительности, характерные для любого сайта, будь он полноформатный или мобильный, возникают вследствие неэффективности выполнения протоколов HTTP и HTTPS. В 2009 году компания Google начала работу над альтернативным протоколом под названием SPDY, призванным устранить многие из этих ограничений. По мере появления серверов, поддерживающих SPDY, ваш сайт сможет использовать этот протокол для любых пользователей, чьи браузеры поддерживают его. По результатам тестов показатели Google SPDY в среднем на 27-60% процентов выше стандартных.

Как и предупреждали, мы дали лишь общий обзор стратегий мобильной оптимизации. Если вас интересует более детальная информация, а также практические рекомендации, ознакомьтесь с  руководством по оптимизации от Strangeloop.

Джошуа Биксби является президентом Strangeloop, бюро, предлагающего решения по оптимизации веб-сайтов и сотрудничающего с такими компаниями как eBay/PayPal, Visa, Petco, Wine.com, и O’Reilly Media. Также Джошуа ведет собственный блог Web Performance Today,где рассказывает о возможностях и новых идеях оптимизации и ускорения работы сайтов, а также шаблонах поведения пользователей.

Оригинал: http://www.speedawarenessmonth.com/15-things-for-making-your-site-faster-for-mobile-users/

Дмитрий Логинов
Управляющий партнер в "Четвертый Рим"

Статья очень информативна, спасибо. Хотелось бы добавить, что вкупе с технологиями следует отдельное внимание уделять дизайну мобильной версии сайта. На всех этапах разработки нужно расставлять приоритеты, какие блоки являются самыми важными для пользователя. Возможно, от чего-то в мобильной версии нужно отказываться — например, скрывать тяжеловесную графику или рекламу. Когда приоритеты расставлены, технологии станут по-настоящему эффективным инструментом.

Артур Кротов
Технический директор в Nimax

Хорошая статья, её можно использовать как шорт-лист того, что может быть сделано, если тесты показывают низкую производительность мобильного, да и, пожалуй, настольного, сайта. Однако хочется предостеречь желающих внедрить подобный перечень как чек-лист. При оптимизации сайта нужно брать не количеством, а качеством, оценивая плюсы и минусы каждого внедряемого метода. Боюсь, что если использовать все методы, перечисленные в статье, местами результат может быть отрицательным, ведь половина методов нагружают сайт скриптами, с которыми борется другая половина, а некоторые пункты — например замена тегов в пункте № 8 — не несут практической пользы для упрощения DOM-дерева или объема документа, а предназначены скорее для улучшения разметки с точки зрения семантики.

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

И самое главное в оптимизации — и то, про что, к сожалению, практически не упомянуто в статье — метрики. Без сбора и оценки «узких мест» сайта оптимизация напоминает стрельбу с закрытыми глазами: если с десятого выстрела и попадешь в цель, то только благодаря удаче.

В заключение хотелось бы привести пример, когда не затронутый в статье параметр redraw — процесс отрисовки и перерисовки элементов страницы — очень сильно сказывался на производительности. В одном из наших проектов, Интер Авто Тим, есть страница со списком элементов. Число этих элементов в отдельных случаях может достигать десятков штук. На каждый элемент средствами CSS3, предлагаемыми этой статьей в качестве оптимизации, наложена тень и градиент. Большинство тестируемых устройств, например, последние iPhone, iPad и устройства на OC Android показали хорошую производительность, однако в первых версиях iPhone отрисовка этого списка достигала десятков секунд. Конечно, как только причина была установлена, проблему быстро решили. Используй мы слепо способы из данной статьи — проблема осталась бы актуальной и по сей день.

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