Медленные сайты раздражают. Ведь в век скоростных каналов связи мы продолжаем тратить свои нервы на ожидание загрузки страницы.
[spoiler]
По данным исследования американской компании :
- 47% пользователей ожидают, что веб-страница загрузится в течение 2 секунд;
- 40% посетителей могут уйти с сайта, который грузится более 3 секунд;
- 52% утверждают, что быстрая загрузка влияет на их лояльность;
- 3 секунды ожидания уменьшают лояльность клиентов примерно на 16%
То, что скорость загрузки сайта влияет на поведение пользователей, подтверждается и в другом исследовании — The Gomez Peak Time Internet Usage Study, проведённом :
- в часы пик 75% посетителей ушли на сайты конкурентов, не дождавшись загрузки страницы;
- 88% заявили, что вряд ли вернутся на сайт после неудачной попытки его открыть;
- больше половины пользователей выразили менее позитивное мнение о компании в целом, если сайт медленно открывался;
- более трети поделились негативным впечатлением со знакомыми.
В сети существует огромное множество сервисов, которые позволяют измерить скорость загрузки сайта. Но у всех этих сервисов есть один большой недостаток – принцип их работы.
Все существующие сервисы работают по очень схожей технологии. Для замера скорости работы вашего сайта они обращаются к нему из ограниченного – от двух до 20 – количества точек (серверов), разбросанных по всему миру. Эти сервера находятся в «тепличных условиях» - в местах со стабильным хостингом, и данные получаются идеальными.
Статистика с таким небольшим количеством данных будет очень неточной. И самое главное, что эта статистика не отразит реальной скорости загрузки вашего сайта вашими пользователями.
В отличие от большинства сервисов, замеряющих скорость загрузки сайта из внешних точек, мы решили проверять скорость загрузки ресурса на хитах реальных пользователей. И далее – отображать данные заходов для последней 1000 хитов. Так как посетители все время меняются, то и данные меняются вместе с ними.
Как мы решили данную проблему
Мы долгое время мечтали о сервисе, который сможет показать, с какой скоростью отображается ваш сайт глазами ваших посетителей! И наша мечта воплотилась в облачный сервис.
Встречайте новый инструмент, интегрированный в «1С-Битрикс: Управление сайтом», который покажет вам реальную скорость отображения вашего проекта у ваших клиентов.
После установки обновления main 14.9.0 на странице «рабочего стола» перед вами отобразится яркий виджет, показывающий текущую скорость загрузки страниц вашего сайта.
В приведенном примере сайт у последней 1000 посетителей открылся, в среднем, со скоростью 0,76 секунды, что характеризуется как «быстро».
Перейдем на страницу с подробной информацией, нажимая на слово «Быстро» или «Рабочий стол -> Настройки -> Производительность -> Скорость сайта»:
Перед нами откроется страница с подробным состоянием замеров скорости.
Что влияет на скорость загрузки?
Но прежде, чем мы начнем разбирать, как все это работает, давайте разберемся, из чего строится показатель скорости – комплексный показатель комфортности работы с сайтом для посетителей.
На скорость загрузки сайта оказывают влияние различные факторы:
- Качество разработки сайта. Ошибки разработчиков или неоптимальный код могут увеличить время выполнения скриптов на страницах сайта. А это, в свою очередь, окажет негативное влияние на скорость отображения страниц.
- Качество хостинга. Вы создали отличный сайт, довели код до идеального состояния и на локальном сервере разработчиков сайт просто летал. Но после выгрузки на хостинг показатели скорости вас разочаровали. Видимо, вы выбрали слабый хостинг или сервера хостера находятся очень далеко от основного местоположения ваших клиентов и время открытия страниц у них очень длительное.
- Доступность сайта в сети – у вас хороший хостинг, у вас оптимизирован код сайта, но время прохождения данных по промежуточным каналам сети от вашего хостинга до ваших пользователей может быть очень большим. И у посетителей ваш сайт будет загружаться медленно.
Скорость сайта фактически показывает, как быстро отобразился ваш сайт для большинства из этих 1000 посетителей.
Но вывести только средний показатель было бы не эффективно. Ведь страницы могут различаться как по количеству контента, так и по количеству скриптов и времени их выполнения. А соответственно, нам нужно видеть, как распределились страницы и какие из них влияют на ухудшение среднего результата:
На графике показано время, с которым страницу увидел ваш посетитель, и количество страниц, загруженных с таким временем. Если подвести курсор к конкретному столбцу графика, мы увидим 10 страниц с наиболее худшими показателями временем загрузки и сможем приступить к оптимизации.
Как работает технология?
Загрузка страницы – это не однородный процесс, на него влияют множество факторов. Давайте разберемся, как все происходит.
На картинке в графическом виде представлено, какие этапы взаимодействия с пользователем проходит страница вашего сайта при заходе на нее.
Человек вводит адрес сайта в строку браузера.
1 ЭТАП. В первую очередь, если настроены, срабатывают (Redirect). В большинстве своем их нет, но система учитывает эти данные, хотя на графике они пока не показаны (но скоро обязательно будут).
2 ЭТАП. Дальше отрабатывает (DNS Lookup). В большинстве своем, запрос к DNS по скорости близок к нулю, так как данные кешируются и браузерами, и самими серверами DNS (локальными, серверами провайдера и т.п.). Мы учитываем этот параметр и выводим его на график.
На скриншоте наглядно отображено, как это выглядит и сколько на это тратится времени:
3 ЭТАП. Дальше происходит «Подключение к серверу» (Connect to Server) и разрешение на дальнейшие действия. Это некое «рукопожатие», мы так же выводим это время на график:
4 ЭТАП. Следующий шаг – это «Ответ сервера» (Request Document). Этот параметр мы также выводим на график, Чем дальше от ваших клиентов находится сервер, тем больше будет этот показатель. По нему можно ориентироваться, сколько теряется времени на ответ сайта посетителю.
Данный ответ может быть не разовая операцией, ведь чем больше запросов делает страница к серверу, чтобы произвести загрузку ресурсов и т.п., тем дольше все будет отрабатываться.
Давайте посмотрим на скриншоте:
5 ЭТАП. Дальше происходит загрузка HTML (Receive Document). Здесь учитывается время загрузки HTML-страницы для ее последующей обработки. Например, при загрузке ресурсов на этот параметр сильно влияет размер страницы.
Этот процесс отображен на следующем графике:
6 ЭТАП. После того, как страница загрузилась, начинается процесс ее обработки – «Обработка HTML» (Process the Document and Load the DOM, но здесь учитывается не весь блок, а только от domLoadding до domInteractive) и загрузки ресурсов.
Вот здесь при наличии ошибок в разработке, процесс загрузки страницы может очень «просесть». В момент обработки некоторые браузеры могут параллельно загружать ресурсы (CSS, JS) в многопоточном варианте, поэтому постарайтесь в процессе разработки вынести загрузку ресурсов в тег «HEAD».
Как уже говорилось, загрузка ресурсов может происходить в несколько потоков. Но для различных браузеров количество таких потоков будет различным, и обычно не превышает восьми.
В этом случае вам поможет включение объединения CSS и JS, которое предусмотрено в «1С-Битрикс: Управление сайтом». Все ваши файлы будут объединены в один и загружены намного быстрее.
Обратите внимание, объединение работает, только если файлы подключаются через механизмы продукта:
В первом блоке ресурсы подключаются правильно, и мы сможем их объединить в один файл. Чуть ниже показано подключение, когда этот файл не сможет быть объединен.
7 ЭТАП. Так же для ускорения загрузки ресурсов можно включить CDN (Content Delivery Network) – эта технология помогает загружать ресурсы с помощью промежуточных серверов, разбросанных по всей стране. Процесс передачи осуществляется из ближайшей к клиенту промежуточной точки, что ускоряет процесс загрузки самого ресурса.
Как это выглядит в теле страницы:
Мы видим, что все JS файлы, а их было 10 штук, объединились в один. Соответственно, времени на их загрузку потребуется меньше, а один файл, который мы загрузили не штатными средствами, не был объединен и загрузился отдельно.
Посмотрим, как это выглядит на нашем графике:
8 ЭТАП. Ресурсы загрузились или продолжают загружаться, и начинается процесс «Отрисовки страницы». Это уже не одиночный процесс, это сумма всех процессов, которую лучше показать на рисунке:
Давайте посмотрим, как это отображается у нас на графике:
Все графики можно совместить, ну и, конечно, можно отслеживать их в разрезе каждой страницы, поднося курсор к нужным узлам, как видно на скриншоте:
Проверка скорости сайта стала легким и удобным процессом, с которым может справится даже непрофессионал.
Не будем забывать и о разработчиках, получивших дополнительный инструмент, который сможет показать заказчику, что его решение по выбору хостинга было не оптимальным, или найдет страницы, к которым нужно внимательно присмотреться и оптимизировать.
Тестируйте свои сайты, хвастайтесь результатами оптимизации в комментариях, и конечно задавайте вопросы!
.
Вы этот момент поправили или по прежнему по сути являетесь прокси?
Мне такое прокси лично не нужно, ибо я не понимаю кто ко мне ломится/спамит/ломает и не могу с этим ничего поделать! Это очень плохо!
Я вам обрисовал проблему.
Десятки тысяч попыток брутфорса битирксовой админки (в день!). Все с одного ИП. Того же, что у админа и всех пользователей - вашего. Нет возможности заблокировать.
Аналогично тысячи попыток php,sql инъекций, xss.
Спам.
Без вас я этих вредителей на последнем рубеже обороны по ИП блочу. А вы меня этого рубежа лишаете.
Если вам интересно скрипты писать, чтобы по логам злоумышленников вычислять, - тогда Айри не для вас. Айри - для тех, кто ценит свое время.
P.S. При каждом запросе передается X-Real-IP. Можете отлавливать по нему.
Я удивлён. Вы реально не понимаете или прикидываетесь?
- Есть пользователи. Их 9000 ИП.
- Есть злоумышленники. Их 999 ИП.
- Есть админ. Его 1 ИП.
- И есть РОВНО 1 ВХОДЯЩИЙ ИП (с точки зрения сайта), который принадлежит АЙРИ. И с этим ИП летят все запросы: пользовательские, админские, зловредные.
Я лично наблюдал всю эту красоту. До включения Айри я блочил по десятку-два наиболее наглых ИПшников.После включения количество "атак" не уменьшилось. А вот блочить самых наглых стало невозможно. Ибо не видно кто есть кто - все теперь АЙРИ.
Я должен какой-то ваш параметр теперь объяснять битирксу? Нафиг надо, если могу не пользоваться вашим Г сервисом.
Битриксовое облако решает (если нужно облако для контента/статики).
А айри идёт в лес.
Как я выше написал, вы можете блокировать по X-Real-IP.
У меня нет оснований доверять Вам.
Тем более, я считаю некорректным, когда такая защита должна как-то отдельно "включаться", если она есть.
Извините, не буду продолжать дискуссию, она бессмысленна.
На бесплатном тарифном плане такой защиты пока нет.
Сомнительного ничего в технологии нет, она сертифицирована и не более сомнительна, чем тот же WAF в Битриксе.
Все, кто хотят протестировать, - с радостью ждем на Айри.рф.
P.S. Спасибо, что отказались от бессмысленного троллинга!
Я предлагаю тред скрыть.
Я тоже заметил, что это похоже на ликбез таких вот "дурачков", как я. И был очень рад.
Очень приятный подарок, который я получил по возвращении из отпуска!
P.S. на своём проекте уже запустил. И был удивлён довольно быстрой работой "в среднем" даже без композита (временно выключен по определённой причине). Можно и клиентам нести теперь, пожалуй...
Какой смысл покупать сертификат если при включении облака все браузеры орут что на странице куча не шифрованного контента?
На сайтах с CDN то же самое
Теперь ждём сжатие js и css для ещё более быстрой загрузки.
Если полученный, в результате объединения, файл прогнать через минификатор - можно сократить размер минимум на 20-30%.
Я думаю, что мы говорим о немного разных вещах. Сжатие nginx делает с помощью упаковки файлов в архив (gzip). Я же имею в виду именно минификацию кода - Вырезается всё лишнее (комментарии, пустые строки, табуляции, лишние пробелы) и
перерабатывается js-код
К примеру вот из такого:
/** * [function_name description] * @param {[type]} argument [description] * @param {[type]} argument1 [description] * @param {[type]} argument2 [description] * @param {[type]} argument3 [description] * @param {[type]} argument4 [description] * @return {[type]} [description] */ function function_name (argument, argument1, argument2, argument3, argument4) { var newArgument = argument + 1, newArgument1 = argument1 + 1, newArgument2 = argument2 + 1, newArgument3 = argument3 + 1, newArgument4 = argument4 + 1; console.log(newArgument); console.log(newArgument1); console.log(newArgument2); console.log(newArgument3); console.log(newArgument4); }function function_name(a,b,c,d,e){var f=a+1,g=b+1,h=c+1,i=d+1,j=e+1;console.log(f),console.log(g),console.log(h),console.log(i),console.log(j)}Размер уменьшился в 5 раз. Но практике конечно всё не так радужно и размер js уменьшается на 20-60% в зависимости от того, сколько "лишнего" там присутствует, но и это очень даже ощутимая цифра. тот же kernel.js уменьшается в два раза. А если всё это ещё и будет жаться через тот-же nginx, то размеры вообще будут мизерными.
Обычно используют , было бы очень классно, если эту, или подобную библиотеку интегрировали бы в битрикс, сайты не просто летали бы, а носились на реактивных скоростях.
Но есть аналогичные решения на PHP, их можно интегрировать.
Есть еще Closure Compiler ( ) от Google и YUI Compressor ( ) от Yahoo, они лучше жмут, но запускаются только через Java.
Вот как раз по поводу инлайновой загрузки css я .
А для более быстрой загрузки картинок можно - в целом сайт загрузится на много раньше - меньше запросов и трафика на ресурсыстраницы при её открытии.
И еще стоит смотреть объем своих скриптов и скриптов от битрикса, а то бывает так, что kernelJS, kernelCSS занимают больше половины вашего кода, тогда - конечно, не во всех ситуациях так можно делать. Но при грамотной разработке можно сэкономить до 300кб лишнего кода, при загрузке.
Вот только интересно, будет ли вестись статистика загрузки сайта без kernelJS...
Не планируете сделать?
Конечно, это мой уникальный случай, но все же имеет место быть.
Есть интернет-магазин для одной из стран средней азии, где с интернетом проблемы. В итоге у меня сайт грузится за 1-1.5 секунды, а у них за 3-6. Поэтому приходится довольствоваться низкими показателями скорости
Хостинг там есть, но лучше пусть долго грузится, чем пользоваться их хостингом. CDN в их стране нет.
А теперь после вашего комментария тут же всплыл вопрос - на скорость в данном виджете влияет количество изображений на странице?
1) /site_speed.php?lang=ru Authentication failure Access denied.
2) гаджета в принципе нет
Вообще, хотелось бы поблагодарить за замечательный стек технологий по оптимизации: конкатенация/минификация + CDN + композит.
Осталась только одна мелочь. Хотелось бы узнать: планируется ли реализация встроенного механизма переноса всех тегов <sc ript> перед </body>? В данный момент приходится все делать через хитросплетение ShowHeadStrings() и ShowHeadScripts() в footer и header.
Вопрос: а как это работает?
Чем данный инструмент принципиально отличается от Яндекс.Метрики (загрузка страниц) ?
Спасибо.
Уже больше месяца на локальном ПК ничего не отображалось (кроме меня никто не заходит на сайт), а сегодня неожиданно стали отображаться данные!!!
Однако уже 2 недели как запущен сайт, с посещаемостью до 800 человек в день, и никаких данные не отображается. Крайне не понятный механизм включения данного модуля.
Подскажете?
Upd. Странно, но сейчас выровнялось... Есть подозрение, что мы обычно заходим без www в админку - поэтому и дольше грузилось.
UPD: забыл уточнить, что в меню добавления гаджетов на рабочем столе его тоже нет.
UPD 2: а его в "гаджетах" и не должно быть вроде.
у меня как и у вас
Но в просмотре исходного кода
Получается что он ничего не обьеденяет (
что я не так сделал ?
спасибо
вот код из header
а вот исходный код главной страницы
может не так делаю что
или не там написано (
Но все равно не могу добиться высокой скорости загрузки сайта, 2.2 сек судя по тестам (
вот у меня так (((
понимаю что не панацея, сейчас ищу все возможные способо/методы уменьшения времени загрузки
сайт только сегодня установил на хостинг, ранее проблем не было, сервера в Италии.
и так вышло что на сам сайт заходил через 3g связь, видимо он взял данные мои и так как больше никто не заходил вписал их.
конечно там показан график, ниже, какой елемент дольше всего грузит, но именно ответ сервера , доли секунды, остальное прорисовка HTML
постараюсь картинки пережать еще
спасибо вам за советы