15 бесплатных инструментов тестирования производительности сайта. Что такое производительность сайта


Производительность сайта. Почему она имеет значение

Производительность сайта. Почему она имеет значение. Управление восприятием

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

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

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

У каждого технического решения есть свои пределы

Современные тенденции и подходы в веб-разработке

Узнайте алгоритм быстрого профессионального роста с нуля в сайтостроении

Узнать подробнее

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

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

Время загрузки составляет 12.436 секунд? Полная визуальная отрисовка занимает 12.2 секунды. Цифры совсем не впечатляют, согласитесь. Судя по цифрам этим сайтам срочно нужна помощь. А что если я скажу, что эти веб-сайты заработали за 2014 год $89 и $19 миллиардов долларов соответственно? Как такое вообще может быть? Не парьтесь. Вбейте в адресную строку amazon.com или ebay.com и увидите, что они все равно загружаются быстрее, чем вы подумали. Как добиться такого эффекта мы обсудим чуть позже.

Производительность это не математика

Производительность сайта никогда не измерялась в миллисекундах, килобайтах или количестве запросов, это не математическая величина. Производительность ощущается на уровне восприятия и психологии. В этой части мы по-другому взглянем на понятие производительности:

Что такое психологическое время?

Как люди ощущают время?

Как управлять и влиять на это ощущения?

Психологическое время: управление восприятием

«Воображение — это единственное оружие в битве с реальностью» — Чеширский кот, Алиса в стране чудес Льюиса Кэрролла

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

В 1927 году Немецкий философ Martin Heidegger в своей книге «Бытие и время» написал «Время сохраняется лишь как следствие событий (в пространстве)». Согласно Хайдеггеру, время конечная величина, оно имеет начало и конец и состоит из мириад событий со своими началами и концами. А события и составляют то, что мы называем «временем». Представим простое событие:

Умственно люди разграничивают события с четкими границами начала и конца.

Назовем начало событие стартовой точкой. Соответственно, момент завершения события – конечная точка. В дополнение к принципу ограниченности времени можно сказать, что почти все события можно охарактеризовать двумя фазами: активная и пассивная. Активная фаза или активное ожидание характеризуется умственной активностью пользователя. Это может быть как физическая активность, так и просто умственный процесс, как разгадка пазла или поиска маршрута на карте. Период, когда пользователь не контролирует момент ожидания называется пассивной фазой или пассивным ожиданием. Примером может послужить очередь или ожидание любимого человека, который опаздывает на свидание. Люди, как правило, чаще думают, что пассивное ожидание более длительный процесс, даже если промежутки времени равны. В своем учении Jacob Hornik вслед за обширными исследованиями Richard Larson показал, что в среднем в пассивном режиме ожидания люди переоценивают время примерно на 36%. Ричарда Ларсона в MIT называют «Dr. Queue» (Доктор Очередь).

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

Итак, мы подошли к двум основным принципам времени, на которых и будет строиться дальнейшее повествование:

У каждого события есть свои начальная и конечная точки.

Почти все события имеют активную и пассивную фазы.

Ни для кого не будет открытием, если я скажу, что мы не любим ждать, кроме отдельных случаев. Но когда мы говорим про длительно ожидание, на самом деле мы имеем в виду пассивную фазу; в большинстве случаев активную фазу вообще нельзя назвать ожиданием. Т.е. чтобы управлять психологическим временем и заставить мозг по-другому ощущать событие , мы должны как можно сильнее сократить пассивную фазу ожидания события и увеличить активную фазу. Существует множество различных способов, но большинство сводятся к двум простым: раннее начало и завершение события. Рассмотрим оба варианта.

Ранний старт

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

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

По технике раннего старта событие начинается с активной фазы. Активная фаза растягивается как можно дольше.

В 2009 году в Техасе управляющая компания аэропорта Хьюстон получила необычную жалобу. Пассажир оказался недоволен долгим ожиданием своего багажа. Как ответ, руководство аэропорта увеличило количество грузчиков багажа, что позволило снизить время ожидания до 6 минут. Это отличный результат по сравнению с другими аэропортами США. И к удивлению руководства, число жалоб не снизилось.

Руководство аэропорта провело исследование, и выяснилось, что в среднем время на получение багажа занимает 8 минут с момента появления первой сумки на конвейерной ленте. У пассажиров уходит около минуты, чтобы дойти до карусели. Т.е. пассажиры в среднем ждут 7 минут перед тем, как забрать сумки. Говоря психологическими терминами, активная фаза события составляет всего одну минуту, в то время как пассивная 7.

Основываясь на своем опыте управления восприятием, аэропорт нашел довольно нетривиальное решение. Они просто отодвинули ворота подальше от главного терминала и перенаправили весь багаж на самую дальнюю карусель. Это увеличило время, которое требуется пассажиру, чтобы добраться до карусели до 6 минут. Тем самым, на пассивное ожидание осталось всего 2 минуты. И несмотря на увеличенное расстояние, число жалоб сократилось практически до нуля.

Карусель багажа.

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

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

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

Другим примером данного метода послужит мобильная версия браузера safari для iOS. Во время набора адреса, браузер подгружает список подходящих сайтов, сначала на которых вы уже были, потом релевантные результаты из поисковика. В сафари есть специальная ссылка Топ. Не многим известно, что ссылки из Топа подгружаются в фоновом режиме. Тем самым при переходе по ним, вы уже получаете готовую страницу, т.е. она загружается для вас быстрее. Эту функцию можно настроить в настройках – предзагрузка Топа.

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

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

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

Современные тенденции и подходы в веб-разработке

