Скорость ответа сервера


С помощью этого инструмента можно проверить код и скорость ответа сервера, наличие gzip сжатия, посмотреть все заголовки ответа, проверить отдачу сервером 304 Not Modified.

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

При необходимости вы можете добавить заголовки к запросу. Например, If-Modified-Since, User-Agent или любые другие.

От чего зависит время ответа сервера

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

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

Нормальное время ответа — это сколько?

Чем меньше, тем лучше.


  • До 300 миллисекунд — очень хороший результат, можно спать спокойно.
  • От 300 до 700 миллисекунд — тоже неплохо, волноваться повода нет.
  • Если время ответа вашего сайта приближается к секунде, или ещё выше — повод принимать меры.

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

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

Коды ответов HTTP

Код состояния HTTP — это число, состоящее из трех цифр. Первая цифра означает группу, к которой принадлежит код.

Существуют следующие группы:

  • 1xx — Информационные коды
  • 2xx — Успешные коды
  • 3xx — Коды перенаправлений
  • 4xx — Коды ошибок клиента
  • 5xx — Коды ошибок сервера

Проверка 304 Not Modified

Правильно настроенный сервер должен обрабатывать заголовок If-Modified-Since. Этот заголовок содержит дату и спрашивает, была ли изменена страница после этой даты. Если страница не была изменена, сервер должен вернуть ответ 304 Not Modified. При этом ответ содержит только заголовки и не содержит тело страницы. Это значительно экономит время и трафик при обходе вашего сайта поисковыми роботами.

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

calcus.ru

Зачем проверять скорость хостинга?

Владельцам сайтов даже при огромном желании не обойтись без проверки минимум трех параметров производительности их ресурсов. Нужно знать:

  1. скорость воссоздания веб-страницы хостингом;
  2. скорость отклика сервера (доступ к ресурсу);
  3. скорость открытия конкретной персональной страницы в браузере.

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

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

Рекомендую прочитать статью «Список плагинов, которые улучшают функциональность моего блога. Проверено мной лично»

Пятерка лучших

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

№1 — http://pr-cy.ru/speed_test. Пожалуй, самый любимый из всех присутствующих! Бесплатный функционал позволяет в считанные мгновения получить интересующую вас информацию.

Сервис не только расскажет, за какое  время загрузится ваш сайт в браузере пользователя, но и подскажет как сделать его лучше. Достаточно ввести адрес нужного вам ресурса в соответствующую строку и нажать кнопку «Анализировать».
Сервис pr-cy

№2 — http://host-tracker.com/. Позволяет определить скорость загрузки сайта с любого уголка земного шара. Поэтому, если вы планируете работать с русскоязычными пользователями, тогда обратите свое внимание на отклик ресурса именно в России.


Сервис host-tracker

№3 — http://www.whoishostingthis.com. Еще один достаточно неплохой ресурс. Зарегистрировавшись здесь, можно с легкостью проверить аптайм сервера.

№4 — http://dnsstuff.fastnext.ru/. Этот русскоязычный ресурс позволяет мгновенно проверить основные показатели сайта.  Кроме того, на этом сайте присутствует достаточно незаменимая функция под названием DNSReport, которая может вам рассказать, есть ли у вас проблемы с DNS.
Сервис dnsstuff.fastnext.ru

№ 5 — Page Speed Insights

Хочу отдельно поговорить о Page Speed Insights. Этот сервис от Google измеряет скорость загрузки веб-страниц. Еще определяет, как можно улучшить некие показатели вашего ресурса, например:

  • время загрузки верхней части интернет-страницы
  • время полной загрузки web-страницы
  • Время вычисляется с момента запроса веб-страницы до момента отображения ее в браузере.

Особенность Page Speed Insights в том, что URL проверяется два раза – обычным и мобильным агентом пользователя. Оценка выставляется от 0 до 100 баллов. Чем больше – тем лучше. Оценивание более чем в 85 баллов говорит о том, что веб-страница загружается быстро.

Сервис PageSpeed Insights

Применив рекомендации сервиса, вы можете оптимизировать скорость загрузки вашего ресурса.

Каждый совет обозначается индикатором приоритета, который соответствует ее важности:

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

Не забываем о пинге

Немаловажно при оценке скорости хостинга учитывать показатели пинга.

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

