Адаптация дизайна (конкретный случай)

Адаптация дизайна

От автора: Это – история того, чему мы научились во время переделки дизайна для нашего самого требовательного клиента — самих себя! В этой статье из собственного опыта обновления вебсайта нашего агентства я объясню, почему мы забросили отдельный мобильный сайт, и сделаю обзор процесса создания нового адаптивного дизайна.

У себя в Cyber-Duck на протяжении уже нескольких лет мы делали сразу и адаптивные вебсайты, и адаптивные мобильные сайты. Оба варианта, конечно, имеют свои «за» и «против». На отдельном мобильном вебсайте есть возможность приспосабливать к контексту своих пользователей содержимое и даже взаимодействие, тогда как адаптивный вебсайт означает лучшее контентное равенство для пользователей и поддержку единственного вебсайта.

Зачем адаптировать дизайн?

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

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

Мы специально создали планшетный и мобильный сайты, помня о пользователях этих устройств — наибольшим приоритетом для нас была производительность. Мы хотели значительно улучшить время загрузки своего настольного вебсайта; домашняя страница для десктопов весила 2,2 MB при 84 HTTP-запросах, да и мобильная все еще была великовата – 700 KB при 46 HTTP-запросах. Также мы создали дизайн интерфейсов специально под сенсорный ввод, применив jQuery Mobile для улучшения впечатления своего пользователя.

СМЕНА ПОДХОДА

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

Необходимости поддержки множества баз исходных текстов,

Управления контентом,

Появления новых мини-планшетов и фаблетов.

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

Мы хотели сделать свой новый вебсайт легким в поддержании и более future-friendly к неизбежному притоку новых форм-факторов.

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

ОПРЕДЕЛЕНИЕ ЦЕЛЕЙ АДАПТИВНОГО ДИЗАЙНА

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

Скорость. Производительность влияет на всех.

Доступность. Должен работать без стилей, фонов или JavaScript’а.

Равенство контента. Во всех платформах должны присутствовать одинаковый контент и функциональность.

Аппаратная независимость. Не оставлять платформы.

Future-friendly. Сократить поддержание.

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

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

Кроме того, мы воспользовались аналитическими данными своего предыдущего вебсайта, применив смесь Google Analytics, Lead Forensics и CrazyEgg, чтобы лучше разобраться в том, чего хотят реально существующие пользователи и что им нужно от нашего вебсайта. В результате нам удалось облечь в форму и назначить приоритеты стратегии контента на базе того, как наши пользователи в действительности взаимодействуют с сайтом.

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

Приоритет отдается производительности

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

Для достижения этой цели мы определили функциональный бюджет — набор целей для улучшения скорости и размера своего нового вебсайта. Для мобильных пользователей нам был нужен такой сайт, который выполнялся бы по меньшей мере как наш существующий мобильный сайт; то есть, для мобильной контрольной точки нам нужно было загружать не более 40 HTTP-запросов и 500 KB данных. (Это только для начала. Следующим шагом было снижение этого объема менее чем до 100 KB.)

СТОРОННИЕ СКРИПТЫ

Самой простой способ срезать жирок – как можно больше оголить сторонние скрипты. Согласно Zurb, «под загрузку кнопок социальных сетей Facebook, Twitter и Google за общее количество в 19 запросов занимается 246,7 KB пропускной способности». В результате мы заменили тяжелые плагины социальных сетей на легковесные ссылки на них.

Замена тяжелых сторонних кнопок социальных сетей простыми ссылками на эти сети может значительно снизить количество HTTP-запросов и время загрузки страницы.

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

БЫЛА ЛИ CMS НУЖНА НА САМОМ ДЕЛЕ?

Ранее при обсуждении требований к новому вебсайту мы обдумывали, нужна ли нам вообще система управления контентом (CMS). Ведь, как и ожидается от цифрового агентства, члены команды по большей части знакомы с HTML, CSS и Git, так что мы определенно могли справиться с содержимым и без CMS.