Узнайте алгоритм быстрого профессионального роста с нуля в сайтостроении

Узнать подробнее

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

На данный момент группа экспертов во главе с инженером по веб-производительности Google Ilya Grigorik разрабатывает W3C спецификацию под названием «Resource Hints». Конечная цель спецификации добавить встроенную поддержку техники раннего старта в браузеры. Как пишет сам Илья в своей книге «High-Performance Browser Networking» — «мы сможем добавить подсказки в HTML документ, чтобы подсказывать браузеру о дополнительных способах оптимизации».

Эти подсказки уже поддерживаются.

Чтобы предзагружать ресурсы как можно раньше, все эти подсказки должны быть расположены в теге head. Быстренько пробежимся по всем подсказкам:

dns-prefetch. Полезна для предварительного одобрения перехода по доменным именам, найденным на странице. Можно использовать для предварительного одобрения перед редиректом. К примеру:

<link rel="dns-prefetch" href="//name-to-resolve.com">

<link rel="dns-prefetch" href="//name-to-resolve.com">

preconnect. Используется не только для одобрения перехода, но и для рукопожатия. Для конфигурации CORS запросов используется необязательный атрибут crossorigin; взгляните на комментарий Ilya Grigorik, сразу все поймете. К примеру:

<link rel="preconnect" href="//cdn.example.com" crossorigin>

<link rel="preconnect" href="//cdn.example.com" crossorigin>

prefetch. Низкоприоритетная подсказка, используется для загрузки ресурсов, необходимых для будущей навигации. Для оптимизации загрузки определенных типов файлов используется необязательный атрибут as. К примеру:

<link rel="prefetch" href="/library.js" as="script">

<link rel="prefetch" href="/library.js" as="script">

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

<link rel="prerender" href="//example.com/next-page.html">

<link rel="prerender" href="//example.com/next-page.html">

Более подробно прочитать о подсказках и посмотреть примеры с необязательными атрибутами можно в рабочем проекте спецификации. Чтобы лучше понять принцип работы подсказок, советую вам посмотреть на слайд шоу Preconnect, Prefetch, Prerender от Ильи, а также прочесть статью Prefetching, Preloading, Prebrowsing от Robin Rendle на сайте CSS-Tricks. Более того, в спецификацию была добавлена еще одна подсказка Preload. Подсказка почти копирует работу prefetch:

<link rel="preload" href="/styles/other.css" as="style">

<link rel="preload" href="/styles/other.css" as="style">

Но все же между ними есть существенные различия:

Prefetch имеет низкий приоритет и используется для подгрузки второстепенных ресурсов, используемых во время навигации по сайту. А preload имеет более высокий приоритет, применяется для загрузки критический для сайта ресурсов. Кстати, подсказка preload вытеснила другую, subresouce. С последней вы могли сталкиваться в других статьях.

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

Раннее завершение

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

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

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

Сервисы видео трансляций, как Youtube, отличный пример метода раннего завершения.

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

Можно начать рендеринг страницы, как только загрузились критические элементы структуры, как DOM. Нет нужды ждать загрузки всех ресурсов, если они не повлияют на рендеринг страницы. Нам даже не нужны все HTML теги; те части, которые не видны визуально при первой загрузке страницы, такие как footer, можно подгрузить потом с помощью JS. Давайте снова вернемся к нашим Amazon и eBay. Рассмотрим в режиме кинопленки процесс рендеринга страницы Amazon:

На Amazon активная фаза наступает довольно быстро.

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

Предложения загружать страницу по кускам, которые дает Google PageSpeed Insights и другие похожие инструменты не что иное, как предложение внедрить метод раннего завершения. Дайте людям хоть что-то и как можно быстрее; заставьте их думать, что страница загружается быстрее, чем это на самом деле происходит, путем разбития загрузки на короткие пассивные фазы ожидания и резкого перехода в активный режим, как только подгрузятся все критически важные ресурсы. Крайне удобно контролировать такой парметр, как «начало рендеринга», в инструментах типа WebPageTest. Они дают представление о том, насколько быстрым пользователи считают сайт.

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

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

Заключение… пока что

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

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

Вы можете взять на заметку хоть все эти методы. Внимательный читатель все равно почувствует, что это не конечный список; все еще есть вопросы, на которые предстоит ответить. Что делать, если технические средства достигли своего предела, а событие до сих пор в пассивном режиме, т.е. вообще без активной фазы?

Автор: Denys Mishunov

Источник: http://www.smashingmagazine.com/

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

Современные тенденции и подходы в веб-разработке

Узнайте алгоритм быстрого профессионального роста с нуля в сайтостроении

Узнать подробнее

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

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

Получить

webformyself.com

Важнейшие рекомендации тем кто делает первый сайт

Здравствуйте уважаемые начинающие веб-мастера. Вот Вам ещё один термин — Производительность сайта.

Что такое производительность и для чего её нужно улучшать, а так же как это делать, уже очень много рассказано в рубрике SEO

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

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

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

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

Изображения

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

Не стоит даже начинать строить сайт не освоив какой либо простой фотошёп типа GIMP, и применять только облегчённые изображения оптимальных размеров.

Использовать нужный формат изображения. Например рисунок лучше форматировать в PNG а фотографии в JPEG.

Если уж вам жизненно необходимо показать картинку в полной красе и весе, то разместите её на стороннем сервере типа trueimages.ru/, и поставьте под облегчённым вариантом ссылку с анкором «Посмотреть полный размер», или как то так.

На сайте не должно быть ни одного не оптимизированного изображения.