Пошаговая инструкция для проверки пинга:

  1. Находим в меню «Пуск» компьютера раздел «Выполнить»
  2. Прописываем в появившемся окошке: cmd
  3. В черном окне пишем: ping domen-vashego-saita.
  4. Анализируем полученные данные. Смотрим на время ответа. Чем ниже показатель, тем лучше работает хостинг.

проверка пингом

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

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

С уважением! Абдуллин Руслан

abdullinru.ru

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

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


Целевая аудитория: владельцы сайтов, web-студии, специалисты и любители. Постараюсь написать статью таким образом, чтобы она была доступна в понимании всем.

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

Мощность и качество устройства клиента, а так же скорость его интернета и удалённость от локации сервера

Мы можем купить клиенту нормальный компьютер и подключить ему высокоскоростной интернет и более не будем испытывать проблем с этим фактором (конечно же, я шучу). Хотя я бы определённо чаще посещал сайты, владельцы которых обновляли бы мне компьютер и оплачивали интернет. Кроме шуток, что мы на самом деле можем сделать, если у клиента слабый интернет и маломощное устройство?

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

2. Чем слабее устройство, тем дольше оно создаёт новые соединения с сервером, а значит, нам нужно сократить количество этих соединений.


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

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

image

image

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

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


Разобьём этот промежуток на подпункты:

1.1 Отправка запроса браузером клиента.

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

Далее до того момента, как сервер отправит готовую страничку в ответ, проходит несколько этапов, и для каждого конкретного сайта этапы могут отличаться. Я возьму в пример сайт на php с БД MySQL.

1.2 Запрос принимается web-сервером, он находит в списке виртуальных хостов тот, что подойдёт под запрос и производит обработку виртуального хоста, в нашем примере сайт на php, значит web-сервер обратится к php для генерации странички, тот в свою очередь для наполнения странички данными обратится в БД. После формирования странички она будет передана web-сервером браузеру клиента.

Очень важную роль играет кэширование на каждом этапе, кэширование на уровне web-сервера, кэширование на уровне php (opcache), кэширование запросов в БД (memcache), могут быть и другие варианты кэширования, я привёл эти как наиболее распространённые. Это как раз тот этап на который Вы можете повлиять и этому этапу нужно уделить время.

Вот способы его ускорения.

  • Выбрать быстрый хостинг или даже лучше VPS, VDS или даже физический сервер. Если вы не компетентны в таком выборе, лучше попросите помощь у специалиста или спросите рекомендации от знакомых, которые уже пользуются теми или иными хостерами. Обратите внимания на то где расположен дата-центр хостера: идеально, если он будет располагаться в непосредственной близости от ваших потенциальных клиентов. Я лично использую зарубежные сервера, если только на сайт осуществляются DDOS-атаки, Российские хостеры предосталяют защиту от DDOS низкого качества, и тут уже приходится мириться с пингами и задержкой.

  • Правильная настройка сервера поможет ускорить ответ от него. Тут играют роль выбор более шустрого ПО и правильное его конфигурирование. Для web-сервера я использую Nginx, где по возможности использую hhvm совместно с php 7.1, выбор версии php, а так же hhvm по большей части ещё и зависит от кода вашего сайта: если сайт использует устаревшие функции, то вам или придётся обновлять его или довольствоваться старыми версиями, имеющими не столь высокую производительность. Ну и в качестве БД использовать MariaBD или даже Perсona, если у вас более крупный проект. Также не стоит забывать о защите: антибруты, фильтры от типовых атак, http-авторизация как дополнительная авторизация на всех админках, антиспамы, антивирусы и прочее.

1.3 Отправка сгенерированной странички клиенту и момент получения этой странички и будет завершающим этапом этой части загрузки страницы. Тут для уменьшения объёма отправляемых данных лучше всего использовать gzip сжатие.

Хочу сделать поправку, у меня на скрине ответ сервера для сайта Хабра равен 3,48 с — это плохое время, но Хабр тут по сути не виноват. У меня 3G интернет посредственного качества. Поэтому конкретно этот этап загрузки рекомендую отслеживать при помощи сервиса. Я использую для этого сервис проверки ответа сервера от Яндекс.

image

Код статуса HTTP должен быть 200.

Ответ сервера тут заметно меньше, чем на моём 3G интернете. В идеале время ответа сервера должно стремиться к нулю, но как минимум он не должен превышать 200 мс, хотя это лично мой критерий. Хотя нет, не только мой. Google PageSpeed если я не ошибаюсь тоже следит, чтобы ответ сервера не превышал 200 мс и, если сайт превышает рекомендованное время, то предупреждает, что нужно сократить ответ сервера.