Воспользовавшись серверными инструментами мониторинга производительности, такими как New Relic, можно было видеть, что наша предыдущая CMS стала ключевым фактором медленной загрузки страниц. Так что было принято весьма радикальное решение о полном удалении CMS с нашего вебсайта. Сделали исключение мы только для блога, которому для эффективного управления из-за объема и частоты публикуемого контента все еще требовалась CMS.

Предыдущая домашняя страница запрашивала сервер базы данных 1,459 раз за общее время выполнения в 2,34 секунды.

Наш старый вебсайт был построен на архитектуре model-view-controller’а (MVC), соединявшейся с CMS WordPress. Для примера – обычная страница с WordPress использует для своей загрузки от 600 до 1500 запросов; сервер базы данных запрашивается сотни раз, а просто удалив CMS нам одним махом удалось снизить это количество до нуля.

Команда разрабатывала прототипы, чтобы видеть пути улучшения производительности и адаптивности.

Удалив CMS для статических страниц, мы устранили необходимость в базе данных и динамических шаблонах. С помощью популярного каркаса PHP Laravel мы реализовали пользовательскую систему «динамического маршрута и статического шаблона». Это означает, что каждый раз при вызове URL’а на нашем вебсайте маршрутизатор Laravel точно знает, какой шаблон загружать, сопоставив URL с его названием, а в шаблоне весь контент уже статично разложен в HTML.

В результате этого единственного действия нам удалось улучшить время обработки вебсайта более чем на 3900%. Если взять за пример домашнюю страницу, в среднем мы улучшили серверную скорость с 2,2 секунд до 56 миллисекунд.

Серверная скорость обработки теперь всего 56 миллисекунд при нуле запросов к базе данных — примерно в 40 раз быстрее, чем была.

Естественно, такой подход не всех устраивает (и многих наших клиентов, на самом деле), но в начале любого проекта следует спросить себя, какая CMS подходит больше всего, и нужна ли она вообще. Конечно, существуют и другие возможности, включая CMS на файловой основе, такие как Kirby и Statamic, построение или приспосабливание легковесных CMS, таких как Perch, или просто применение лучшего кэширования на серверной стороне, например, с помощью Varnish.

В конце концов мы решили удалить CMS, потому что даже самая легковесная из них и хорошо оптимизированная с «умным» кэшированием имеет свой потолок и не может сочетать производительность и серверное пространство статических файлов.

ИЗБЕЖАНИЕ ГОТОВЫХ КАРКАСОВ CSS

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

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

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

По часовой стрелке начиная сверху: Разметка из трех колонок для десктопа становится одной колонкой в мобильном устройстве и пользуется преимуществом дополнительного пространства на «таблетках» путем смещения изображения влево от контента.

@media only screen and (min-width: 120px) and (min-device-width: 120px) {

   // Применяет мобильную сетку
   .container {
      width: 100%;
   }
   .col12, .col11, .col10, .col9, .col8, .col7, .col6, .col5, .col4, .col3 {
      width: 92%;
      margin: 0 4% 20px 4%;
   }
   .col2 {
      width: 46%;
      float: left;
      margin: 0 4% 20px 4%;
   }
}

@media only screen and (min-width: 600px) and (min-device-width: 600px) {

   // Применяет пользовательскую сетку для подгонки содержимого
   .home-content {
      article {
         width: 92%;
         clear: both;
         margin: 0 4% 20px 4%;
      }
      .image {
         float: left;
         width: 40%;
      }
      .text {
         float: left;
         width: 50%;
         margin-left: 5%;
         .btn {
            @include box-sizing(content-box);
            width: 100%;
         }
      }
   }
}

@media only screen and (min-width: 1024px) and (min-device-width: 1024px) {

   // Применяет обычную систему сеток для настольного компьютера
   .container {
      width:960px;
      margin:0 auto;
   }
   .col4 {
      width: 300px;
      float: left;
      margin: 0 10px;
   }
}

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

$sass --watch --style compressed scss:css

Кроме того, мы воспользовались функциями внутри Sass для построения пользовательской сетки. Вот код для сетки десктопа:

@import "vars";