Вид или восприимчивость страницы

Восприимчивость — характеристика того, как страница воспринимается пользователем.

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

Вид страницы должен быть прост. Возможно оригинален, возможно солиден, но при этом прост.

Избегайте большого количества рамок, меню, ссылок, расцветок, и в особенности рекламных блоков.

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

Необходимая навигация должна быть простой и немногочисленной, чтоб не рассеивать внимание. Солидная простота — основная цель.

Отсутствие излишеств — хороший плюс для ускорения загрузки страницы.

Содержание

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

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

Свои шрифты, нужно использовать с большой осторожностью, так как каждый дополнительный шрифт здорово сажает скорость загрузки.

Защита

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

Поэтому не стоит сразу ставить защиту типа BulletProof Security. Это же ещё на полдвижка кода.

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

Спам можно изолировать капчёй, или легким плагинчиком типа Kama SpamBlock, а пароль сделать посложнее и почаще менять.

В последней версии WordPress это делается в один клик.

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

На моём Бегет например, эта услуга бесплатная, и я уже давно не знаю забот с ботами тип Хруммер и т.п.

Очень рекомендую прочитать мою статью Как защитить сайт от злоумыщленников.

Рекомендации данные в ней доступны для самых начинающих.

Приложения, плагины, 3rd Party

По возможности сократить использование приложений плагинов и данных третьих сторон (Third party data).

Источники Third party data — сервисы рассылок, платёжные системы, сторонние сайты, сервисы обработки и хранения данных

Базы данных Third party data создаются на внешних платформах, и агрегируются с других сайтов. Есть много ресурсов продающих эти данные.

Естественно возникает вопрос о правомерности использования, качестве и безопасности таких данных.

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

Поэтому в настройках браузера лучше блокировать cookies сторонних ресурсов.

Pixel tags — программа пиксель, внедряемая в страницу, так же в рекламных целях.

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

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

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

Кеширование

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

Плагин создаёт статические копии файлов, получить которые браузеру гораздо легче, чем грузить из БД динамический контент.

График обновления файлов задаётся пользователем. К примеру на этом сайте статические файлы обновляются каждые 24 часа.

Кроме того плагин использует GZIP сжатие (сжатие без потерь) при передаче данных, что дополнительно ускоряет процесс.

CSS <script>

Отрисовка страницы начинается только после загрузки CSS файлов.

При создании первого сайта многие начинающие веб-мастера начинают активно изменять оформление HTML элементов.

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

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

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

Минимизируйте комментарии и пробелы в файле CSS.

Минимизируйте «тяжелые» свойства такие как box-shadow и прозрачность rgba.

Если в шаблоне подключены несколько CSS файлов, то лучше объединить их в один.

В целом используйте как можно меньше CSS и скриптов. Как я уже говорил выше основная цель — оригинальная простота.

При необходимости внедрения скрипта обеспечьте ему асинхронную загрузку (атрибут async).

Выбор хостинга

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

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

Адаптивность

Используйте только шаблоны адаптированные под мобильные устройства. Альтернативно можно адаптировать стационарный шаблон.

Уже сейчас половина трафика приходит с мобил, и что будет завтра — легко представить.

Желаю творческих успехов.

starper55plys.ru

Анализируем производительность сайта

Приступим...

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

Поскольку в заданное время слишком много переменных могут влиять на состояние front-end-а, веб-разработчики используют метод, называемый многовариантным тестированием, чтобы получить точную картину показателей производительности веб-сайта в течение времени. Что касается показателей производительности, которые должны быть проанализированы, то существует список наиболее важных показателей производительности, организованных по категориям.

Показатели скорости 

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

Для того, чтобы получить результаты многих из показателей ниже для конкретного сайта, можно запустить тест скорости ( test over) на webpagetest.org . Следует обратить внимание, что не все показатели будут отображаться на страницах итога или обзора производительности. Для того, чтобы получить доступ к более гранулированным (точным) показателям, нужно загрузить страницу необработанного  отчета данных.

 

Следующие результаты тестирования скорости сайта были взяты из стандартного теста скорости WordPress, запущенного на Nginx и KeyCDN без специальных конфигураций.

1. Время до появления названия

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

2. Time To Start Render ( время начала визуализации)

Время, прошедшее между возникновением запроса пользователя и моментом, когда содержание появляется в браузере, называется временем Time to start Render. Это также является очень важным показателем для анализа, чем раньше посетитель увидит контент, тем больше вероятность, что он останется в течение остальной части загрузки страницы.Time to start render, в данном случае, было 1019ms .

 

3. Время до взаимодействия

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

4. DNS Время поиска

- это количество времени, которое требуется провайдеру DNS для перевода доменного имени в IP - адрес. Такие сервисы, как Pingdom или WebPagetest могут быстро вычислить время  поиска DNS сайта для каждого домена, который должны найти.

5.  Время Соединения

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

Определение проблем времени подключения может быть трудным, поскольку это зависит от многих факторов. Слишком большой трафик сервера, будь то из-за пользователей или ботов, может вызвать connection times to spike. Пользователи в различных географических регионах, вероятно, испытают более длительное время соединения. Простое контролирование показателей производительности веб - сайта в течение долгого времени не может дать достаточной информации для решения проблем; можно поэкспериментировать с инструментами нагрузочного тестирования такими, как LoadStorm или JMeter, имитирующие использование тяжелого сервера. Для того, чтобы обеспечить лучшее время соединения, возможно, потребуется обновить инфраструктуру. Кроме того, можно разгрузить часть активов(assets) на CDN или сервер кэширования.