Ну и в самом низу мы можем увидеть, что ответ сжат при помощи gzip.

Хабр прошёл первый этап загрузки на пятёрочку (нет-нет, я вовсе не подлизываюсь).

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

2. DOMContentLoaded — именно так этот этап загрузки страницы называется в инструментах разработчика, а если по-простому, это тот самый момент когда визуальная загрузка страницы закончена.

На что тут нужно обратить внимание.

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

Как же их сократить? В http/1.0 и http/1.1 для каждого отдельного файла создаётся отдельное соединение, значит наша задача сократить количество подгружаемых файлов на страничке.

  • Объединить все css в один файл и все js в один файл, эта процедура называется конкатенация.
  • Поместить мелкие картинки в закодированном виде прямо в css или в тело страницы чтобы для них не создавались отдельные соединения.
  • Возможно избавиться от загрузки каких-то не нужных элементов, и по возможности отсрочить загрузку js или поместить их в конец ну или хотя бы сделать их загрузку асинхронной. CSS тоже, кстати, было бы неплохо оптимизировать.
  • Если отложить загрузку css, то страничка при сёрфинге по сайту будет моргать, — на мой взгляд, это неприемлемо, но мы ведь можем загрузить css нужный для отображения верхней части сайта в начале, а остальное потом. Тут лучше проконсультироваться с верстальщиком, я им не являюсь, поэтому не воспринимайте данные рекомендации буквально.
  • Перейти на http/2, данная версия протокола позволяет грузить все элементы в один поток не создавая лишних соединений. И самые догадливые уже подумали, так зачем тогда выполнять первые две рекомендации если можно просто перейти на http/2, сейчас поясню. На данный момент http/2 ещё поддерживается не всеми устройствами, поэтому часть клиентов продолжат пользоваться сайтом на предыдущих версиях протокола, так что эта рекомендация поможет ускорить загрузку страницы для свежих девайсов с актуальными версиями браузеров.

image

Вот тут наглядно видно на сколько меньше соединений создаётся при использовании http/2

2.2 Вес страницы и элементов, подгружаемых с неё.

  • Убрать лишние комментарии в коде.
  • Использовать сжатие.
  • Оптимизировать контент сайта, сжать и объединить css и js, сжать картинки и пр.

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

Модуль для web-сервера PageSpeed. Он есть и для nginx — ngx_pagespeed и для apache2 — mod_pagespeed. О том что он может делать, лучше подробнее почитать в официальной документации, его настройки очень гибкие. Я только отмечу, что он способен выполнять конкатенацию на лету что поможет сократить количество соединений и он же отлично жмёт контент, сокращая вес странички и её содержимого.

На этом этапе я могу поставить Хабру твёрдую 4 и то только за отсутствие http/2, хотя я бы наверное ещё сократил объём подгружаемых элементов и сделал конкатенацию.
Этот этап загрузки странички в идеале не должен превышать 2-3 сек(хотя предела совершенству нет конца и у меня есть клиенты, которые хотят быстрее даже при скорости загрузки меньше 1сек). Если у вас это время больше, вам стоит задуматься над рекомендациями, которые я дал выше.

3. Load — это тот момент, когда колёсико браузера перестало крутиться, то есть произошла полная загрузка страницы. Это менее критичный этап загрузки и он зачастую затормаживается сторонними чатами для общения с клиентами на сайте и прочими второстепенными элементами. Если вы выполните рекомендации, которые я дал выше, то этот этап тоже станет быстрее. Ещё хотел бы отметить что если у вас не высоконагруженный проект и при этом у вас VPS, VDS или физ. сервер, постарайтесь, чтобы вся статика грузилась только с вашего сервера. Размещение статики на сторонних сайтах и в CDN принесёт пользу только при высоких нагрузках, а для не нагруженных сайтов сыграет только в минус.

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

5. Данной цифрой на скриншоте я обозначил место, где отображается количество загружаемых элементов на страничке и вес странички со всеми элементами. Нужно учитывать что если для ПК не проблема загрузить страничку в 2,5 Мб, то для мобильного браузера со слабым 3G это становится более проблематично. В частности у меня 3G интернет и Хабр у меня грузится не так быстро как другие сайты. Для мобильных устройств в идеале, чтобы страничка весила меньше 1 Мб. Тут или сокращать размер всего контента на страничках или делать мобильную версию.

