Pull to refresh

Comments 37

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

Думаю, более верным подходом было бы измерение скорости загрузки при подключении к разным провайдерам, и сравнение усредненной статистики.
Время ответа сервера не зависит от провайдера, оно зависит только от сервера. Мы исключили сетевые издержки и DNS-запросы.
А можно тогда подробнее как это делалось? В методике это не описано.
да, спасибо, добавил в методику
А также замерялось время открытия главной страницы магазинов в браузере Google Chrome…

Это время наступления события load?
Значение этой метрики довольно размыто. Страница может полностью отрисоваться, пользователь начать с ней полноценно взаимодействовать, но отвалившийся скрипт или префетчинг ресурсов «оттягивают» наступление этого события. Другими словами, в большинстве случаев (по моему опыту) эта метрика никак не коррелирует с пользовательским счастьем и влияет только на индикаторы загрузки в браузере.
для обычных пользователей индикатор загрузки в браузере говорит о готовности сайта к взаимодействию. Чем раньше для пользователя «все ок», тем лучше для удобства использования (usability). Большинство исследований (как российских, так и западных) завязаны именно на эту метрику. И для большинства сайтов именно она характеризует «готовность к взаимодействию». Поэтому мы смотрим на пересечение большинства с большинством, а не рассматриваем пограничные случаи, которые, например, по вашему опыту, могут иметь место.
Откровенно говоря, я тоже был в этом уверен до недавнего времени :)

Мы (в Яндексе) проводили исследование на эту тему и наши результаты показывают, что время onload никак не влияет на пользовательские метрики (время до первого клика, доля некликнутых и т.д.). Это было обычное a/b/c тестирование, с оттягиванием onload на одну и две секунды, с объёмом выборки 2% на пользователях Поиска.

Стоит также учитывать, что прошли те времена, когда у браузеров было двадцать три индикатора загрузки и не обратить на них внимание было невозможно. Сейчас, что в Хроме, что в Опере или Фаерфоксе индикатор загрузки это маленький спин в табике и всё.

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

Всё, я выдохнул, простите :)
Вы что издеваетесь чтоли? Зачем в диаграмме использованы цвета которые невозможно отличить?
Открыл десяток первых магазинов из списка, посмотрел через Firebug. В большинстве случаев — все плохо.
80-120 запросов к серверу, штук 20 разных js (и не только внешних), куча мелких css-картинок, куча изображений товаров, которые пользователю даже не видно при просмотре страницы, и прочий бардак.
Т.е. по скромным оценкам большинство «победителей» можно спокойно разогнать еще процентов на 20-50 только за счет клиентской оптимизации.
А почему выбрана для теста «Главная страница»? Разве она может что-то сказать о скорости работы интернет-магазина?

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

Главную страницу в большинстве случаев можно закэшировать на 50-80%, оптимизировать скрипты, как сказано выше и выплевывать её за доли секунды.
любую страницу можно (кроме корзины и обработки заказа) можно закэшировать, оптимизировать и выплевывать за доли секунды. Карточки товара и категории в этом смысле ничем от главной не отличаются. Но по главной можно обо многом сказать.
Не правда! Карточки товара и категории кэшировать в ряде случаев намного сложнее.
На главной обычно имеется товар, который точно в наличии, часто без цены.
На карточках и в категориях чаще встречается товар, при выборке которого нужно учитывать наличие — целиком страницу уже не закэшировать.
Так же в категориях и карточка для разных регионов — разные цены. В этом случае нельзя кэшировать даже по частям.
В больших много-регионных магазинах часть данных с неглавных страниц отдается онлайн, часть кэшируется, но не тупо кусками, а мелкой нарезкой так сказать.
Кэширование региональных версий не является пробемой
А кто говорил, что это проблема?
Просто это несколько сложнее, чем просто главная страница
Главная страница обычно от региона тоже зависит, сложность одинаковая. Но если на сайте выводятся разные цены для разных пользователей — тогда да, нужно хитрить с системой кэширования. Но этот случай покрывает где-то 0,1-0,2% магазинов. Я соглашусь, что в ряде случаев кэшировать сложнее. Но этот ряд случаев крайне малочастотен.
Не знаю, как у кого, но я не вижу особого смысла кэшировать страницы кроме главной.
К примеру, вчера сайт отдал 111 тысяч страниц.
Из них — 40845 разных.
Страниц, запрошенных более 100 раз за день всего 36.

С другой стороны, ежедневно меняются цены и наличие для примерно 20000 товаров.