6. Время до первого байта (Time to First Byte - TTFB)

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

Статическое содержимое, которое появляется одинаковым для всех пользователей, должно быть отделено от динамического контента, который является специфичным для индивидуального посетителя. Таким образом, пользователи будут получать контент сразу, пока ожидают медленную загрузку персонализированного контента. Строгий контроль показателей и нагрузочное тестирование могут помочь разработчикам определить время исхода первых байтов.  Можно также использовать тест производительности KeyCDN для просмотра TTFB домена или одного актива(assets) из 14 тестирующих локаций.

 

7. Время последнего байта (Time to Last Byte – TTLB)

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

Сложность контента и показатели производительности веб-сайта

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

8. Общий вес

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

Выделяя отдельные показатели, такие как вес JavaScript, вес CSS, вес изображений и общий вес активов,  можно выбрать, какие категории слишком тяжелые; а затем выполнить waterfall analysis, чтобы идентифицировать актив, который должен быть изменен или удален.

9. Общий подсчёт активов (Overall Asset Count)

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

10. Домены сторонних разработчиков

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

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

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

11. Частота ошибок (Error Rate)

Первый важный, не относящийся к скорости показатель,  за которым нужно следить, - частота ошибок сайта. Среднее число проблемных запросов по сравнению с общим числом запросов и есть частота ошибок. Этот показатель, вероятнее всего, зависит от количества одновременных пользователей; чтобы проверить,  необходимо протестировать  производительность сайта при различных нагрузках.

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

Если используется KeyCDN, то можно использовать Отчетный(Reporting) раздел, чтобы увидеть, как много ошибок клиента произошли на сайте в течение определенного периода времени.

 

12. Частота отказов (Bounce Rate)

Если показатель отказов высок, это означает, что из-за чего-то  пользователи уходят без тщательного изучения сайта. Google называет такие визиты «сессиями одной страницы(single-page sessions)» , и слишком многие из них могут повлиять на SEO. Возможные причины высокой частоты отказов могут включать в себя плохо нацеленные ключевые слова, медленное время загрузки или неприглядный графический дизайн.

Если при внесении изменений показатель отказов начинает снижаться, то всё делается правильно.

13. Рейтинг страниц (Top Pages)

Можно узнать, какие из страниц привлекают большую часть трафика, просто проверив раздел Behavior section of Google Analytics . Зная, где пользователи фокусируют свое внимание, можно  получить представление о том, какой контент помогает сохранить аудиторию. Необходимо иметь в виду, что число просмотров страницы- это не только мера её уместности; количество (просмотров,репостов) страница получает через социальные сети, что также важно.

14. Скорость преобразования (Conversion Rate)  

Пожалуй, наиболее важным из всех показателей производительности, является скорость преобразования,  наиболее тесно связанная с нижней линией. Когда дело доходит до оптимизации опыта пользователей, скорость преобразования является наиболее важной, чем общие преобразования чисел, потому что она позволяет знать, делают ли пользователи то, что хочет разработчик, чтобы они делали, когда они посещают сайт. Скорость преобразования вычисляется путём простого разделения количества уникальных посетителей от количества конверсий. Google Analytics может отслеживать эту информацию в течение долгого времени, но определенные «преобразования» достигают разработчика.

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

 

Ощущаемая Производительность в сравнении с показателями производительности

Иногда цифры не говорят все, что вам нужно знать, поэтому очень важно  понять, как веб - пользователи думают. Восприятие есть все, а иногда  есть разница между тем, как много времени занимает загрузка страницы и как долго пользователь «чувствует», сколько она занимает.

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

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

Использование показателей производительности для оптимизации User Experience ( Опыта Пользователей)

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

 

drach.pro

Тестируем производительность сайта: 15 бесплатных инструментов

Я подобрал 15 инструментов для тестирования производительности и быстродействия сайта. На момент написания статьи все эти инструменты были бесплатными и не предполагали установки какого-либо программного обеспечения для тестирования.

Некоторые инструменты, такие как Webpagetest и LoadImpact, очень сложные, в то время как другие, вроде Redbot или Alertra, всего лишь осуществляют простые проверки быстродействия сайта.

Webpagetest

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

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

Водопад-диаграммы помогают отследить, какой компонент может быть причиной медленной загрузки сайта. Webpagetest также отмечает начало отрисовки страницы и момент полной ее загрузки страницы.

GTMetrix

Ещё один замечательный инструмент, позволяющий проверить быстродействие сайта. Он предоставляет оценки Google PageSpeed Grade и Yslow Grades. Я рекомендую этот инструмент, если вы хотите улучшить производительность.

Сайты на платформе WordPress зачастую получают низкие оценки в некоторых тестах из-за тем и плагинов, добавляющих дополнительные файлы CSS и JS.

Pingdom

Предоставляет прекрасные сервисы мониторинга и включает в себя бесплатный инструмент тестирования производительности веб-страниц. Главный отчёт – это водопад-диаграмма времени загрузки сайта.

Этот инструмент оценки производительности работает быстро, поэтому вам не придётся долго ждать результатов.

Отчеты позволяют легко получить заголовки ответа от каждого HTTP-запроса. Это может принести  пользу, если вы осуществляете тонкую настройку заголовков ответов HTTP для увеличения производительности.

Уделите внимание деталям. Здесь наш сайт получил 69 баллов, но время загрузки было только 0,5с. Это быстрее, чем у 97% всех протестированных сайтов.

Gomez

Этот инструмент существует уже давным-давно, но он очень полезен, если вам нужно провести тестирование из нескольких местоположений. Доступно больше 100 местоположений на выбор.

