Створення високопродуктивних мобільних вебсайтів

13

Слово редактора: В цій статті відображено всього одне рішення з безлічі, що стосуються створення високопродуктивних мобільних вебсайтів. Ми пропонуємо вам ознайомитися з різними підходами, такими як Створення адаптивного веб-додатки (Building A Responsive Web App), Поліпшення мобільного підтримки (Improving Mobile Support) і Зробіть свій вебсайт швидше (Making Your Websites Faster) до того, як визначитися зі своїм вибором.

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

Ця стаття описує методи, що пояснюється Йоханом Йоханссоном (Johan Johansson) в його статті » Як зробити свої вебсайти швидше на мобільних пристроях (How to Make Your Websites Faster on Mobile Devices), опублікованій у квітні 2013р.

Ми покажемо способи розпізнавання того, як люди по-різному взаємодіють з вебсайтом на мобільних пристроях, і ті дизайнерські рішення, які можна зробити, зрозумівши дане явище. Наша мета – не тільки поліпшити веб-продуктивність, але і збільшити повернення інвестицій клієнта.

Техніки, які ми продемонструємо, базуються на двох унікальних характеристиках мобільних телефонів, які зміняться ще не скоро: малої ємності батареї і маленьких екранах.

МАЛЕНЬКА ЄМНІСТЬ БАТАРЕЇ

Для комунікації мобільні телефони використовують радіозв’язок, і у них батареї малої ємності, за яким потрібно уважно стежити, щоб ті не розрядилися. В результаті цього радіо дуже швидко відключається, коли не використовується, збільшуючи сприймане час появи веб-сторінки. 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.

// Напишіть файл реєстрації, що містить поточний час і розмір
// екрана запитувача пристрою в дюймах.
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 всередині нього.

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». Важливо, що рядок запиту і назва сторінки під час перенаправлення залишаються тими ж.

Як тільки завантажилася сторінка, застосовується JavaScript для підрахунку потрібних для зображення точних розмірів і запиту суворо масштабованого зображення з сервера. Після обробки JavaScript’а вищенаведений HTML перетвориться на це:

Створення високопродуктивних мобільних вебсайтів

Обробник зображення, на якого посилаються в web.config, співвідноситься з параметром рядка запиту I з джерелами зображення для застосування в якості відправної точки найкращого зображення для зміни розміру на сервері. Параметр рядка запиту w визначає ширину необхідного зображення. Не потрібно гарантувати надання безлічі зображень; майже так само добре спрацює і одне.

Цей підхід легко реалізувати, а його результатом стане зображення з точними розмірами, знижує споживання пропускної здатності, циклів центрального процесора мобільного телефону і енергії.

HTML

Повний Оксфордський тлумачний словник англійської мови містить 171 476 слів. Якби комп’ютера довелося уявити кожне слово як унікальне двійкове число, а не алфавітні літери, то знадобилося б 18 біт (або 3 байти, якщо округлити). Цей метод показує, чому алгоритми стиснення настільки ефективні.

Проте HTML не дуже результативний із-за того що сповнений слів, що позначають елементи, ID, класи, стилі і JavaScript, не вважаючи при цьому тих слів, які здатний прочитати людина. Стиснення їх зменшує, але вони залишаються непродуктивними витратами. Ось чому у популярних бібліотек мінімізовані версії, які здаються людині майже нечитабельним.

Крім того, деякі з таких пов’язаних з розміткою слів, не втративши їх сенсу, здатний мінімізувати сервер перед відсиланням на браузер. Якщо взяти вищенаведений приклад зображення, стандартним атрибутом HTML ID елемента зображення ASP.NET буде ImageBanner.

Проте в коді, відісланому браузеру, залишиться тільки B. Для окремого елемента виграш в продуктивності буде нікчемним, але складна сторінка з сотнями елементів буде передаватися швидше і браузер зможе все це обробити набагато швидше.

ВСТАВКИ-ІНКЛУД

Є в остаточному HTML наведеного прикладу зображення ще дещо трохи незвичайне.

Створення високопродуктивних мобільних вебсайтів

Код ASP.NET включає пропущений атрибут стилю, а для елемента img відсутній атрибут класу. Так як же застосовується стиль? Процес мінімізації серверної сторони ідентифікує інформацію про стилі і створить для сторінки вставку CSS, зменшуючи таким чином кількість HTML. Якщо HTML змінюється, то інформація про стилі вже буде кэширована в браузері і її не доведеться заново завантажувати. Фрагмент CSS виглядає так:

#B{clear:both;width:100%;}

Якщо у безлічі елементів одні стилі, то їх ID будуть додані в CSS, і ті стануть розділяти однакову інформацію.
Також за допомогою елемента стилю серверної сторони можна спільно використовувати для елементів сторінок і інформацію про стилях. Наступний код розширює попередній приклад зображення і показує елемент із загальним стилем.

Елементи можна поширити ще далі для застосування різних стилів, грунтуючись на можливості пристрою, і оптимізувати таблиці стилів для безлічі сторінок. Таким способом завжди можна гарантувати передачу тільки потрібного 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 методики, щоб гарантувати, що ваш вебсайт не очолить цей список!

Вам ще не надавалося більш вдалого випадку поліпшити його продуктивність.