P.S.

Плюсы загрузки контента со стороны:

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

Минусы загрузки контента со стороны:

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


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

Надеюсь, данная статья оказалась для вас познавательной.

habr.com

Что такое TTFB?

TTFB (Time To First Byte) — время до получения первого байта веб-страницы после отправки запроса со стороны клиента. Чем меньше этот показатель, тем быстрее браузер начнет загружать страницу.

Кстати, специалисты MOZ провели исследование о связи TTFB и позиции страницы в выдаче. Главный график в статье:

Специалисты MOZ провели исследование о корреляции TTFB и позицией страницы в выдаче

По рекомендациям Google, показатель TTFB не должен превышать 200 мс, а в идеале должен быть не более 50 мс. Если время ответа больше, потребуется определить причину и устранить её.

Как проверить TTFB?

Использовать отладчик в браузере

Для проверки TTFB можно использовать отладчик браузера. Например, в Google Chrome и Mozilla Firefox отладчик запускается комбинацией клавиш «Ctrl+Shift+I». После этого необходимо выбрать вкладку «Network» (Сеть), перезагрузить страницу и отфильтровать ресурсы по типу HTML (Doc). Далее нужно выбрать текущую загруженную страницу и во вкладке «Timing» в строке «Waiting» будет указано время ответа сервера.

Далее нужно выбрать текущую загруженную страницу и во вкладке «Timing» в строке «Waiting» будет указано время ответа сервера

Получить данные из Google Analytics

Необходимо перейти по пути «Поведение» — «Скорость загрузки сайта» — «Обзор». Далее в блоке «Среднее время ответа сервера (сек.)» будет указан TTFB за выбранный промежуток времени.

Далее в блоке «Среднее время ответа сервера (сек.)» будет указан TTFB за выбранный промежуток времени

Использовать PageSpeed Insights

Также можно использовать инструмент PageSpeed Insights. Введите URL веб-страницы и запустите анализ. После завершения анализа при наличии проблемы с TTFB вы сможете в увидеть это показатель в блоке «Сократите время от сервера».

Также можно использовать инструмент PageSpeed Insights

Использовать Netpeak Spider

Netpeak Spider — десктопный краулер для комплексного SEO-аудита всего сайта. Чтобы узнать время ответа сервера с помощью этого инструмента, вставьте URL в адресную строку, запустите сканирование (кнопка «Старт») и выберите столбец «Время ответа сервера».

Netpeak Spider — десктопный краулер для комплексного SEO-аудита всего сайта

Кстати, если TTFB страницы составит более 500 мс, Netpeak Spider покажет ошибку средней степени критичности. Все такие страницы можно удобно отфильтровать после сканирования — просто кликните на искомую ошибку в правой панели:

Все такие страницы можно удобно отфильтровать после сканирования — просто кликните на искомую ошибку в правой панели

Использовать сторонние сервисы

Простой и удобный инструмент — Webpagetest. Узнать значение TTFB можно в колонке «First Byte»:

Простой и удобный инструмент — Webpagetest

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

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

Что может быть причиной большого TTFB?

На время ответа сервера плохо влияет:

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

Для определения точной причины необходима помощь опытного программиста и системного администратора.

Как уменьшить время ответа сервера?

Оптимизировать работу с базой данных

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

Например, при формировании блока «с этим товаром также покупают» выполняются следующие запросы:

  1. Определить текущий товар.
  2. Определить количество добавлений текущего товара в корзину.
  3. Определить товар, который добавлялся вместе с текущим в корзину.
  4. Исключить незавершенные заказы.
  5. Сформировать список наиболее часто покупаемых товаров вместе с представленным.

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

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

Переехать на более производительный сервер

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

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

Использовать акселераторы PHP

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

Популярные акселераторы:

  • Alternative PHP Cache (APC);
  • eAccelerator;
  • PhpExpress;
  • Windows Cache Extension for PHP;
  • XCache;
  • Zend OPcache.

Использовать серверное кэширование

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

На тестовом сайте я настроил серверное кэширование страниц — время ответа сервера уменьшилось в десять раз.

TTFB с отключенным кэшированием:

TTFB с отключенным кэшированием

TTFB с включенным кэшированием:

TTFB с включенным кэшированием

Вывод