FeedTheBot

Новый сервис с множеством инструментов. Результаты их работы похожи на Google PageSpeed, но размещение и удобство использования на высоте. К каждому плохому результату теста добавляется объяснение.

 Feedthebot пригодится для объяснения клиентам проблем, связанных с оптимизацией производительности сайта.

Google Page Speed Insights

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

Dotcom Monitor

Тест производительности сайта из 20 местоположений всего в один клик. Мне нравится этот инструмент, потому что он производит полное браузерное тестирование. Отчёт включает в себя водопад-диаграммы из всех 20 местоположений! Иногда проблемы в работе Сети могут снижать производительность сайт. Но их может быть сложно обнаружить без мониторинга из разных местоположений.

Alertra

Инструмент SpotCheck от Alertra отлично подходит, чтобы быстро определить работает ли сайт при обращении к нему из нескольких местоположений. Я часто использую его, чтобы быстро проверить сайты, когда клиенты сообщают о проблемах. Обычно если тест Alertra не показывает проблем, то это значит, что проблема изолирована в узком регионе или это что-то, связанное с действиями конкретного клиента.

Which Loads Faster

Это интересная маленькая утилита позволяет посмотреть, что загружается быстрее. Вставьте два URL-адреса в форму и нажмите «Go». Это может быть полезным, если требуется проводить быстрые тесты разных сайтов или продемонстрировать клиенту, насколько быстрее сайт может загружаться с другого хостинга.

Load Impact

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

Круговая диаграмма, показывающая распределение HTTP-запросов по типу контента. Здесь мы видим, что более 40% запросов приходятся на JavaScript, что может быть улучшено слиянием js-файлов.

RedBot

Небольшая утилита для проверки HTTP заголовков. Вы удивитесь, узнав, как много сайтов имеют плохо сформированные заголовки. Они могут убить кэширование, навредить эффективности CDN-контента и привести к отображению неверных страниц на мобильных устройствах. Я использую этот инструмент, чтобы показать клиентам, какие заголовки отправляет их сайт. Если заголовки отправляет веб-приложение, они могут переслать эти отчёты своим разработчикам, чтобы исправить имеющиеся проблемы.

Uptrends

Осуществляет быструю проверку времени загрузки сайтов из 30 местоположений. Инструмент поможет обнаружить проблемы с Сетью, которые влияют на время загрузки страниц.

OctaGate Site Time

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

Быстрые отчёты с водопад-диаграммами – вот чем полезен этот инструмент. Не слишком много деталей, но тест выполняется быстро и бесплатно!

Neustar Ultratools

Набор утилит для проверки скорости работы хостинга, DNS и прочего. Его разработчики постоянно обновляет набор инструментов сервиса.

IntoDns.com

Это не инструмент тестирования. Но если DNS не работает, то сайт может быть недоступен. Проверяйте поддомены, использующиеся для CDN и другого контента, опубликованного на вашем сайте.

ManageWP

Инструмент позволяет управлять несколькими WordPress-сайтами из одного места.

Перевод статьи “15 Free Website Performance Testing Tools” был подготовлен дружной командой проекта Сайтостроение от А до Я.

www.internet-technologies.ru

Производительность сайта - Seo Shield

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

Настроить кеш браузера

Благодаря кешированию пользователи, повторно посещающие ваш сайт, тратят меньше времени на загрузку страниц. Заголовки кеширования должны применяться ко всем кешируемым статическим ресурсам, а не только к некоторым из них (например, изображениям). Кешируемые ресурсы включают файлы JavaScript и CSS, графические и другие файлы (мультимедийное содержание, файлы PDF и т. д.). Обычно код HTML не является статическим ресурсом и по умолчанию не считается кешируемым.

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

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

Этот код будет говорить вашему веб-серверу, что картинки нужно кэшировать в течении 1-го года, а CSS, HTML, PDF, JS и SWF — в течении 1-го месяца с момента первой загрузки.

Внимание! Этот код будет работать только на вебсервере Apache. nGinx этот код не воспримет.

Рекомендации по настройке:

Включите для своего сервера кеширование в браузере. Продолжительность хранения статических ресурсов в кеше должна составлять не менее недели. Внешние ресурсы (объявления, виджеты и др.) должны храниться не менее 1 дня. Рекомендуется использовать следующие установки для всех кешируемых ресурсов:

  • В заголовке Expires следует указать период от недели (минимум) до года (рекомендуется). Лучше использовать Expires, чем Cache-Control: max-age, так как он более широко поддерживается. Не устанавливайте срок больше одного года: это является нарушением правил RFC.
  • Если вы точно знаете дату будущего изменения ресурса, можно установить более короткий период. Если же конкретная дата неизвестна, лучше использовать более продолжительный срок.
  • Для всех кешируемых ресурсов нужно обязательно указывать один заголовок из пары Expires и Cache-Control: max-age, а также один заголовок из пары Last-Modified и ETag. Использовать и Expires, и Cache-Control: max-age излишне, как и указывать Last-Modified и ETag одновременно.

    Исключением являются инструменты аналитики, пример правильной настройки:

    http://www.googletagmanager.com/gtm.js?id=GTM-MFCVJQ (15 минут)

    https://mc.yandex.ru/metrika/watch.js (60 минут)

    http://www.google-analytics.com/analytics.js (2 часа)

Ответ сервера

