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

Внимание! В скорости сайта есть три основные метрики — время ответа сервера (TTFB), время отрисовки (DOMready) и время полной загрузки (onload). Часть исследований сфокусирована только на одной из метрик, а некоторые — вообще без этих метрик. Применяя результаты исследований (и предлагаемые методы) к вашему сайту, нужно четко понимать, о какой конкретно метрике (и ее улучшении) идет речь. Иначе проблемы вашего сайта не удастся соотнести с полученными результатами.

Хабр уже насыщен статьями на тему «нового» формата изображений WebP (описание, сравнение с JPEG2000, сравнение с BPG, использование, подключение на сайте). К сожалению, открытыми остаются вопросы: как правильно подключить WebP на сайте, чтобы «все работало», и насколько он лучше (меньше) PNG/JPEG. В этой заметке я буду отвечать на оба вопроса.

Предполагаю, что вы уже в курсе оптимизации изображений, умеете конвертировать изображения в WebP, понимаете разницу между использованием JPEG и PNG на сайте, знаете инструменты ExifTool, jpegtran, mozjpeg, JPEGrescan, optipng, pngcrush, pngwolf, zopflipng и TruePNG, а также различаете пастеризацию молока и постеризацию изображений.

Если все так — то переходим к сути.

Время идет, интернет становится быстрее, а устройства пользователей — мобильнее. Практики, которые были актуальными 5-10 лет назад, устаревают, и на смену им приходят новые. За 9 лет существования WEBO Group (WEBO Site Speedup, webo.in, webopulsar.ru, Айри.рф) мы проанализировали, увеличили и промониторили скорость сотен тысяч сайтов. С годами браузеры становились быстрее, а сайты — более тяжелыми. И каждый год подходы по ускорению сайтов немного но менялись. Я рассмотрел наиболее часто встречаемые проблемы скорости сайта и наиболее эффективные методы их решения на сегодняшний день.

Дисклаймер: все советы вредные, применять их не нужно!

По долгу работы в Айри я иногда разбираю ошибки функционирования сайта на сетевом уровне / уровне браузерного взаимодействия. Обычно это сводится к простому анализу заголовков запроса-ответа и воспроизведению тривиальных условий. Но иногда бывают интересные случаи.

Все начиналось холодным февральским вечером. Клиент написал о странной проблеме при ускорении сайта: слайд-шоу множилось и блокировало поведение сайта, страницы были недоступны. Через два дня после выяснения всех подробностей я узнал, почему Mootools и jQuery категорически нельзя использовать совместно. И подтвердился в мысли, что и «алкоголь — зло», и «eval — зло».

Но обо всем по порядку.

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

Да, это похоже на западный CloudFlare. И первоначальная модель у нас такая же. Но только на просторах России, согласно ее географии. И развиваться мы планируем по-другому.

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

Существует большое количество инструментов как для создания прототипа сайта, так и быстрого разворачивания сайта «с нуля», которые позволяют создать что-то в Сети и оперативно это обсудить/поменять буквально за несколько минут. Для интернет-магазина можно воспользоваться InSales, WebAsyst, WinShop или SiteBerry. Для создания готовых сайтов сервисов еще больше — к списку можно добавить имеющиеся у провайдеров Jimdo, Setup, Wix и многочисленные платформы для блогов. Но онлайн-сервисов для быстрого создания уникального дизайна сайта (с учетом обычной и мобильной версии) почти нет. Поэтому я расскажу о MotoCMS, как инструменте прототипирования и быстрого дизайна сайта.

Основная миссия MotoCMS — быстрое и бюджетное создание сайта-визитки, сервис позволяет успешно решить следующие задачи:

• Подобрать сетку сайта и цветовое решение
• Согласовать основные шаблоны на примере готового сайта
• Быстро внести изменения в дизайн прямо в браузере
• Быстро согласовать тексты и изображения на сайте
• Легко добавить базовый функционал для сайта

Хотя на сайте MotoCMS заявлено, что это шаблоны Flash-сайтов, далеко не все из них Flash, есть и обычные HTML. Например, тот, который использовался для данной статьи. Как заявляют разработчики, MotoCMS была изначально Flash-админкой сайтов с Flash-шаблонами, но потом разработчики полностью перешли на HTML формат в шаблонах. Сейчас шаблоны MotoCMS наиболее удобные, функциональные и отвечающие всем требованиям к сайтам-визиткам.

Однажды при общении с коллегами из AdRiver выяснилось, что далеко не все клики по рекламным объявлениям становятся переходами на целевой сайт. Для меня было бы нормальным услышать, что теряется 5-10% посетителей (вполне естественные цифры в рамках общей погрешности измерений). Но, как оказалось, потери могут составить до 50%. И мы решили разобраться подробнее, где же происходят утечки, почему обычные, здоровые, адекватные клики не становятся переходами.

На днях мы запустили WEBO Bubbler — очень крутое дополнение к нашему обычному технологическому мониторингу: мы научились делать скриншоты сайтов из любой точки России и отслеживать на этих скриншотах рекламные банеры. Для затравки: так выглядит реклама Samsung на главной Яндекса из Новосибирска.

Скорость все же имеет значение для интернет-магазинов. Два года назад мы проводили исследование по сайтам ведущих интернет-магазинов, банков и страховых. Результаты были не очень радостные, но примерно четверть сайтов можно было отнести к «быстрым». Сейчас мы решили повторить исследование, ведь если скорость подключения основной аудитории интенет-магазинов изменилась не сильно (все то же безлимитное с ограничение полосы пропускания в районе 5-10 Мбит/с), то количество мобильных пользователей заметно выросло (по последним измерениям, сейчас каждый четвертый пользователь использует смартфон для просмотра сайта). И было интересно узнать, какие критерии маркетинговая команда ведущих интернет-магазинов считает эффективными, за сколько секунд должен открываться успешный интернет-магазин.