Работайте над сокращением времени ответа сервера и не экономьте на производительности процессоров. Если ваш TTFB больше 200 мс, обязательно:

  • оптимизируйте работу с базой данных;
  • используйте более производительный сервер;
  • используйте акселераторы PHP;
  • настройте серверное кэширование страниц.

В результате можно уменьшить время ответа сервера в 5-10 раз.

Читайте также, как ускорить сайт с помощью CDN-сервиса.

netpeak.net

1. Как вычислить кривой плагин?

Тут все просто: сначала вырубаем СРАЗУ ВСЕ плагины и смотрим на результат:
15 — столько SQL запросов к базе.
0,937074 — за столько сгенерировалась страница.
Как видите, мало что изменилось, а это значит, что плагины не причем. Эта теория проверена, идем дальше…

2. Как проверить шаблон WordPress?

Тут действуем сначала по той же схеме, закачиваем какой-нибудь бесплатный шаблон, вставляем в него наш код и смотрим на результат.
27 — столько SQL запросов к базе.
1,170909 — за столько сгенерировалась страница.
Мда, результат тот же, значит тема не при чем, нужно рыть дальше.

3. Как проверить сайт на вирусы?

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

4. Как проверить базу данных?

У меня ушли сутки, прежде чем я решил проблему. Сразу хочу показать результат:

29 — столько SQL запросов к базе.
0,168516 — за столько сгенерировалась страница.

Видите разницу? 1,2 секунды или 0,16 секунд? Это разница в ДЕСЯТЬ РАЗ! Как мне этого удалось достичь?

Как я и предполагал, дело было в базе данных. Никакие чистильщики не помогали, и тогда я стал делать все вручную. Очень помогла ВОТ ЭТА СТАТЬЯ, не знал о таких приемах при работе с базой данных.

Первое, что я сделал, это отсортировал таблицы базы данных, чтобы увидеть, что занимает больше всего места. Получилось вот что:

Сократите время ответа сервера wordpress

Самыми большими и поэтому вызывающими подозрение были 4 таблицы, в порядке убывания:

post — в этой таблице хранятся все статьи, к ней вопросов быть не может.
options — тут хранятся все настройки и к этой таблице вопросы есть.
postmeta — тут хранятся мета описания к статьям — к ней вопросы есть.
comments — в этом разделе хранятся комментарии, к нему вопросов нет.

Сначала я взялся за таблицу POSTMETA и вычистил из нее немного мусора, в основном кэш, который оставил один плагин. Но все это не помогло. Тогда я взялся за таблицу OPTIONS.

Я установил плагин Clean Options (плагин создан ИСКЛЮЧИТЕЛЬНО для чистки ЭТОЙ таблицы), который нашел у меня более ТЫСЯЧИ осиротевших опций! Я удалил примерно 700 ненужных строк из таблицы, осталось 300, которые кажется нужны.

Сократите время ответа сервера вордпресс

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

Далее я сделал так: скачал эту таблицу на компьютер и открыл в обычном текстовом редакторе (лучше для разработчиков, у меня в линукс это Geany), сделал перенос строк и сразу увидел, что занимает ОГРОМНОЕ количество места!

Как сократить время ответа от сервера?

Виновником всему был cron! Если не знаете что это, то вот для справки:

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

Я ничего не планировал, и я даже не знаю, какой плагин создал столько заданий! Я зашел в PHPMYADMIN и нашел в этой таблице этот раздел, затея я его безжалостно удалил! Таблица сократилась с 3,5 мегабайт до 168 килобайт! После этого сайт стал летать как ошпаренный!

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

Если вы знаете, почему у меня все так вышло и как этого избежать в будущем, то охотно послушаю экспертный совет. А в целом я ОЧЕНЬ рад, так как сутки у меня были мысли только об этом. Осталось только все это сделать на других сайтах, вдруг и там есть эта проблема, пусть и не в таком масштабе? И напоследок похвастаюсь, плагин кэширования отключен:

скорость загрузки сайта

1,7 секунды — это кажется круто?

Как найти мусор от плагинов?

Нашел еще такой интересный плагин — Plugins Garbage Collector. Он сканирует базу данных и ищет таблицы, которые не принадлежат самому wordpress:

Plugins Garbage Collector

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

zmoe.ru

Какое должно быть время ответа сервера?

Рекомендуемые показатели следующие:

  • Максимальный приемлемый показатель – до 200 мс.
  • Оптимальный показатель – до 50 мс.

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

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

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

Внизу формы появятся результаты проверки:

инструмент проверка ответа сервера в Яндекс.Вебмастер

Здесь можно посмотреть код ответа сервера (должен быть 200 для существующих страниц), IP сайта, кодировку, размер страницы, а также – время ответа в мс. В нашем случае – это 23 мс.

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

Критичная ошибка «Долгий ответ сервера» в Яндекс.Вебмастер. Что делать?

Если сервер отвечает очень долго, Яндекс посчитает это критичной ошибкой и выведет соответствующее уведомление в Яндекс.Вебмастере на вкладке «Диагностика сайта»:

критичная ошибка долгий ответ сервера

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

Если вы получили уведомление об ошибке «Долгий ответ сервера», сразу принимайте меры:

  1. Проверьте время ответа сервера у страниц вашего сайта. При появлении ошибки в Яндекс.Вебмастере можно посмотреть список страниц, при загрузке которых возникли проблемы.
  2. Если время ответа сервера превышает 200 мс, следуйте рекомендациям по улучшению данного показателя. Они будут написаны ниже. После улучшения показателя нажмите на кнопку «Проверить» справа от ошибки (на скриншоте выше кнопка уже нажата).
  3. Если время ответа сервера не превышает 200 мс, напишите в поддержку Яндекс.Вебмастер. Возможно, уведомление получено по ошибке или в момент визита роботов наблюдались временные сбои. В любом случае, лучше разобраться в ситуации.

Как сократить время ответа сервера?

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

Чтобы уменьшить время ответа сервера:

  1. Сократите количество запросов к базе данных. Например, в шаблонах WordPress прописано несколько обращений к базе, в которых берется название сайта, адрес файла с CSS и другие параметры, статичные для конкретного проекта. Вместо запросов в шаблоне можно прописать данные вашего сайта, и количество запросов к базе сократится. Если вы не являетесь специалистом, то можете заказать услуги по ускорению сайта в компании 1PS.ru или у программистов-фрилансеров.
  2. Включите кеширование сайта. Это позволит значительно уменьшить время ответа сервера на WordPress и других системах управления. Например, в случае блога http://adblogger.ru/ пришло уведомление из Яндекса о долгом ответе сервера. Проверка показала, что сервер отвечает за 500-550 мс. Проблема оказалась в плагине кеширования, который не работал. После исправления ошибки время ответа сервера сократилось до 20-25 мс.
  3. Обратитесь к специалистам, которые помогут оптимально настроить ваш хостинг.
  4. В ряде случаев сервер отвечает долго из-за нехватки ресурсов. В этом случае поможет приобретение новых ресурсов или переезд на более мощное оборудование.

Выводы

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

Читайте также:

  • Скорость загрузки сайта: как проверить и улучшить?
  • Бесплатные сервисы, позволяющие сделать аудит сайта онлайн

adblogger.ru

1. Google PageSpeed Insights

Инструмент Google PageSpeed Insights

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

2. Pingdom Tools

Проверка скорости с помощью сервиса Pingdom Tool

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

3. WhichLoadFaster

Which Load Faster - Сравнение двух сайтов по скорости

Загружаете два сайта для сравнения (себя и конкурента), визуально наблюдаете, кто загружается быстрее (удобно демонстрировать клиентам). В конце загрузки отображается информация, какой сайт выиграл и во сколько раз быстрее он загрузился.

4. Web Page Performance Test

Подробная статистика по Web Page Performance Test

Загружает страницу два раза, сравнивает количество обращений – выявляет, насколько хорошо организовано кеширование, показывает подробную статистику по каждому из тестов. Сохраняет скриншоты, как сайт выглядит на каждой секунде загрузки. Также в удобной форме демонстрирует, какая группа запросов заняла больше всего времени. Сервер находится в Далласе (США).

5. GTmetrix

GTmetrix - сводная статистика по скорости и история

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

6. Load Impact

Load Impact - легкий ДДОС для теста сайта

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

7. Monitis Tools

Monitis Tools - проверка скорости загрузки с разных участков Земли

Анализирует загрузку сайта с разных участков Земли — серверы в США, Европе и Азии. Отображает сводную статистику по каждому тесту.

8. SiteSpeed.me

SiteSpeed.me - с каких географических участков скорость наилучшая или наихудшая

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

9. PR-CY

PR CY - массовая проверка скорости загрузки сайтов

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

devaka.ru


You May Also Like

About the Author: admind

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

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

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.