Вот и какой смысл кэшировать?
Наверно, посещаемость будет 10M страниц в день, я буду думать по другому, но сколько таких eCommerce проектов в мире — 200?
Вопрос сформулирован некорректно. Нужно: сколько раз при кэшировании всего сайта страницы будут отдаваться из кэша (т.е. сколько динамических запросов мы сэкономим таким образом). По нашему опыту — это снижение нагрузки в 3-5 раз. В некоторых случаях — в десятки раз.
Ваша формулировка вопроса теоретически верна, но она вступает в силу только когда требуется масштабирование и autoscaling
При вычислительной мощности 100+ страниц в секунду и реальной нагрузке 3 страницы в секунду мы наоборот сидим и думаем — чем бы ещё пригрузить сервер, чтобы сделать лишний заказ в день?
В вашем случае вы переплачиваете за хостинговую площадку примерно втрое.
Сомнительное исследование, ведь в перечне сайтов есть как практически текстовые сайты (например, club-sale.ru), не содержащие сложных выборок и презентации перечня продуктов, так и содержащие выборку (например, dostavka.ru).
Так и о чем говорит цифра 10 секунд для Boutique.ru? Livechat там достаточно долго грузится, но он абсолютно не мешает пользоваться сайтом до своей загрузки.

Опять же, главные у всех разные, к кому-то вы попали на кэш, к кому-то нет, не вижу особого смысла сравнивать эти цифры.
В течение недели постоянно раз в минуту попадать на кэш? Брался средний показатель, было несколько сотен или тысяч замеров из разных географических точек.
Кэш может быть и cookie-based, если уж на то пошло.

Открыл club-sale, а там пипец, одна гигантская картинка фоновая (http://club-sale.ru/_img/theme/theme13_intro_top.jpg?2) у меня грузилась 1.14 сек. CSS-ка красота — club-sale.ru/_css/style.min.css?1363330215 — 2.65 сек грузилась. %))
«onload: 9.16 s, DOMContentLoaded: 6.11 s» — вот вам и 0.77 сек.

Как говорится, сколько людей, столько и интернетов. :)
Может хаброэффект?
Может быть, конечно. Хотя Boutique.ru: onload: 5.64 s, DOMContentLoaded: 2.39 s.
1. Данные выглядят субъективными:
У меня boutique ~1с, sotmarket.ru — 1.5с, что не соотвтествует данным результам.

На самом деле писать такие тесты можно только для себя. Чтобы увидеть реальную картину лучше использовать данные от реальных пользователей. К сожалению, google analytics не раскрывает таких данных о чужих сайтах, но есть и другие варианты.
К примеру, Alexa.com — плагин, который стоит у многих пользователей и репортит время загрузки. По её данным, у пользователей sotmarket.ru открывается в среднем за 1.163 с, boutique.ru — 1.634 Seconds, что вполне неплохо. А вот Komus.ru, занявший 3е место — 1.238 Seconds?

2. Мы для abo.ua добились отдачи страниц с скоростью порядка 100mbps (1 сервер), что в десятки раз превышает текущие потребности. По мнению алексы, пользователи получают страницу в течении 0.565 Seconds.

Если вы хотите сделать быстрый магазин — актуальнее тестировать не закэшированную домашнюю страницу, либо простую страницу товара, а рандомную выборку товаров, которая бы показала силу «движка». К примеру, телевизоры с ценой до random().
И тогда результаты будут совсем другими. Чтобы это тестировать мы делаем специальную «рандомную» страницу, которая каждый раз ищет разные данные и тестируем на скорость.

И я не сказал бы, что добиться высокой скорости работы сложно, особенно, что касается времени загрузки в браузере. Достаточно воспользоваться google pagespeed insights.
Если вдруг кому интересно как мы оптимизировали serverside — основные советы собраны в этой презентации socialtalents.com/page/100mbps (правда, на английском)

Ну и вообще, нужно оценивать степень параллелизма — каким образом меняется скорость работы с увеличением количества клиентов. К примеру, у нас начинаеся снижение производительности после 80 параллельных юзеров в секунду, и это уже проблема, которая заставляет задуматься…
UFO just landed and posted this here
Так и есть.
И хотя среднюю скорость загрузки уложить в 2-3 секнуды не так уж сложно, добиться этого от первой загрузки хотя бы для 90% клинетов довольно сложно.
Айри.рф решает почти все сложности с "90% до 3 секунд"
UFO just landed and posted this here
Если вы это можете сделать за 750 рублей и 5 минут времени, то ничем. Особенно CDN по России.
Правда, там еще куча технологий сверху навернуто — типа 100% доступности сайта — но это уже как бонус пойдет :)
UFO just landed and posted this here
да, тестовый период несколько дней — бесплатно автоматически. Больше — по запросу с обоснованием эффективности.

Для интеграции нужно только NS-серверы перенести. В редких случаях дополнительные правила для сложных URL добавить (с этим помогаем).
Sign up to leave a comment.

Articles