// Система сеток
$wrap: $col * 12 + $gutter * 11;
@for $i from 2 through 12 {
   .col#{$i} {
      width: $col * $i + $gutter * $i - $gutter;
      float: left;
      margin: 0 $gutter/2 $vgrid $gutter/2;
   }
}
@for $i from 1 through 11 {
   .pre#{$i} {
      padding-left: $col * $i + $gutter * $i;
   }
}
@for $i from 1 through 11 {
   .suf#{$i} {
      padding-right: $col * $i + $gutter * $i;
   }
}
.container {
   width: $wrap + $gutter;
   margin: 0 auto;
   padding-top: 1px;
}
.colr {
   float: right;
   margin: 0 $gutter;
}
.alpha {
   margin-left: 0;
}
.omega {
   margin-right: 0;
}

С этого момента мы могли модифицировать в соответствии со своими запросами ширину колонок и промежутки внутри сетки, просто редактируя конфигурационный файл vars.

//Сетка
$vgrid:      20px;
$col:        60px;
$gutter:     20px;

Сетка рассчитывает ширину диапазона колонок на основе их количества в этом диапазоне, делая их гибкими для любой конфигурации разметки или сетки. Мы выложили этот код с открытым исходником на GitHub, так что пожалуйста – берите и адаптируйте эту гибкую систему сеток к требованиям собственного проекта — и дайте нам знать, как у вас получается!

УСЛОВНАЯ ЗАГРУЗКА JAVASCRIPT’А

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

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

Оптимизация уменьшила размер JavaScript’а с 411 KB до 106 KB.

ОПТИМИЗАЦИЯ РЕСУРСОВ ИЗОБРАЖЕНИЙ

Вдобавок к JavaScript’у, для большей части вебсайтов изображения – самые тяжелые для загрузки материалы. Нам особенно хотелось улучшений в этой области, потому что вебсайт довольно сильно переполнен изображениями с образцами нашей работы.
Мы вручную оптимизировали изображения на всем сайте, выборочно сжимая из области с помощью опций отбора Adobe Fireworks. Кроме того, уменьшили размер файлов с изображениями через последующий контроль сжатия, размытия и уменьшения насыщенности.

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

Мы также воспользовались ImageOptim и TinyPNG для сжатия своих изображений и спрайтов. Эти инструменты удаляют все ненужные данные без потери качества изображения. Так, например, вес спрайта основного изображения снизился с 111 KB до 40 KB.

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

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

@media only screen and (min-width: 120px) and (min-device-width: 120px) {
   .item-1 {
      background: $white url('carousel/dmd/background-optima-m.jpg') 50% 0 no-repeat;
      .computer, .tablet, .phone, .eiffel, .bigben, .train {
         display: none;
      }
   }
   /* Общая загрузка: 27 KB */
}

На десктоп загружается больше ресурсов.

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

@media only screen and (min-width: 1024px) and (min-device-width: 1024px) {
   .item-1 {
      background: $white url('carousel/dmd/background.jpg') center -30px no-repeat;
      .computer {
         background: url('carousel/dmd/computer.png') center top no-repeat;
         div {
            background: url('carousel/dmd/sc-computer.jpg') center top no-repeat;
         }
      }
      .tablet {
         background: url('carousel/dmd/tablet.png') center top no-repeat;
         div   {
            background:  url('carousel/dmd/sc-tablet.jpg') center top no-repeat;
         }
      }
      .phone {
         background: url('carousel/dmd/phone.png') center top no-repeat;
         div {
            background: url('carousel/dmd/sc-mobile.jpg') center top no-repeat;
         }
      }
      .eiffel {
         background: url('#{$img}carousel/dmd/eiffel.png') center top no-repeat;
      }
      .bigben {
         background: url('#{$img}carousel/dmd/bigben.png') center top no-repeat;
      }
      .train {
         background: url('#{$img}carousel/dmd/train.png') center top no-repeat;
      }
   }
   /* Общая загрузка: 266 KB */
}

БЫСТРАЯ ДОСТАВКА СОДЕРЖИМОГО