Время ответа сервера определяет, сколько занимает загрузка кода HTML для отображения страницы. Задержка сети между Google и вашим сервером не учитывается. Это время может варьироваться в незначительном диапазоне. Если время ответа сервера колеблется слишком сильно, возможно, это связано с проблемами производительности. Время ответа сервера должно составлять не более 150 мс. Большое время ответа может быть связано с десятками факторов: логика приложения, медленная работа с базой данных, маршрутизация, программная платформа, библиотеки, нехватка процессорной мощности или памяти. Все эти обстоятельства следует учитывать при оптимизации. Первым делом необходимо измерить время ответа сервера. Затем, обладая нужными сведениями, нужно обратиться к соответствующим руководствам.

Рекомендации по уменьшению времени ответа сервера:

  • Соберите и тщательно изучите имеющиеся данные о производительности. Если они недоступны, подумайте об использовании автоматического решения для наблюдения за веб-приложениями.
  • Найдите и исправьте проблемные места. Если используется популярная веб-платформа или система управления контентом, советы по оптимизации вы найдете в документации.
  • Отслеживайте и исправляйте любые проблемы производительности.
  • Использование CSS-спрайтов. CSS-спрайт – это комбинированное изображение, которое содержит в себе несколько маленьких изображений, которые в нужный момент для нужного элемента страницы вырезаются используя свойства: background-image и background-position.
  • Использование Inline-картинок. Inline-картинки используют URL-схему data: для встраивания картинки в саму страницу. Это, однако, увеличит размер HTML-документа. Встраивая inline-картинки в ваши таблицы стилей вы добьетесь уменьшения запросов к серверу, а размер HTML останется прежним.
  • Объединение нескольких файлов в один. Если у Вас на страничке подключается больше одного css- или js-файла, то Вы можете объединить их в один. Это очень простой, но действенный способ уменьшения количества http-запросов на сервер.

Оптимизация изображений

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

Рекомендации:

Используйте инструменты сжатия изображений

Существуют инструменты, выполняющие дополнительное сжатие файлов JPEG и PNG без потерь и снижения качества. Для файлов JPEG рекомендуется использовать jpegtran или jpegoptim, Для PNG лучше использовать OptiPNG или PNGOUT.

Несколько онлайн сервисов для оптимизации изображений:

Выберите подходящий формат файла изображения

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

  • GIF – идеально подходят для изображений с несколькими цветами, например логотип.
  • JPEG – отлично подходят для детализированых изображений с большим количеством цветов, такие как фотографии.
  • PNG – ваш выбор, когда вам нужно высококачественное изображение с прозрачностью.
  • Не используйте BMP и TIFF.

Используйте Gzip- сжатие

Как показали проведенные исследования, gzip-сжатие текстового файла «на лету» в 95–98% случаев позволяет сократить время на передачу файла браузеру. Если хранить архивированные копии файлов на сервере (в памяти proxy-сервера или просто на диске), то соединение в общем случае удается освободить в 3-4 раза быстрее.

Начиная с версии протокола HTTP/1.1, веб-клиенты указывают, какие типы сжатия они поддерживают, устанавливая заголовок Accept-Encoding в HTTP-запросе.

Accept-Encoding: gzip, deflate

Если веб-сервер видит такой заголовок в запросе, он может применить сжатие ответа одним из методов, перечисленных клиентом. При выдаче ответа посредством заголовка Content-Encoding сервер уведомляет клиента о том, каким методом сжимался ответ.

Content-Encoding: gzip

Переданные таким образом данные меньше первоначальных примерно в 5 раз, и это существенно ускоряет их доставку.

Проверка внедрений будет осуществляться через онлайн сервисы:

  • удовлетворительным показателями для Pingdom будет оценка выше 80 баллов или B
  • удовлетворительным показателями для PageSpeed Insights будет оценка выше 80 баллов или зеленая отметка для Desktop-версии сайта.
  • ответ сервера до 150 мс.

Проверяться будут основные типы страниц сайта:

help.seoshield.ru

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

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

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

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

До начала любых работ по оптимизации производительности сайта, нам необходимо узнать основные системные показатели нашего сервера. Крайне важно знать такие метрики, как текущая загрузка процессора, количество занятого дискового пространства, использование оперативной памяти и разделов swap. Большинство из них можно увидеть при помощи системной программы "top", либо её аналога (более наглядного для начинающего пользователя) "htop".

Для начала нас интересует метрика «load average», представленная тремя числами. Эти числа отражают число блокирующих процессов в очереди на исполнение в определенный временной интервал, а именно 1 минута, 5 минут и 15 минут соответственно (в данном случае, блокирующий процесс — это процесс, который ожидает выделения ресурсов для продолжения работы). Высокие значения показателей «load average» (более единицы) говорят о том, что система не справляется с нагрузкой. Если речь идет о целевом сервере, работающем под высокой нагрузкой, то обычно полезно провести тонкую настройку операционной системы (сетевая подсистема, ограничение на количество одновременно открытых файлов и тому подобное). Высокая загрузка также может быть вызвана аппаратными проблемами, например, выходом из строя накопителя.

Серверное «железо» также является важнейшим критерием хорошей производительности сайта. Кроме того, что все компоненты должны удовлетворять современным требованиям и быть в принципе работоспособными — необходимо так же настроить сервер на их оптимальную работу.

Кроме сетевого подключения, о котором говорилось выше, важнейшими компонентами сервера являются также Процессор, Оперативная память и Жесткий диск.

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

Жесткий диск

Например, жесткий диск. Для хорошей производительности он должен иметь не только достаточный объём и скорость передачи данных, но и подходящую файловую систему. Например, популярная журналируемая файловая система Ext3, которая была стандартной во многих дистрибутивах Linux, имеет проблемы с производительностью, при работе с большим количеством маленьких файлов.

