Слово редактора: В этой статье отражено всего одно решение из множества, касающихся создания высокопроизводительных мобильных вебсайтов. Мы предлагаем вам ознакомиться с разными подходами, такими как Создание адаптивного веб-приложения (Building A Responsive Web App), Улучшение мобильной поддержки (Improving Mobile Support) и Сделайте свой вебсайт быстрее (Making Your Websites Faster) до того, как определиться со своим выбором.
Люди начинаю терять интерес к вебсайту, не получив от него ответа в течение трех секунд. Для удовлетворения ожиданий пользователей мобильных телефонов требуется иной подход к анализу пользования, дизайну и тестированию.
Эта статья подробно описывает методы, объясняемые Йоханом Йоханссоном (Johan Johansson) в его статье Как сделать свои вебсайты быстрее на мобильных устройствах (How to Make Your Websites Faster on Mobile Devices), опубликованной в апреле 2013г.
Мы покажем способы распознавания того, как люди по-разному взаимодействуют с вебсайтом на мобильных устройствах, и те дизайнерские решения, которые можно предпринять, поняв данное явление. Наша цель – не только улучшить веб-производительность, но и увеличить возврат инвестиций клиента.
Техники, которые мы продемонстрируем, базируются на двух уникальных характеристиках мобильных телефонов, которые изменятся еще не скоро: маленькой емкости батареи и маленьких экранах.
Бесплатный курс по PHP программированию
Освойте курс и узнайте, как создать веб-приложение на PHP с полного нуля
Получить курс сейчас!МАЛЕНЬКАЯ ЕМКОСТЬ БАТАРЕИ
Для коммуникации мобильные телефоны используют радиосвязь, и у них батареи маленькой емкости, за которым нужно внимательно следить, чтобы те не разрядились. В результате этого радио очень быстро отключается, когда не используется, увеличивая воспринимаемое время появления веб-страницы. 2G и 3G-радиосвязи может потребоваться до двух секунд, чтобы установить операционное HTTP-соединение. Если принять во внимание, что через три секунды пользователь начинает терять интерес, то для ответ вебсайту остается всего одна секунда. Считайте ее «золотой секундой».
Максимизация “золотой секунды”: две секунды на установление радиосвязи оставляют вашему вебсайту одну секунду на загрузку до момента потери 40% своих пользователей.
МАЛЕНЬКИЕ ЭКРАНЫ
В реальном мире контент производится для досок объявлений и журналов и изменяется в размере исходя из расстояния до наблюдателя. В цифровом мире у обычного среднего смартфона экран составляет примерно шесть дюймов. У MacBook Pro с 15-дюймовым дисплеем будет более 100 квадратных дюймов. Таким образом, можно не только оптимизировать производительность вебсайта путем снижения количества посылаемого на телефоны контента, но и оптимизировать бизнес-процессы для повышения возврата инвестиций владельцев вебсайтов.
Примеры кода в этой статье предоставлены в .NET. Там, где возможны эквиваленты в PHP, Java, C или Python, я сделал их доступными в сопроводительной статье. Причину применения .NET я объясню в конце этого текста.
Максимизация «золотой секунды»
Дизайнеры вебсайтов и разработчики с высокой пропускной способностью Wi-Fi и фиксированным соединением привыкли брать ширину полосы за само собой разумеющееся. Адаптивный веб-дизайн (RWD) ограничивает творческий процесс, заставляя представлять одно и то же содержимое, навигацию и бизнес-процессы на каждом устройстве вне зависимости от его физических возможностей.
Чтобы гарантировать легкое измерение производительности, поведение пользователей мониторов на основании характеристик устройства и оптимизировать устройства с маленькой шириной полосы, требуются решения для максимизации «золотой секунды».
ИМИТАЦИЯ РЕАЛЬНОСТИ
Очень существенным для тестирования веб-производительности мобильных устройств является метод имитации реальных условий мобильной пропускной способности. Многие беспроводные роутеры стоимостью менее $100 поддерживают ограничение ширины полосы. Это просто приводит к ограничению входящей и исходящей пропускной способности для клиентов локальной сети (LAN). Если роутер не поддерживает эту способность на «отлично», то можно использовать DD-WRT, прошивку с открытым исходным кодом для замены операционной системы по умолчанию на многих популярных роутерах для ограничения полосы пропускания.
Я пользуюсь роутером Linksys E3000, модифицированным DD-WRT. Процедура апгрейда роутера довольно проста и на вебсайте DD-WRT есть подробная инструкция.
Когда установлен DD-WRT, перейдите в меню “QoS” (качество линии) и включите ограничение полосы. Затем установите значения восходящей (uplink) и нисходящей (downlink) связи. Я предпочитаю 256 kbps для нисходящей и 28 kbps для восходящей с целью имитации среднего соединения мобильного устройства.
Ограничение полосы пропускания в настройках “QoS”.
Теперь пропускная способность любых устройств, соединенных с роутером по Wi-Fi или кабелем Ethernet, будет искусственно снижена. Также со временем можно отслеживать использование настоящей полосы пропускания.
Отслеживание пропускной способности при помощи DD-WRT.
Тогда как этот подход не предоставляет случайных падений, различных условий полосы пропускания или задержек, связанных с радио-связью, это лучше, чем делать тестирование на быстром широком соединении с малым временем ожидания. Будучи выполненным в начале цикла разработки вебсайта, это – легкий способ неформально протестировать производительность в течение процесса разработки и гарантировать, что во время официального тестирования не будет неприятных сюрпризов.
НЕЛЬЗЯ УПРАВЛЯТЬ ТЕМ, ЧЕГО НЕ МОЖЕТЕ ИЗМЕРИТЬ
Однажды консультант по управлению Питер Дракер (Peter Drucker), сказал знаменитую фразу: «Если не можете что-либо измерить, то не можете этим управлять».
Средний рост размера экрана с течением времени.
Непрерывно отслеживая просматриваемый пользователями контент согласно характеристикам устройств (таким как поддерживаемая радиосвязь или физический размер экрана), вы сможете идентифицировать содержимое и услуги, более или менее популярные на мобильных телефонах. Возможно, вы не увидите разницы, но пока вы ее не измерите, не узнаете точно.
НАКОРМИ МЕНЯ СЕЙЧАС ЖЕ: ПРИМЕР
Всемирная фастфуд-франчайзи собралась создать версию своего широкоэкранного вебсайта, оптимизированную под мобильные устройства. Перед первым этапом создания сайта они провели анализ для определения того, к каким опциям широкоэкранного вебсайта получали доступ пользователи маленьких устройств. Самыми популярными оказались главное меню, специальные предложения и поиск по магазину, и поэтому оптимизация мобильного вебсайта была создана с целью сосредоточения на данных областях.
На этом работа не остановилась. Последующий анализ обнаружил, что самой популярной опцией был поиск по магазину. Мобильную домашнюю страницу снова перекроили под него. Непрерывный мониторинг покажет, сколько пользователей выбирают другие опции, и сайт продолжит постоянно оттачиваться для того, чтобы удовлетворить самый популярный спрос самым простым возможным способом.
УЛУЧШЕНИЕ РЕГИСТРАЦИИ
Google Analytics дает некоторую информацию о модели устройства, но нам недостает необходимых деталей для принятия обоснованного решения на основании размера экрана и метода ввода. К счастью, можно использовать обширное хранилище определения устройств (DDR) и добавить эту информацию в уже существующие файлы регистрации. Можно внести в вебсайт .NET следующий фрагмент кода, получить физические размеры экрана в дюймах и записать полученные данные в простом файле CSV.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
// Напишите файл регистрации, содержащий текущее время и размер // экрана запрашивающего устройства в дюймах. File.AppendAllText( Path.Combine( AppDomain.CurrentDomain.BaseDirectory, String.Format( "App_Data\\Simple_Log_{0:yyyyMMdd}.csv", DateTime.UtcNow)), String.Format("{0:s},{1},{2},{3}\r\n", DateTime.UtcNow, Request.Path, Request.Browser["ScreenInchesWidth"], Request.Browser["ScreenInchesHeight"])); |
Первая колонка – это дата и время, когда был выполнен запрос. Вторая – запрашиваемая страница. Две последних колонки – ширина и высота в дюймах. Как только получено достаточное количество данных, можно подсчитать средний размер экрана в квадратных дюймах и выразить его в графике, как в следующем примере:
Сравнение средних размеров экранов устройств за 20 месяцев.
Анализ можно ограничить отдельными страницами. В качестве колонок попробуйте добавить прочие характеристики устройства, операционной системы и браузера.
Похожий код можно использовать в PHP, Java, Python и других средах.
СУЩЕСТВУЮЩИЕ ФАЙЛЫ РЕГИСТРАЦИИ
Иногда невозможно переделать подобным образом существующие веб-страницы. В таких ситуациях примените DDR для представления оффлайн-анализа файлов регистрации, содержащих агенты пользователя. Следующий код .NET – это функциональная программа командной строки, анализирующая разделенный пробелами файл регистрации и считающая для своих запросов средний размер экрана в квадратных дюймах. Первый аргумент – это местонахождение файла, второй – указатель колонки UserAgent внутри него.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 |
using System; using FiftyOne.Foundation.Mobile.Detection.Binary; using System.IO; namespace ConsoleApplication { class Program { static void Main(string[] args) { // Количество устройств, считываемых с файла регистрации. int count = 0; // Колонка в файле ввода, где содержится агент пользователя. int column = int.Parse(args[1]); // Переменные размера экрана. double total = 0, width, height, squareInches; // Создайте провайдера для определения возможностей устройства. var provider = Reader.Create("51Degrees.mobi.dat"); // Прочтите каждую строку файла регистрации, предоставленного в аргументе 0. // Допустите, что значение в колонке 8 – это строка UserAgent. using (var reader = File.OpenText(args[0])) { while(reader.EndOfStream == false) { var values = reader.ReadLine().Split(new[] { ' ' }); if (values.Length >= column) { // Получите информацию об устройстве на основе UserAgent. var device = provider.GetDeviceInfo( values[column - 1].Replace("+", " ")); if (device != null) { // Определите размеры экрана в дюймах. double.TryParse( device.GetFirstPropertyValue("ScreenInchesWidth"), out width); double.TryParse( device.GetFirstPropertyValue("ScreenInchesHeight"), out height); squareInches = width * height; // Если доступны надежные значения (не desktop/laptop), // то добавьте значения к результатам. if (squareInches > 0) { total += squareInches; count++; } } } } } Console.WriteLine( "Average screen size '{0:#.00}' square inches from '{1}' devices", total / count, count); Console.ReadKey(); } } } |
Анализ файлов регистрации менее точен, потому что на результаты детекции заголовки-сообщения HTTP влияют по-другому, чем User-Agent. Это особенно верно для браузеров Opera Mini и Opera Mobile, где информацию о физическом оборудовании, недоступную в стандартном User-Agent, предоставляет второй заголовок HTTP под названием Device-Stock-UA.
ЗАЧЕМ МОНИТОРИТЬ?
Мониторинг дает нам возможность удалять непопулярный контент с целевых страниц, улучшая таким образом производительность более важного и значимого содержимого. Удаленный контент все же должен оставаться доступным на второстепенных страницах — просто не размещайте его на целевых, где он отъест ценную пропускную способность и замедлит производительность.
Итак, как создать отдельный мобильный вебсайт, оптимизированный для производительности?
РАЗДЕЛЯЙ И ВЛАСТВУЙ
Я понимаю, почему с точки зрения пользовательского интерфейса адаптивный вебдизайн имеет большой смысл. Он отлично подходит для тех ситуаций, когда содержимое, навигация и требования бизнес-процесса идентичны для экранов в 6 и в 100 квадратных дюймов, и переделка требуется только для разметки.
Средний размер экрана устройств.
Тем не менее, специальный мобильный вебсайт имеет смысл, когда вышеуказанные условия неточны или когда очень важна производительность.
Отдельные мобильные сайты часто выполняются таким образом, что производят на своих пользователей плохое впечатление. Google сейчас освещает эти проблемы, наказывая сайты с низкой оценкой в поисковых системах. Ошибки включают в себя отправку каждой десктопной страницы на одну мобильную домашнюю страницу, перенаправление на страницы загрузки приложений, невозможность перехода к широкоэкранному вебсайту и одинаковая обработка всех устройств с определенной операционной системой.
Такие примеры некачественной реализации бросают тень на всю концепцию. Вот как делать это просто и правильно.
Следующий раздел .NET web.config перенаправит первый запрос со смартфона на эквивалентную страницу в разделе вебсайта — “Smartphone”. Важно, что строка запроса и название страницы во время перенаправления остаются теми же.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
<redirect firstRequestOnly="true" mobileHomePageUrl="~/Mobile/Default.aspx" timeout="20" devicesFile="~/App_Data/Devices.dat" mobilePagesRegex="/(Mobile|Smartphone)/" > <locations> <!—Пошлите смартфоны на эквивалентную версию исходной страницы, сохраняя ее название и строку запроса.--> <location name="smartphone" url="~/Smartphone/{0}" matchExpression="(?<=^\w+://.+/).+"> <add property="IsSmartphone" matchExpression="true"/> </location> </locations> </redirect> |
В большинстве случаев при перенаправлении на альтернативные страницы пользователи должны иметь возможность при желании вернуться на исходную страницу; возможно, они лучше знакомы с широкоэкранной версией вебсайта. Атрибут firstRequestOnly гарантирует, что перенаправляться будет только первый запрос с устройства. Атрибут devicesFile применяется для отслеживания тех устройств, на которых не поддерживаются куки. Атрибут timeout контролирует то, сколько времени устройство сохраняется в памяти (с целью перенаправления).
Система перенаправления также должна знать, какие страницы созданы для каких видов устройства. Атрибут mobilePagesRegex применяется к запрошенным URL’ам. Если находится соответствие, то страница не подлежит перенаправления. Так предотвращаются случаи бесконечных перенаправлений.
Бесплатный курс по PHP программированию
Освойте курс и узнайте, как создать веб-приложение на PHP с полного нуля
Получить курс сейчас!Элемент locations позволяет конфигурировать различные места и связанные с этим правила. В примере папка Smartphone вставляется в исходный URL. Во время перенаправления строка запроса и прочая информация об URL сохраняются. Должна передаваться вся информация, влияющая на контекст запроса, для того, чтобы пользователь получил ожидаемый контент.
Этот простой подход дает возможность доставки дружественного к поисковому движку, совместимого с Google, оптимизированного под мобильный телефон вебсайта с превосходной производительностью, создающего у пользователя хорошее впечатление. Для процесса очень важна удвоенная скорость передачи данных, быстрое и постоянное предоставление точной информации об устройстве. Уважим пользователей, меняющих установки браузера своего мобильного телефона на серфинга в режиме настольного компьютера – перенаправления не случится.
ОСТОРОЖНО, ОБЛАКА!
«Облачные» сервисы – популярный способ добавления возможностей вебсайту. Но они создают помехи производительности, постоянно отвлекаясь на Интернет. Даже не принимая во внимание время обработки, при передаче данных с «облачных» сервисов, расположенных в хостинге Amazon Web Service, мы наблюдали среднюю задержку в 200 миллисекунд.
200 миллисекунд – это 20% «золотой» секунды. Следовательно, тщательно обдумайте применение облачных сервисов, гарантируйте их асинхронный вызов для возможности продолжения выполнения других процессов во время ожидания ответа. Их следует избегать при работе, принадлежащей критическому пути, такой как определение информации о запрашивающем устройстве.
Прессуем содержимое
После видео, изображений, CSS и HTML сделайте большой массив веб-трафика. Нам нужны способы оптимизации их всех. Видео – это такая вещь, которой придется подождать следующего раза.
ИЗОБРАЖЕНИЯ
Популярное решение – обеспечивать три версии одного и того же изображения и выбирать из них самое лучшее для запрашивающего устройства с помощью JavaScript’а или CSS3 во время отображения браузером страницы. Это хорошо, но управлять разными версиями одного изображения сложно; оно никогда не оптимизируется идеально, а метод возлагает все бремя масштабирования на ограниченный центральный процессор мобильного устройства и батарею.
Есть более удачный способ – применение оптимизатора изображений. У него множество отличных возможностей; если соберетесь пользоваться нашим собственным оптимизатором, то можете добавить его в вебсайт ASP.NET посредством интерфейса Visual Studio. В web.config будет автоматически добавлена следующая конфигурация.
|
1 2 3 |
<handlers> <add name="Image" verb="GET" path="P.axd" type="FiftyOne.Framework.Image.ImageHandler, FiftyOne.Framework" /> </handlers> |
Обработчик говорит информационным службам Internet (IIS), что обработчик изображений должен выполнять любые GET- запросы к ресурсу P.axd. Будучи включенным в web.config, следующий ниже код ASP.NET станет применять оптимизатор изображений для определения элемента изображения с тремя возможными источниками — шириной соответственно в 240, 480 и 640 px.
|
1 2 3 4 5 |
<mob:Image runat="server" ID="ImageBanner" CalculateSizeMode="ClientWidth" Style="clear: both; width: 100%"> <mob:AltImage ImageUrl="~/Images/Landscape240.png" /> <mob:AltImage ImageUrl="~/Images/Landscape480.png" /> <mob:AltImage ImageUrl="~/Images/Landscape640.png" /> </mob:Image> |
При начальной визуализации изображения сервер посылает белый GIF размером 1 × 1 px, чтобы тот появился на месте изображения. Вот окончательный HTML:
|
1 |
<img id="B" src="P.axd?i=E.gif&i=1"/> |
Как только загрузилась страница, применяется JavaScript для подсчета требующихся для изображения точных размеров и запроса строго масштабированного изображения с сервера. После обработки JavaScript’а вышеприведенный HTML превратится в это:
|
1 |
<img id="B" src="P.axd?i=1&w=500"/> |
Обработчик изображения, на которого ссылаются в web.config, соотносится с параметром строки запроса I с источниками изображения для применения в качестве отправной точки самого лучшего изображения для изменения размера на сервере. Параметр строки запроса w определяет ширину требуемого изображения. Не нужно гарантировать предоставление множества изображений; почти так же хорошо сработает и одно.
Этот подход легко реализовать, а его результатом станет изображение с точными размерами, снижающее потребление пропускной способности, циклов центрального процессора мобильного телефона и энергии.
HTML
Полный Оксфордский толковый словарь английского языка содержит 171 476 слов. Если бы компьютеру пришлось представить каждое слово как уникальное двоичное число, а не алфавитные буквы, то потребовалось бы 18 бит (или 3 байта, если округлить). Этот метод показывает, почему алгоритмы сжатия настолько эффективны.
Однако HTML не очень результативен из-за того что полон слов, обозначающих элементы, ID, классы, стили и JavaScript, не считая при этом тех слов, которые способен прочесть человек. Сжатие их уменьшает, но они остаются непроизводительными издержками. Вот почему у популярных библиотек минимизированные версии, которые кажутся человеку почти нечитаемыми.
Кроме того, некоторые из таких связанных с разметкой слов, не потеряв их смысла, способен минимизировать сервер перед отсылкой на браузер. Если взять вышеприведенный пример изображения, стандартным атрибутом HTML ID элемента изображения в ASP.NET будет ImageBanner.
|
1 |
<mob:Image runat="server" ID="ImageBanner" CalculateSizeMode="ClientWidth" Style="clear: both; width: 100%"> |
Однако в коде, отосланном браузеру, останется только B. Для отдельного элемента выигрыш в производительности будет ничтожным, но сложная страница с сотнями элементов будет передаваться быстрее и браузер сможет все это обработать гораздо скорее.
ВСТАВКИ-ИНКЛУДЫ
Есть в окончательном HTML приведенного примера изображения еще кое-что слегка необычное.
|
1 |
<img id="B" src="P.axd?i=1&w=500"/> |
Код ASP.NET включает пропущенный атрибут стиля, а для элемента img отсутствует атрибут класса. Так как же применяется стиль? Процесс минимизации серверной стороны идентифицирует информацию о стиле и создаст для страницы вставку CSS, уменьшая таким образом количество HTML. Если HTML меняется, то информация о стиле уже будет кэширована в браузере и ее не придется заново скачивать. Фрагмент CSS выглядит так:
|
1 |
#B{clear:both;width:100%;} |
Если у множества элементов одни стили, то их ID будут добавлены в CSS, и те станут разделять одинаковую информацию.
Также с помощью элемента стиля серверной стороны можно совместно использовать для элементов и страниц информацию о стилях. Следующий код расширяет предыдущий пример изображения и показывает элемент с общим стилем.
|
1 2 3 4 5 |
<mob:Style runat="server" ID="StyleBanner"> <mob:Filter Style="clear: both; width: 100%"/> </mob:Style> <mob:Image runat="server" ID="ImageBanner" CalculateSizeMode="ClientWidth" StyleID="StyleBanner"> |
Элементы можно распространить еще дальше для применения разных стилей, основываясь на возможностях устройства, и оптимизировать таблицы стилей для множества страниц. Таким способом всегда можно гарантировать передачу только нужного CSS, улучшая производительность при последующих запросах к одной странице, особенно там, где в содержимом HTML имеются только небольшие различия.
ПОЧЕМУ .NET?
Техники и примеры кода оптимизации изображений и динамического уменьшения содержимого HTML и CSS полагаются на то, что содержимое меняется после визуализации страницы, но перед передачей сервером в браузер. Такие препроцессорные методики сравнительно легко реализуются в такой архитектуре, как ASP.NET Web forms.
Однако их гораздо сложнее выполнить в скриптовых архитектурах, таких как PHP. По этой причине примеры этой статьи для последовательности приведены в .NET. Где мне удалось применить техники к другим языкам, примеры кода выложены в сопровождающем блоге.
Примеры
Компании Фонда здравоохранения реализовали приведенные в этой статье техники и получили 23% увеличение успешных результатов в течение первой же недели.
Прочие сведущие в производительности вебсайты — включая 24.com (СМИ), ServiceTick (аналитика), LettingWeb (недвижимость), AdSupply (реклама) и Kitsap Credit Union (финансы) — все оптимизированы под мобильные устройства и пользуются некоторыми из раскрытых в этой статье методик.
Заключение
Для истинной оптимизации производительности нам нужно обдумать возврат инвестиций владельцу вебсайта. И насущной отправной точкой становится мониторинг различий в характеристиках устройств.
Затем можно развернуть такие решения, как применение отдельных мобильных вебсайтов для разделения или изменения доминанты контента. И можно выжать максимальную производительность из мобильных телефонов путем минимизации изображений и HTML, удаления jQuery, исследования того, когда следует применять только адаптивный вебдизайн, и использования прочих методов. Конечно, очень важны уже упрочившиеся методы, такие как конфигурирование директив кэширования и сжатие контента.
Подстройка среды разработки для имитации условий реального мира во время процесса разработки также приводит к лучшему пониманию производительности.
ОПТИМИЗИРУЙТЕ СЕЙЧАС
Чтобы дать вам еще подумать о производительности, я устроил конкурс на самый тяжелый в мире вебсайт. Отыщите плохо выполняемую на мобильном телефоне страницу и представьте ее на конкурс. Мы выясним вес страницы, и если он окажется самой тяжелой, вы получите $1000. Тем временем, пока мы обмениваемся мнениями о производительности, реализуйте раскрытые в этой и других статьях Smashing Magazine методики, чтобы гарантировать, что ваш вебсайт не возглавит этот список!
Вам еще не предоставлялось более удачного случая улучшить его производительность.
Автор: James Rosewell
Источник: //mobile.smashingmagazine.com/
Редакция: Команда webformyself.
Бесплатный курс по PHP программированию
Освойте курс и узнайте, как создать веб-приложение на PHP с полного нуля
Получить курс сейчас!
Разработка веб-приложения на PHP
Скачайте видеокурс и узнайте, как создать веб-приложение на PHP
Скачать