Золотое правило производительности Yahoo гласит, что «80-90% времени отклика конечного пользователя тратится на загрузку всех компонентов страницы: изображений, таблиц стилей, скриптов, Flash’а и так далее». Короче говоря, любому запросу требуется время на выполнение; следовательно, каждый запрос (как, например, доставка файла с сервера) будет неизбежно увеличивать время загрузки.

Применяя сеть доставки контента CloudFlare (CDN), мы отделили задачу веб-сервера по доставке файлов от обработки вебсайта. Это значит, что наш веб-сервер сосредоточивается на приложении, а не доставке статических файлов. Мы переместили все статические материалы в отдельный субдомен (в нашем случае static.cyber-duck.co.uk) для уменьшения до минимума количества куки, посылаемых с каждым запросом материала, что в свою очередь уменьшает ширину полосы пропускания, требующейся для каждого ресурса.

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

Вдобавок к CDN мы применили правила Gzip и заголовки expires в файле .htaccess HTML5 Boilerplate. Они используют модуль Apache’а mod_deflate для сжатия вывода файлов в браузер, а также устанавливают заголовкам прекращение по истечению срока на далекое будущее, чтобы гарантировать лучшее кэширование вебсайта для возвращающихся посетителей.

Создание настоящего адаптивного дизайна

Как было определено в исходных задачах, мы хотели, чтобы у нашего нового вебсайта было равенство контента и он обеспечивал доступность всем пользователям независимо от того, каким образом они на него попадают. Для доставки по-настоящему адаптивного дизайна мы доверили все стили и задачи отображения только CSS, используя JavaScript только для смены «статуса» элементов через добавление и удаление классов CSS в противоположность скрыванию и показу элементов напрямую с помощью JavaScript’а.

ВЕРНЫЙ КОД ДЛЯ ЭТОЙ ЗАДАЧИ

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

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

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

Вот JavaScript:

$('#menu').addClass('closed');
$('.btn-menu').click(function(e){
   e.preventDefault();
   $('#menu').toggleClass('closed');
});

CSS для настольных компьютеров:

.nav {
   display: block;
   float: right;
}
.btn-menu, .btn-call, .btn-map {
   display: none;
}

CSS для мобильных устройств:

.menu {
   display: block;
   height: auto;
   overflow: hidden;
}
.menu.closed {
   height: 0;
}
.btn-menu, .btn-call, .btn-map {
   display: block;
}

АНИМАЦИЯ КАК СРЕДСТВО УЛУЧШЕНИЯ

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

Для анимации мы решили везде использовать CSS3. Он улучшает впечатление пользователя в тех браузерах, которые поддерживают анимацию CSS3, тогда как более старые браузеры все равно функциональны и даже притягивают к себе взгляд. Например, когда у пользователя смартфон последнего поколения, при растяжении меню или элемента портфолио оно анимируется при помощи CSS3, а не JavaScript’а.

Производительность такой анимации улучшается путем применения аппаратного ускорения, передачей задач центрального процессора (CPU) к графическому (GPU). Для пользователей смартфонов или планшетов она способна создать огромную разницу в производительности путем снижения потребления их и так уже ограниченных ресурсов CPU. Передача анимации CSS позволяет выжать из аппаратного ускорения все, что можно.

.menu {
   height: auto;
   transition: height 200ms linear;
}
.menu.closed {
   height: 0;
   transition: height 200ms linear;
}

КОНТРОЛЬНЫЕ ТОЧКИ НА ОСНОВЕ СОДЕРЖИМОГО И ДИЗАЙНА, А НЕ УСТРОЙСТВА

Для контрольных точек мы применили множественные медиазапросы CSS, чтобы те адаптивно доставляли оптимальное предъявление контента и на большие, и на маленькие экраны.

Такой аппаратно независимый подход гарантирует, что позднее, когда в продаже появятся другие устройства, не понадобится оптимизация кода. Мы включили (но не ограничили) контрольные точки на 120, 240, 600, 760, 980 и 1360 пикселях, а также направленные медиазапросы к определенному контенту на страницах и экранам с высокоплотным разрешением.

Между любыми контрольными точками вебсайт отвечает очень быстро.