Чтобы избежать проблем с производительностью Ext3, можно, например, провести оптимизацию файловой системы.

Оперативная память

Большой объём оперативной памяти также зачастую не является залогом быстродействия. Важным критерием является корректное распределение памяти между процессами и оптимальное использование «swap'a». Следует учесть, что Linux в отличие от Windows старается "забрать" всю оперативную память прежде чем использовать swap, поэтому если ваш Linux-сервер постоянно и активно использует swap – у вас проблемы.

Для определения возможных проблем, мы можем воспользоваться shell-программой «top», о которой говорилось ранее. С её помощью мы можем увидеть такие метрики, как: полный объём оперативной памяти, количество занятой и свободной оперативной памяти, а так же метрики потребления swap-памяти.

Также, при наличии проблем с производительностью, удобно будет воспользоваться программой «ps» (process status) с опциями "a", "u" и "x" (ps aux), которая выводит отчёт о работающих процессах. Полученный вывод предоставит список процессов, а также нужную информацию: потребление процессора, памяти, состояние и непосредственно информацию, идентифицирующую процесс (PID и команду).

Напоминаем, что такие команды как top или ps следует запускать "от рута" (sudo top или sudo ps соответственно), так как не-руту обычно не "видны" все процессы в системе.

Советуем также обратить внимание на такие возможности, как использование технологии «RAM Disk» (при необходимости ускорить скрипты, теряющие скорость на доступ к файловой системе) и настройка параметра «swappiness» в Linux-системах (если swap начинает заполняться до того, как использована вся оперативная память).

Процессор

Для начала выясним, какой процессор (или несколько) установлен на нашем сервере. В Ubuntu Linux мы можем воспользоваться командой «cat /proc/cpuinfo», которая покажет нам подробную информацию по каждому имеющемуся процессору. В остальных ОС для этого также можно найти подходящие аналоги.

Снова обратимся к данным, которые даёт нам вывод «top». Строка Cpu(s) содержит информацию о распределении процессорного времени. Первые два значения (“us” и “sy”) непосредственно отражают работу CPU по обработке процессов (пользовательских и системных процессов соответственно). Если они показывают значения 99-100% долгое время — это указывает на CPU как на узкое место.

Параметр "wa" говорит о простое, связанным с вводом/выводом. Выше 80% считается не совсем нормальным и явно указывает нам на то, что процессор проводит очень много времени в ожидании ввода/вывода (обычно это означает, что медленно работает или даже выходит из строя HDD или NIC).

Если же оборудование в порядке и ЦП имеет адекватные характеристики, - скорее всего, проблема в ПО. Проблемное приложение можно отловить с помощью указанной выше программы «ps» с опциями "a", "x", "f" и "u" (ps axfu).

Опытные разработчики также могут узнать, как нагружают процессор php-скрипты, воспользовавшись функцией «getrusage()».

Типичным серверным ПО, при работе сайта на Linux-сервере, являются Apache, MySQL и PHP. Аналогично аппаратному обеспечению, обычная установка данного ПО, со стандартными параметрами не всегда является достаточной для корректной и быстрой работы сайта.

Существует множество вариантов настройки каждого элемента под конкретные нужды вашего сайта. Рассмотрим несколько общих вариантов:

Apache

Самым популярным рецептом является связка веб-сервера «Apache» с проксирующим сервером «nginx». В Интернете можно найти множество информации по этому поводу, в том числе конкретные действия, которые нужно произвести для стабильной работы этой связки. Скажем только, что в нашем случае надо уделить особое внимание отдаче nginx'ом статики (об этом так же можно найти множество статей и «how-to»). Дальнейшие поиски покажут и другие мелкие вещи, на которые стоит обратить внимание (например, целесообразность отключения режима «keepalive» при использовании данной связки, или решение возможных проблем, таких как ошибка «504 Gateway Timeout»).

Что же касается apache, как такового — рекомендуем обратить внимание на такую вещь, как «Количество процессов apache». Для настройки используются параметры ServerLimit и MaxClients в конфигурационном файле веб-сервера. Менять их следует с осторожностью и только при полной уверенности в необходимости такого изменения! Если значение ServerLimit установить намного выше необходимого, то свободная совместно используемая память будет занята (ассигнована, allocated). А если ServerLimit и MaxClients установить выше, чем система может обрабатывать, то Apache может не запуститься или система станет нестабильной.

MySQL

С оптимизацией и ускорением работы mysql-сервера также связано множество статей в Интернете. В рамках данной статьи мы можем посоветовать использование весьма полезной утилиты «mysqltuner», а также предложить вашему вниманию статью про кэширование в MySQL для высокопосещаемых проектов.

В двух словах, оптимизация MySQL заключается, в основном, в том чтобы выделить довольно много оперативной памяти для кэшей. Вся остальная оптимизация заключается в определении и рефакторинге “медленных” SQL-запросов конечного приложения (в этом вам поможет «slow query log»).

PHP

Первое, на что следует обратить внимание при разговоре о php в свете производительности — это то, что php должен быть установлен как модуль Apache, а не работать в режиме FastCGI. Правильная настройка php в режиме “fastcgi” требует дополнительной квалификации и опыта, поэтому начинающим разработчикам не рекомендуется её использовать – результат будет только хуже. Достаточно статей с подробной информацией о достоинствах и недостатках обоих вариантов можно найти в Интернете.