Как показало исследование, 85% интернет-магазинов открываются до 4 секунд, при этом 23% открываются до 2 секунд. Это гарантирует как минимальную зависимость эффективности сайта от скорости (скорость уже почти максимально высокая), так и хорошие показатели сайта для мобильных пользователей (сайт открывается достаточно быстро для них).

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

Как ответить на эти вопросы?

Рынок хостинга понемногу перешел от аренды виртуальных площадок до вполне вменяемых виртуальных серверов, когда есть гарантированные мощности и полный доступ к системе и «железу». Это сильно сегментировало рынок: можно встретить как тарифные планы за 200-300 рублей, так и более 2000 рублей в месяц. При этом все хостинг-провайдеры предлагают более-менее одинаковые показатели оборудования (процессор, память, диск) и встает резонный вопрос: в чем, собственно, разница?

Чтобы разобраться в вопросе со всей нужной глубиной, мы провели тестирование производительности более-менее одинаковых тарифных планов от наиболее популярных российских провайдеров на одной из самых популярных коммерческих платформа в России для создания сайтов – 1C-Битрикс. Почему на ней? Причин довольно много: и стандартная установка базового сайта, и наличие тарифных планов «специально подобранных», да и просто существование определенного набора пакетов «Окружения Битрикс», которые гарантируют относительно равноправное участие различных площадок в тестировании (когда мы можем сравнивать производительность без учета специфики операционной системы или серверного окружения).

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

Обычно уровень надежности инфраструктуры проекта позволяет оставить время реакции на возникшие проблемы таким же — часы или даже дни. Но при этом есть ряд мест, решения по которым должны приниматься в (полу)автоматическом режиме, чтобы исключить человеческий фактор и свести время простоя системы к минимуму. О триггерах таких решений речь пойдет ниже. Хочу сразу отметить, что почти все описанные технологии мониторинга используются в новом облачном сервисе социального интранета — Битрикс24.

Бизнес в интернете сейчас очень сильно завязан не только на качество самого сайта, но и на его доступность и работоспособность в режиме 24/7/365. И хотя хостинг-провайдеры заявляют о достаточно большом аптайме площадок и серверов, не всегда этого бывает достаточно, чтобы быть уверенным в надежности сайта. Одним из помощников в этом является мониторинг как доступности, так и работоспособности основных подсистем сайта. Давайте посмотрим, как это можно делать сейчас.

Регулярная проверка

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

Прошло уже больше 3,5 лет с момента официального запуска информационного ресурса webo.in. Утекло не просто много воды, а очень много. Отрасль сильно шагнула вперед, мы опубликовали две книги по собственным и переведенным материалам, проверили больше миллиона веб-ресурсов, основали и успешно растим компанию — единственную в России, кто профессионально занимается ускорением сайтов — WEBO Software. Но топик не об этом, он — о новом поколении отчетов по скорости сайтов.

Ресурс webo.in устарел уже года полтора назад, когда появился Google Page Speed, был осуществлен его перевод на русский и стало понятно, что аналитическая проверка (поверх реальных данных) будет значительно точнее синтетической (на основе вычислений реальных данных, их моделирования). Поэтому мы решили «закрыть» webo.in.

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

В исследовании были рассмотрены сайты 3 сфер: банки (ТОП 50 по активам), страховые (ТОП 50 по активам) и интернет-магазины большой телекомовской тройки и крупных цифровых ритейлеров (всего 9 сайтов). Для всех этих компаний очень важно повышать лояльность пользователей к сайту, большой вклад в которую вносит снижение времени открытия страниц.

К примеру Amazon.com (оборот за 2010 г. – $34,2 млрд, +40% за год) заявлял, что увеличение времени открытия сайта пользователем всего на 0,1 секунды приводит к потере 1% объема продаж [ссылка]. А исследование Akamai и Phocuswright показало, что 43% людей не готовы ждать открытие сайта больше 4 секунд.

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

Забегая немного вперед, скажу, что ежедневно сайты теряют порядка миллиона посетителей. И примерно в половине случаев эти потери практически незаметны, потому что происходят либо из-за «плавающих» сбоев, либо из-за большого наплыва посетителей (и превышении времени ожидания ответа). Происходит это, к счастью, не так часто, но в финансовом плане эффект получается весьма ощутимым. Например, только avito.ru потерял за прошедшую неделю почти 140 тысяч посетителей.

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

%username, доброго тебя дня/ночи/утра/что там еще бывает :) Спешу сообщить о безумно классной новости: теперь разработка расширений сразу под множество CMS стала на порядки легче. Если по-русски, то расширение для Joomla! теперь можно установить на WordPress, Bitrix, Drupal, или что-еще-у-вас-на-сайте-используется. И наоборот.

Но это слишком здорово, для того чтобы быть правдой, правда? :) Подробности под катом.

Дальше много букв, но загрузить это чудо-расширение можно прямо отсюда (размер порядка 100 Кб). В комплекте кроме самой платформы — 4 виджета для измерения клиентской и серверной скорости загрузки, объема потребляемой памяти и свободного места на диске. Расширение доступно пока только для Joomla! и WordPress (системные требования).

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

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

С выходом новой версии WEBO Site SpeedUp (приложения для автоматического ускорения сайтов) — 1.3.0 — мы смогли, наконец, с уверенностью сказать: оно здесь. В смысле: идея автоматического ускорения сайтов реализована.

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