Хотя в расчете на будущее мы создавали контрольные точки не на основе отдельных устройств, тестировали мы свой вебсайт на всех устройствах и браузерах, до каких только смогли дотянуться, от самых простых (браузеры десктопов и множество телефонов и планшетов) до необычных (Lynx, Playstation 3, Kindle Paperwhite, PSP Vita и прочих). Мы даже тестировали на старых устройствах Nokia, где он все равно отлично отображался.

Наши дизайнеры и команда разработки пользовательского интерфейса тестировали новый вебсайт на огромном количестве устройств, включая старые модели, такие как этот Nokia X2.

Еще больше доступности

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

ТЕКСТ

Текст четко различим на фонах при соотношении контрастности в 3:1 для заголовков и 4,5:1 — для основного текста.

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

Размер текста можно менять без потери содержимого и функциональности.

ССЫЛКИ

Назначение всех ссылок проясняется описательным текстом, а когда это непрактично — альтернативным текстом.

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

Адреса страницы (т.е. URL’ы) могут читаться человеком и постоянны, где это только возможно.

Мы реализовали ключи доступа для быстрой навигации к важным страницам и свойствам.

Вот HTML для «беглой» навигационной ссылки:

<a href="#content" title="Skip to content" accesskey="s" class="btn-skip">Skip navigation</a>

И CSS:

.btn-skip {
   position: absolute;
   left: -9999px;
}

ИЗОБРАЖЕНИЯ

У всех изображений содержимого имеется альтернативный текст (с атрибутом alt), который показывается там, где изображения отключены или не поддерживаются.

Содержимое доступно и понятно при отключенных или неподдерживаемых изображениях.

ВИДЕО

У всех размещенных на YouTube видеороликов есть сопроводительные подписи (субтитры), если в них имеется устная речь.

ФОРМЫ

Все элементы управления формами и поля тщательно и четко маркированы.

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

Все важные поля формы при ее отправке проверяются на ошибки.

Любая найденная ошибка описывается пользователю в виде текста вместе с предложениями о ее исправлении.

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

Все формы можно отправлять с помощью клавиш “Return” или “Enter”.

Применять подходящие типы ввода и атрибуты, такие как required и placeholder легко и они делают форму более доступной.

<input type="email" id="email" name="email" value="" required="" placeholder="Pop your email address in here">

Всего лишь начало

Результаты выхода в свет нового вебсайта пару недель назад впечатляют. Мобильный трафик увеличился более чем на 200% (при 82% увеличении всего трафика в среднем); средняя продолжительность посещения сайта возросла на 18%; а уровень выхода с домашней страницы для мобильных пользователей снизился более чем на 4000%. Хотя статистика может сказать нам только об этом, данные показывают, что адаптивный вебсайт демонстрирует на мобильных устройствах лучшую производительность, чем наш предыдущий специальный мобильный вебсайт.

Согласно Google Analytics, время ответа сервера уменьшилось в среднем с 1,21 секунд до 170 миллисекунд. Точно так же время загрузки сайта уменьшилось в среднем с 9,19 секунд до 1,82 секунд.

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

Адаптивность — только первый шаг нашего вебсайта.

На инаугурационной конференции Smashing в 2012г. Брэд Фрост (Brad Frost) процитировал Бенджамина Франклина, который сказал: «Если перестал меняться, то ты – пропащий человек». Для всех работников веб-индустрии это утверждение истинно в высшей степени. Мы работаем в таком средстве массовой информации, которое быстро и постоянно эволюционирует. Удержаться на волне в этом постоянно меняющемся ландшафте — сложная задача, но именно она делает работу с вебом такой фантастической и волнующей.

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

Автор: Matt Gibson

Источник: ttp://mobile.smashingmagazine.com/

Редакция: Команда webformyself.

Практика HTML5 и CSS3 с нуля до результата!

Получите бесплатный пошаговый видеокурс по основам адаптивной верстки с полного нуля на HTML5 и CSS3

Получить

Метки:

Комментарии Вконтакте:

Комментарии Facebook:

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Я не робот.

Spam Protection by WP-SpamFree