Теперь поговорим об акселераторах php. UMI.CMS поддерживает eAccelerator, XCache, APC (Alternative PHP Cache) и связующее программное обеспечение memcached, которое выполняет схожие функции. Каждый из этих механизмов повышает производительность php своим методом. Так, например, eAccelerator делает это за счет кэширования скомпилированного байт-кода, а memcached позволяет кэшировать данные в “быстром” хранилище. Для оптимальной работы конкретного сайта следует выбрать подходящий механизм и настроить его под ваши конкретные нужды.

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

dev.docs.umi-cms.ru

Анализ HTTP-запросов и влияния их числа на производительность WordPress

От скорости загрузки современного веб-сайта зависит удержание посетителей, их вовлеченность и, в конечном итоге, конверсия. В свою очередь, на скорость загрузки сайта влияет множество факторов, и один из наиболее существенных – количество HTTP-запросов.

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

Что такое HTTP-запрос?

Когда браузер отображает страницу, он запрашивает у веб-сервера по протоколу HTTP различные статические компоненты страницы (например, стили CSS, скрипты JavaScript или изображения), и сервер отвечает, посылая браузеру соответствующие файлы.

Запрос, посылаемый браузером серверу при помощи HTTP, называется «HTTP-запрос».

Анализ HTTP-запроса

Чтобы лучше понять смысл HTTP-запроса, взгляните на HTML-код простой веб-страницы:

Как видите, данная страница содержит в себе 4 HTTP-запроса.

Влияние числа HTTP-запросов на WordPress

Как сказано в Правилах производительности Yahoo:

80% времени отклика среднего веб-сайта зависит от работы фронтенда. Большая часть этого времени уходит на загрузку всех компонентов страницы: графики, стилей, скриптов, Flash-анимации и т. д.

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

Из вышеприведённой цитаты мы можем справедливо заключить, что, чем меньше количество HTTP-запросов, тем быстрее сайт. Поэтому средний сайт на WordPress, содержащий множество изображений, стилей и скриптов, склонен быть медленным.

Подсчёт числа HTTP-запросов

Число запросов, содержащихся в одной странице, несложно подсчитать с помощью расширения для браузера Firefox, которое называется Firebug, или встроенного в браузеры Opera и Google Chrome инструмента «Inspect Element».

Используем Firefox

Убедитесь, что Firebug установлен:

  • Откройте ваш блог на WordPress и нажмите F12, чтобы открыть консоль Firebug;
  • Перейдите на вкладку «Сеть». Если она запрещена, разрешите её;
  • Обновите страницу вашего сайта, чтобы Firebug захватил и записал все HTTP-запросы;
  • Вы увидите общее количество запросов в нижней части вкладки:

Используем Google Chrome или Opera

В отличие от Firefox, в Opera или Google Chrome нам не потребуется устанавливать какие-либо расширения. Мы можем использовать инструменты, встроенные в эти браузеры.

Следующие шаги можно использовать в обоих браузерах:

  • Откройте ваш сайт на WordPress;
  • Щёлкните правой кнопкой мыши на странице и выберите пункт «Исследовать элемент»;
  • Перейдите на вкладку «Сеть» и обновите страницу сайта;
  • Вы увидите общее количество запросов в нижней части вкладки:

Знаете ли вы, что установка большинства плагинов для WordPress увеличивает количество компонентов на странице, тем самым увеличивая количество HTTP-запросов?

Как плагины и темы увеличивают число HTTP-запросов

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

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

Чтобы понять, как происходит увеличение количества HTTP-запросов, рассмотрим в качестве примера плагин WP Subscriber Form.

Активация плагина поместит форму подписки в подвал поста, а также включит ссылку на свой файл стилей в страницу WordPress:

Просматривая исходный код страницы после активации плагина можно обнаружить добавление ссылки на новый CSS-компонент, что означает один добавочный HTTP-запрос:

Темы WordPress, аналогично плагинам, содержат много CSS и JavaScript-включений. Типичная тема содержит несколько шрифтов, файл стилей JavaScript-компоненты и библиотеки, что ведёт к росту числа запросов.

Как соотносятся минимизация и HTTP-запросы

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

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

Как уменьшить число HTTP-запросов на WordPress-сайте

Чтобы уменьшить количество HTTP-запросов, нужно сделать так, чтобы страница содержала меньше изображений, стилей и скриптов.

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

WordPress использует в своих темах CSS-тэг background-image. Вы можете перевести изображения, загружаемые этим тэгом, в спрайты.

Производительность WordPress может быть значительно улучшена, если CSS и JavaScript-файлы тем будут объединены между собой и минимизированы.

Существуют специальные плагины для WordPress: WP Minify и Better WordPress Minify. Я сам использовал эти плагины и с удовольствием рекомендую их вам. Они объединяют файлы стилей и скриптов и тем самым уменьшают число HTTP-запросов.

Если вы используете плагин W3 Total Cache, то в вышеприведённых плагинах нет необходимости, так как W3 Total Cache имеет опции для комбинирования и минимизирования стилей и скриптов:

Будучи веб-разработчиком, я редактирую плагины, которые добавляют компоненты в WordPress, вырезая из них JavaScript и CSS, комбинируя их и помещая внутрь скриптов и стилей моей темы.

Заключение

Трудно переоценить значение ускорения работы веб-сайта. Медленный сайт отталкивает посетителей.

Существует много приёмов ускорения работы веб-сайтов, один из которых – уменьшение числа HTTP-запросов – мы и рассмотрели в этой статье.

Перевод статьи «Analysis and Effects of HTTP Requests on WordPress Performance» был подготовлен дружной командой проекта Сайтостроение от А до Я.

www.internet-technologies.ru