Сократите время ответа сервера – Время ответа сервера: как проверить, как сократить, что делать при появлении ошибки Долгий ответ сервера в Яндекс.Вебмастер?

Содержание

Сократите время ответа сервера - как решить проблему?

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

скидки 50%

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

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

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

Оптимизация скорости сайта на #WordPress. Сжатие стилей, скриптов, html

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

<!--noindex-->
 <center><?php
 print get_num_queries(). ' - столько SQL запросов к базе.<br />'.
 timer_stop(0, 6). ' - за столько сгенерировалась страница.';
 ?></center>
 <!--/noindex-->

Посмотрим, какое состояние сайта на данный момент:

26 — столько SQL запросов к базе.
1,205022 — за столько сгенерировалась страница.

Это главная страница сайта про линукс. Теперь проверю таким же образом главную страницу этого сайта:

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

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

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

1. Есть какой то кривой плагин, который тормозит генерацию страницы.

2. Кривой шаблон и какие то ошибки в верстке мешают нормальной работе.

3. На сайте есть вирус, который тормозит его работу. Как проверить на вирусы сайт читайте по ссылке…

4. Ошибки в базе данных и данные долго считываются.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сократите время ответа сервера wordpressСократите время ответа сервера 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 CollectorPlugins Garbage Collector

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

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

Все это мне очень помогло ускорить сайт, но все же Google Speed сигнализировал мне, что время отклика от сервера очень большое. И виноват в этом не сам сам сервер, так как простые html документы загружаются без всяких задержек, а движок сайта WordPress, который как не ускоряй ракетой не станет. Что же делать?

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

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

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

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

hyper-cachehyper-cache

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

pagespeed-insights-vremya-otklika-ot-serverapagespeed-insights-vremya-otklika-ot-servera

До 100/100 в Google Speed мне осталось совсем немного и уверен я достигну этого результата, так как почти все уже сделано, осталось совсем немного…


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

Не нашли ответ? Воспользуйтесь поиском по сайту

что это такое и почему это важно / RUVDS.com corporate blog / Habr

Сейчас я работаю над проектом для одного клиента. Речь идёт о сайте из сферы электронной коммерции, поэтому меня очень сильно интересуют некоторые аспекты производительности. Для начала это — различные показатели, характеризующие время загрузки сайта. Дальше — это время начала рендеринга страницы, которое важно для тех посетителей, которые хотят, после захода на сайт, увидеть его содержимое как можно быстрее (в эту категорию, естественно, попадают все посетители сайта). Есть среди интересующих меня показателей производительности и такие, которые отражают специфику деятельности моего клиента. Например: «Насколько быстро загружается основное изображение товара?». Анализ всех этих показателей способен дать ценные сведения о состоянии проекта.

Однако есть один показатель, которому, как кажется, фронтенд-разработчики часто не уделяют должного внимания. Речь идёт о времени до первого байта (Time to First Byte, TTFB). Это можно понять, можно и хотя бы отчасти простить разработчикам такое отношение к TTFB, особенно учитывая то, что они видят этот показатель как нечто, зависящее только от бэкенда проектов. Но если попытаться буквально в двух словах выразить проблему, касающуюся этого показателя, то можно сказать следующее: «Хотя хорошее значение TTFB не обязательно означает того, что демонстрирующий его сайт можно счесть быстрым, плохой показатель TTFB практически гарантированно указывает на проблемы с производительностью проекта».


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

Что такое TTFB?



Показатель TTFB выглядит не особенно информативным (изображение в полном размере)

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

Первое, на что мне хотелось бы обратить ваше внимание, это то, узнав о чём, люди обычно очень удивляются. Речь идёт о том, что в TTFB входит время, которое запрос от клиента идёт по сети к серверу, и время, которое занимает путь ответа сервера клиенту. Речь идёт о так называемом «времени приёма-передачи» (Round Trip Time, RTT). TTFB — это не просто некое время, потраченное сервером на подготовку ответа. Это ещё и время которое тратится в пути данными, идущими от клиента к серверу и от сервера к клиенту (в составе этих данных, понятно, и находится интересующий нас «первый байт»).

Теперь мы, вооружённые этим знанием, легко можем понять причину того, что при просмотре сайтов с мобильных устройств показатель TTFB часто оказывается просто неприлично большим. Вполне возможно, что раньше вы в подобных ситуациях задавались примерно таким вопросом: «Уверен, сервер не знает о том, что я смотрю сайт с мобильного. Как он тогда увеличивает TTFB?». Причина этого в том, что, как правило, мобильные сетевые соединения — это соединения с высокой задержкой. Если показатель RTT, отражающий время, необходимое данным для прохождение пути от телефона к серверу и обратно, составляет, например, 250 мс, то на соответствующее значение вырастет и TTFB.

Если бы мне хотелось, чтобы читатели этого материала вынесли бы из него лишь одну важнейшую идею, то я сформулировал бы эту идею так: «Сетевые задержки влияют на TTFB».

Что ещё влияет на TTFB? На самом деле — уйма всего. Вот далеко не полный список того, что вносит вклад в формирование этого показателя. Пункты этого списка расположены в произвольном порядке.

  • Сетевые задержки. Как уже было сказано, в TTFB входит время, которое занимает доставка запроса на сервер и возврат ответа от сервера. Возьмём, например, время, необходимое на сеанс обмена данными между устройством, находящимся в Лондоне, и сервером, находящимся в Нью-Йорке. В идеале, при использовании оптоволоконного соединения, это 28 мс. Но это — если исходить из множества весьма оптимистичных предположений. В реальности стоит ожидать чего-то наподобие 75 мс. Именно поэтому так важно использовать CDN. Даже сейчас, в век интернета, географическая близость некоего бизнеса и его клиентов — это преимущество.
  • Маршрутизация. Если вы используете CDN (а так и должно быть!), то запрос вашего клиента, скажем, из Лидса, может быть перенаправлен в дата-центр MAN только для того, чтобы в результате выяснилось, что нужный клиенту ресурс отсутствует в соответствующем PoP-кэше. Потом запрос будет перенаправлен к настоящему серверу с вашими материалами для того чтобы всё же передать клиенту то, что ему нужно. Если этот сервер находится, например, в Виргинии, то всё вышеописанное приведёт к серьёзному увеличению TTFB без видимых причин.
  • Работа с файлами. Даже если сервер просто читает из своей файловой системы статические данные, такие, как изображения или файлы стилей, на выполнение этой операции, всё равно, требуется некоторое время. Это время тоже входит в состав TTFB.
  • Приоритизация. Протокол HTTP/2 имеет механизмы приоритизации обработки запросов. В результате может оказаться так, что низкоприоритетные запросы могут быть задержаны на сервере, давая дорогу выполнению высокоприоритетных запросов. Если даже не принимать во внимание механизмы приоритизации HTTP/2 и предположить, что всё работает гладко, эти ожидаемые задержки способны внести вклад в TTFB.
  • Выполнение приложений. Это, на самом деле, вполне очевидно, но мне хотелось бы отметить, что время, необходимое на выполнение серверных приложений, серьёзно влияет на TTFB.
  • Запросы к базам данных. Если для формирования страницы нужно запросить что-то из базы данных — то время на выполнение подобной операции тоже войдёт в TTFB.
  • Вызовы API. Если для подготовки страницы нужны данные из неких API (внутренних или внешних), то обращения к этим API отразятся на TTFB.
  • Серверный рендеринг. Совершенно очевидно то, что серверный рендеринг требует времени, это время несложно оценить, но это не отменяет вклада данной операции в TTFB.
  • Дешёвый хостинг. Если вы используете дешёвый хостинг, стремясь как можно сильнее сэкономить и жертвуя производительностью, это обычно означает, что сервером, на котором расположен ваш проект, пользуется ещё некоторое количество других проектов. Возможно — немалое количество. В результате тот, кто пользуется дешёвым хостингом, может ожидать падения производительности сервера, что способно повлиять на возможности проекта по обработке запросов. Фактически, речь идёт о том, что мощности серверного «железа» недостаточно для удовлетворения нужд приложения.
  • DDoS-атаки, высокая нагрузка на проект. Тут мы продолжаем тему, затронутую в предыдущем пункте этого списка. А именно, если нагрузка на сервер растёт, а проект не предусматривает гибкого масштабирования серверных мощностей, это приводит к тому, что оборудование начинает работать на пределе возможностей. И, как результат, происходит падение производительности приложений.
  • WAF, балансировщики нагрузки. Сервисы, такие, как WAF или балансировщики нагрузки, расположенные перед серверным приложением, увеличивают TTFB.
  • Некоторые возможности CDN. Использование CDN — это фактор, безусловно, благотворно влияющий на TTFB, но некоторые возможности CDN могут ухудшить этот показатель. Например — это свёртывание запроса, ESI и т.п.
  • Задержки на «последней миле». Когда мы говорим о компьютере из Лондона, который обращается к серверу, находящемуся в Нью-Йорке, мы обычно чрезмерно упрощаем ситуацию, почти сводя всё к тому, что компьютер и сервер соединены друг с другом напрямую. Но в реальности всё устроено гораздо сложнее. Сигнал между компьютером и сервером идёт через множество посредников. Наш маршрутизатор шлёт его провайдеру; из беспроводной сети он попадает в кабель, проложенный по дну океана… Задержки на «последней миле» включают в себя все те сложности, которые встают на пути передачи данных между конечными устройствами.

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

Снятие покрова тайны с TTFB


Теперь, надеюсь, TTFB выглядит уже не таким уж и таинственным показателем. А если потратить немного времени на реализацию API Server Timing, то можно приступать к измерениям хитрых серверных временных показателей и к отправке их на клиентские системы. Это позволит веб-разработчикам обнаруживать и устранять потенциальные узкие места производительности, которые раньше были скрыты от их взоров.

API Server Timing позволяет разработчикам расширять ответы на запросы с помощью дополнительного HTTP-заголовка Server-Timing. Он содержит сведения о временных показателях, измеренные самим приложением.

Именно этим механизмом мы воспользовались в прошлом году при работе над BBC iPlayer.


Новый заголовок Server-Timing можно добавить к любому ответу (изображение в полном размере)

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


Теперь, прямо в браузере, можно видеть структуру TTFB (изображение в полном размере)

Если вы хотите реализовать у себя API Server Timing — взгляните на этот материал.

Итоги


Очень важно, чтобы веб-разработчики понимали бы масштабы влияния TTFB на всё то, что называют «производительностью сайтов». Время до первого байта — это некая граница, после пересечения которой можно говорить об оптимизации сайта. Чем ниже этот показатель — тем лучше.

Уважаемые читатели! Оптимизируете ли вы свои веб-проекты с учётом TTFB?


Уменьшение времени ответа сервера | WordPress.org Русский

Модератор Yui

(@fierevere)

ゆい

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

Радикально поможет — сменить хостинг на более быстрый

Но остальные сайты на других движках работают с временем ответа менее 200мс

Модератор Yui

(@fierevere)

ゆい

на том же хостинге?
возможно 200 мс для них тоже много.

хостинг vps или «обычный» ?
какая версия PHP, рекомендуется 7.0 или выше. Ускорит ответ в 2 раза.
Есть ли возможность использовать memcached или redis?

Хостинг best-hoster точка ру, а где смотреть версию php&

Модератор Yui

(@fierevere)

ゆい

https://ru.wordpress.org/plugins/health-check/

заодно продиагностируете на наличие других проблем

Модератор SeVlad

(@sevlad)

wp.me/3YHjQ

На моем сайте время ответа сервера 650мс

Что Вы вкладываете во «время ответа сервера» и кто Вам показал такие цифры? (если это правда «время ответа СЕРВЕРА», то причём тут ВП).

стоит всего 3 плагина: Yoast SEO, All In One WP Security и UpToLike Social Share Buttons.

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

Было бы проще Вам помогать, если бы Вы не скрывали адрес сайта.

Модератор Yui

(@fierevere)

ゆい

Было бы проще Вам помогать, если бы Вы не скрывали адрес сайта.


ну хочет он чтобы из него тянууули

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

Модератор SeVlad

(@sevlad)

wp.me/3YHjQ

Время ответа я смотрел в вебмастере.

А я думал в мониторе.
Ибо «вебмастер» — это проф. специальность человека.

Сайт не покажу

Ну тогда.. удачи.

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

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

Ох уж эти молодые сеошнеги. Одни ссылками спамят напропалую, другие наоборот — шифруются, когда не надо 🙂

O

(@perdyllo)

Сайт не покажу, т.к сами знаете как у молодых сайтов потом контент воруют

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

Так, что уважаемый, @coolfrodo, вы уж как-нибудь сами лечитесь.
А чтобы у вас ничего не украли — не надо ничего в интернет выкладывать. Тем более кое-как лепить сайты, которые все равно никто не увидит.

UpToLike Social Share Buttons.

Немедленно удаляйте! Не дай Бог кто ссылкой в соц.сетях на ваш сайт поделится! В момент ведь весь контент упрут!

  • Ответ изменён 1 год, 7 месяцев назад пользователем O.
  • Ответ изменён 1 год, 7 месяцев назад пользователем O.
  • Ответ изменён 1 год, 7 месяцев назад пользователем O.

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

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

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

Модератор Yui

(@fierevere)

ゆい

у молодых сайтов часто воруют контент

конечно воруют, отряд назгулов уже выехал для похищения контента
https://www.youtube.com/watch?v=31MHVbHA4TY

😉

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

конечно воруют, отряд назгулов уже выехал для похищения контента

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

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

O

(@perdyllo)

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

В связи с этим ТС следовало бы посоветовать удалить и Yoast SEO — не дай Бог с его помощью сайт засветился в поисковиках. 😁

А вот All In One WP Security это правильно! Только в нем надо не забыть включить «защиту от копирования» путем блокировки ПКМ. А чтобы совсем быть уверенным в защищенности контент от кражи — включить режим обслуживания 😁😁

А я думал в мониторе.
Ибо «вебмастер» — это проф. специальность человека.

Не знал что Яндекс это человек.

Ну прям обосрали с ног до головы! Жаль проблему это не решило.

Ответ «https://mybiznescentr.ru&#187; → Основной робот Яндекса
Код статуса HTTP 200 OK
Время ответа сервера 616 мс
IP сайта 91.219.194.9
Кодировка UTF-8(unicode-1-1-utf-8, UTF8)
Размер страницы 33,43 КБ
Date: Wed, 20 Jun 2018 05:19:56 GMT
Server: Apache
X-Powered-By: PHP/5.3.29

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

Кстати иногда задержка прыгает, замечал и 900мс и 1100

  • Ответ изменён 1 год, 7 месяцев назад пользователем coolfrodo.

Время ответа сервера: как проверить, как сократить, что делать при появлении ошибки Долгий ответ сервера в Яндекс.Вебмастер?

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

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

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

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

  • Максимальный приемлемый показатель – до 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. В ряде случаев сервер отвечает долго из-за нехватки ресурсов. В этом случае поможет приобретение новых ресурсов или переезд на более мощное оборудование.

Выводы

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

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

Уменьшение времени ответа сервера - page 2

Модератор Yui

(@fierevere)

ゆい

X-Powered-By: PHP/5.3.29

посмотрите выше что я написала по поводу версии PHP
поставьте 7 или 7.1, ускорите сайт только за счет этого почти в 2 раза

А как поставить версию PHP?

Модератор Yui

(@fierevere)

ゆい

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

https://ru.wordpress.org/support/upgrade-php/

Модератор SeVlad

(@sevlad)

wp.me/3YHjQ

ведь прав он — у молодых сайтов часто воруют контент.

1. Контент копипастят (а не воруют) у всех сайтов.
2. Ссылки на формах этому никак не способствуют. Тем более закрытые.
3. ..при этом закупаются беки. Беки с разных популярных ресурсов, на минутку 🙂
4. Злоумышленники узнают о «молодых сайтах» вовсе не с форумов поддержки. Они узнают о них даже до первого бека.

Не понимание «сеошнегами» пп 2-4 у меня лично вызывают приступ гомерического хохота.

Модератор SeVlad

(@sevlad)

wp.me/3YHjQ

Не знал что Яндекс это человек.

Яндекс — это компания.
А вебмастер — это человек, занимающийся разработкой веб-сайтов.

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

Ну прям обосрали с ног до головы! Жаль проблему это не решило.

Умение правильно выражать свои мысли, пользоваться правильными определениями-терминологией и давать нужные данные (а не огрызаться, когда дают знания) — залог успеха получения помощи.

Модератор SeVlad

(@sevlad)

wp.me/3YHjQ

Омайнгот.. ещё и license.txt и readme.html удалены.
И кодировка сервера кривая https://i.imgur.com/3posMzo.jpg (и роботс из ГСов скопипащен. Сеошнеги, такие нонешние сеошнеги 🙁 )

license.txt и readme.html этих файлов я не удалял, значит их не было. А что тогда в роботсе написать. И я как бы не сеошник, а просто человек который пробует себя в создании и продвижении сайта. Очень странно вы реагируете на вопросы. Я понимаю что вы шарите в этом, но тогда зачем этот форум тех. поддержки, если не для различных вопросов, да же если они глупые.

Модератор SeVlad

(@sevlad)

wp.me/3YHjQ

license.txt и readme.html этих файлов я не удалял, значит их не было.

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

тогда зачем этот форум тех. поддержки,

Для помощи с ВП.
А если Вы озабочены СЕО — Вам на СЕО-форумы.

O

(@perdyllo)

license.txt и readme.html этих файлов я не удалял

Доступ к ним может блокировать плагин безопасности All In One WP Security. Есть в нем такая опция.
@coolfrodo подобные плагины надо не только устанавливать и активировать, но надо ещё хорошо думать прежде чем включить в них ту или иную опцию. Столь же серьёзно надо относиться и к удалению таких плагинов.

А ведь в инструкции к плагину сказано что к его настройке надо относиться крайне осторожно. Или вообще не включать ту или иную опцию если не понимаете что делаете.

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

  • Ответ изменён 1 год, 7 месяцев назад пользователем O.

А нету нормального видео по настройке этого плагина. Я просто в ютубе нашел видео и по нему делал. Как теперь правильно восстановить эти файлы и настроить плагин?

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

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

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

O

(@perdyllo)

Я просто в ютубе нашел видео и по нему делал

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

https://www.yandex.ru/search/touch/?text=%D0%9A%D0%B0%D0%BA%20%D0%BD%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B8%D1%82%D1%8C%20%D0%BF%D0%BB%D0%B0%D0%B3%D0%B8%D0%BD%20%2C%20All%20In%20One%20WP%20Security%20&lr=117943&mda=0

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

  • Ответ изменён 1 год, 7 месяцев назад пользователем O.
  • Ответ изменён 1 год, 7 месяцев назад пользователем O.
Модератор SeVlad

(@sevlad)

wp.me/3YHjQ

он их не удаляет, насколько я помню — а просто скрывает.

не знаю как физически, а сервер отдаёт 404.

и вообще — скрытие этих файлов (как и удаление) — вполне нормальная практика.

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

не знаю как физически, а сервер отдаёт 404.

и что? https://www.wphook.ru/readme.html
тоже 404 ошибка, стандартный конфиг:


    	location  = /readme.html {
            # запрет доступа к readme.html
            deny all;
            return 404;
            access_log off;
            error_log off;
       }
    	location  = /license.txt {
            # запрет доступа к license.txt
            deny all;
            return 404;
            access_log off;
            error_log off;
       }

Плохая практика для новичков, обращающихся за помощью.

новичок и сам может сказать, какая у него версия wordpress.

Бесполезная практика и для всех остальных. Разве что успокаивает некоторых, думающих что это чем-то помогает 🙂

ваши категоричные утверждения как всегда далеки от истины.

Модератор SeVlad

(@sevlad)

wp.me/3YHjQ

и что?

Только то, что 404.

новичок и сам может сказать, какая у него версия wordpress.

Да причем тут версия? Не понимаете зачем важно иметь возможность (быстро и просто) проверить статику и др хар-ки и ответы сервера?

ваши категоричные утверждения как всегда далеки от истины.

Ваши заблуждения и предрассудки не имеют ничего общего ни с «истиной» ни с моей «категоричностью».

Оптимизация скорости загрузки сайта по Google PageSpeed Insights

Краткое содержание статьи:

PageSpeed Insights — инструмент от Google, анализирующий производительность страницы на мобильных и десктопных устройствах с предоставлением рекомендаций по их улучшению. Зачем его использовать? В лидирующих поисковых системах скорость сайта является важным критерием ранжирования. От того, насколько быстро произошла загрузка страницы, зависят не только трафик и позиции сайта, но и конверсия, глубина просмотров, лояльность пользователей и прочие важные параметры интернет-маркетинга.

Кратко об изменениях в работе инструмента

Раньше при оценке сайта Google основывался на своих метриках и правилах. Из недостатков: инструмент мог показывать оптимизированные страницы с быстрой загрузкой, но по факту страница могла грузиться долго, и при этом оценка отображаться высокой. Была и обратная ситуация: страницы загружались быстро, а оценка была низкой. 12 ноября 2018 года инструмент был обновлен. Формулы подсчета показателей полностью сменились, а также добавились новые.

С обновлением инструмент стал уделять больше внимания скорости страницы, где основной метрикой стала именно она. Благодаря этой оценке, инструмент может выделить самый быстрый и самый медленный сайт, и в зависимости от их показателей начислить соответствующие баллы вашему ресурсу. Начисление баллов осталось прежним – по шкале от 0 до 100, но их подсчет в корне изменился. Теперь оценка происходит с помощью Lighthouse. Lighthouse – это автоматизированный open-source инструмент с открытым исходным кодом для аудита сайтов. Этот же инструмент доступен в Google Chrome в качестве расширения.

Как пользоваться и что показывает PageSpeed Insights

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

Первое, что вы увидите — это оценка эффективности страницы. Она определяется с помощью Lighthouse, о котором мы писали выше. Эффективность загрузки страницы измеряется по шкале:

  • 90 или выше – быстрая;
  • от 50 до 89 – средняя;
  • ниже 49 – медленная.

Данные наблюдений и Origin Summary

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

На скриншоте мы можем видеть значения FCP и FID в процентах и секундах.

  • Первая отрисовка контента (FCP) – это время, спустя которое на экране отображается первый контент. Чтобы улучшить значение, необходимо работать над количеством внешних ресурсов CSS, JS; HTTP-кэшированием; размером текстов; загрузкой CSS, JS. FCP должен быть не выше 2500 мс.
  • Первая задержка ввода (FID) – это время, в котором происходит первое взаимодействие пользователя с вашим сайтом и отклик браузера на это взаимодействие. По сути, это время, в котором пользователю приходится ждать, пока браузер отреагирует на его взаимодействие (например, клик), и, если оно оказывается долгим, пользователя уходит с ресурса. FID не должен превышать 250 мс.

Имитация загрузки страницы

Имитация загрузки страницы оценивается по 6 показателям:

  • Время загрузки первого контента (FCP).
  • Индекс скорости загрузки – показывает, насколько быстро контент страницы отображается пользователю.
  • Время загрузки для взаимодействия (TTI) – время, в течение которого страница становится готова к взаимодействию с пользователем.
  • Время загрузки достаточной части контента (FMP) – время, по истечении которого становится виден основной контент страницы.
  • Время окончания работы ЦП (или первый простой процессора) – измеряет за какое время страница становится минимально готова к взаимодействию, причем поток страницы становится достаточно свободен для обработки ручного ввода.
  • Максимальная потенциальная задержка (FID).

«Оптимизация», «Диагностика» и «Успешные аудиты»

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

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

Раздел «Успешные аудиты» показывает параметры, которым соответствует ваша страница. Здесь остаётся только облегченно вздохнуть и порадоваться, что это дорабатывать не нужно.

Как избавиться от ошибок в PageSpeed Insights

Устраните ресурсы, блокирующие отображение

Здесь указываются все ссылки на ресурсы JS, CSS, HTML которые препятствуют загрузке контента страницы. Инструмент показывает какой размер у файла сейчас и размер, который будет после внедрения оптимизации.

Решить проблему можно следующими способами:

  • Ограничить объем ресурсов, которые отображаются в верхней части страницы, либо перенести их в футер сайта. Перенос подходит не для всех ресурсов, так как многие из них должны располагаться в пределах тега head.
  • Для JS рекомендуется указывать асинхронную загрузку. Либо другой вариант: синхронно загружать в head только те JS-ресурсы, которые могут требоваться для других скриптов, а остальные перенести в конец тега body.
  • Если добавить в ссылку подключения стилей значение preload атрибута rel и событие onload, то получится асинхронная загрузка стилей, пример:

    Это даёт возможность обработать CSS, не блокируя рендеринг. Как только ресурс загрузится благодаря onload, скрипт заменит значение preload атрибута rel на stylesheet и применит стили на странице.

  • Если есть стили, которые нужны только для подгружаемого контента, то их лучше загружать динамически с помощью скриптов стоящих в конце тега body.
  • Разбейте внешний CSS на несколько файлов по медиа типам и медиа запросам, тем самым избегая загрузки больших CSS-документов. Например, пометкой media="print" в теге link сообщите браузеру, что этот файл применялся только, если страница уходит в печать. Пример:
  • На первом экране должен загружаться только важный контент, поэтому нужно уменьшить размеры JS, CSS, HTML: перенести скрипты и стили в единые файлы; удалить ненужные скрипты и стили, загружать изображения через CSS, удалить лишние теги, комментарии и пр.

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

  • Для WordPress плагины Autoptimize, Speed Booster Pack, W3 Total Cache, JCH Optimize.
  • Для Joomla плагины JCH Optimize.
  • Для Drupal плагины JCH Optimize.
  • В Bitrix это реализуется в админке в разделах: Настройки > Настройки продукта > Настройки модулей > Главный модуль «Оптимизация CSS».
  • Opencart плагины Simple Minify, SourceCode Compressor, MCJ.

Также можно воспользоваться онлайн-инструментами для сжатия (минификаторами) JS и CSS: websiteplanet.com «JS & CSS Minifier», csscompressor.com.

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

В этом разделе инструмент рекомендует использовать форматы изображений JPEG 2000, JPEG XR и WebP, которые превосходят JPEG и PNG в характеристиках сжатия и сохранения качества.

Но есть недостаток у данных форматов – это проблемы с поддержкой версий в популярных браузерах. В России популярными браузерами являются Google Chrome, Яндекс.Браузер, Safari, Opera и Firefox. Например: WebP не поддерживается Safari, JPEG 2000 не поддерживается Google Chrome, Firefox и Opera, а JPEG XR вообще никаким из перечисленных браузеров.

WebP

JPEG 2000

JPEG XR

Исходя из приведенных таблиц наиболее лучшим оказывается формат WebP (но всё еще не универсальным), который можно получить следующим образом:

  • Онлайн-конвертеры: convertio.co, image.online-convert.com, ru.inettools.net и пр.
  • Плагин AdobeWebM для Adobe Photoshop CC.
  • Плагины для CMS:
    1. для WordPress плагин WebP Express.
    2. для Bitirx для поддержки WebP проще доработать код. Также в Bitrix Marketplace к приобретению доступны решения «Ускорение загрузки сайта - оптимизация css, js и картинок» и Ammina Optimizer.
    3. Для Joomla ранее был доступен плагин WebP Joomla Yireo, но был удалён, может быть вам удастся его найти на просторах интернета.
    4. Для Opencart есть платное дополнение «Image COMPRESSOR & Watermark & WebP & Lazy Load etc. by Sitecreator».
    5. Для Drupal модули «WebP By Bart Vanhoutte», «ImageAPI Optimize WebP».

Настройте эффективную кодировку изображений

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

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

  • PNG — изображения более высокого качества, но имеющие больший размер файла. Был создан как формат изображения без потерь качества.
  • JPEG — использует оптимизацию с потерями и без потерь. Есть возможность регулировки уровня качества и размера файла в балансе.
  • GIF — использует только 256 цветов. Используется только сжатие без потерь. Считается, что GIF – лучший вариант для анимированных изображений, но у Google на этот счет другое мнение, см. раздел «Используйте видеоформаты для анимированного контента».

Оптимизация изображений может происходить следующим образом:

  • Вручную с помощью Adobe Photoshop и с использованием экшенов.
  • Пакетное преобразование с помощью FastStone Image Viewer.
  • Онлайн-сервисов: tinypng.com, kraken.io, compressor.io, imagecompressor.com.
  • С помощью доработки кода, например в Bitrix.
  • С помощью плагинов:
    1. для WordPress плагины Robin image optimizer; EWWW Image optimizer, WP smush.
    2. Для Bitrix решения Image Optimizer, «Оптимизация картинок – автоматически и без сторонних сервисов».
    3. Для Joomla плагины JCH Oprimize, Imgen, Image Recycle.
    4. Для Drupal плагины JCH Optimize, ImageMagick, Image Optimize (or ImageAPI Optimize).
    5. Opencart модуль Image Optimizer, дополнение «Сжатие изображений для OpenCart 2.x».

Удалите неиспользуемый код CSS

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

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

Сократите время ответа сервера (время до получения первого байта)

Если страницы сайта медленно грузятся, стоит обратить внимание на отклик времени сервера. Google Page Speed недоволен этим показателем, если он более 600 мс, в идеале это должно быть 200 мс и меньше. Для дополнительной оценки можно использовать онлайн-инструмент Pingdom.

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

  • Тяжелые плагины или их большое количество могут влиять на загрузку сервера – отключите те, которые не используются.
  • Перейдите на новую версию PHP – PHP 7 (предварительно проверьте, что ваш хостинг его поддерживает).
  • Оптимизируйте таблицы базы данных MySQL.
  • Если используете старую версию CMS, лучше обновите её до последней версии.
  • Включите кеширование сайта браузером.
  • Оптимизируйте код, например, с помощью инструмента gtmetrix.com.
  • Установите веб-сервер nginx и настройте его работу с Apache таким образом, чтобы страницы отдавали браузеру пользователя Apache, а статический контент – nginx. Либо полностью замените Apache на nginx.
  • Используйте GZIP-сжатие, которое позволяет на стороне сервера архивировать файлы, а распаковывать уже в вашем браузере.
  • Выполните рекомендации из разделов Google PageSpeed Insights, описанных выше.

Дополнительные варианты плагинов для популярных CMS, которые помогут в сокращении ответа сервера:

  1. Для WordPress плагины WP Super Cache, PHP Speedy WP, Optimize DB.
  2. Для Bitrix предлагаем варианты, в которых можно ознакомиться, как ускорить сайт.
  3. Для Joomla уже упоминаемый плагин JCH Optimize, а также включение кеширования в админ-панели.
  4. Для Drupal модули «Authenticated User Page Caching (Authcache)», «CSS GZIP», «JavaScript Aggregator», «eAccelerator».
  5. Для Opencart модули Smart Optimizer, Turbo OpenCart.

Уменьшите размер кода JavaScript

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

Настройте показ всего текста во время загрузки веб-шрифтов

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

Пример:

Далее в стилях к основному шрифту необходимо подключить дополнительный шрифт в font-family. Например:

Если же вы отдаёте предпочтение локальным шрифтам, то в @font-face добавьте свойство «font-display: swap;»:

Минимизируйте работу в основном потоке

В этом разделе подразумевается оптимизация кода JS: удалите неиспользуемый JS, первым загружайте только необходимый, сожмите данные JS. Более подробно смотрите в разделе «Устраните ресурсы, блокирующие отображение».

Сократите размер структуры DOM

DOM (от англ. Document Object Model – «объектная модель документа») может нанести ущерб производительности страницы, если оно имеет большое дерево. Дерево DOM состоит из объектов, которые называются узлами, например это элементы HTML, текстовое содержимое, закомментированный код и пр. Оптимальное количество узлов в DOM 1500, глубина – 32 узла, количество дочерних и родительских элементов – менее 60.

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

Задайте правила эффективного использования кеша для статических объектов

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

Сократите время выполнения кода JavaScript

Здесь снова говорится об улучшении кода JS – необходимо уменьшить размер фрагментов кода JS: использовать только тот, который нужен для правильной работы сайта; сократить, сжать данные кода и кешировать. Более подробно о том, что может помочь смотрите в разделе «Устраните ресурсы, блокирующие отображение».

Сократите глубину вложенности критических запросов

В этом разделе говорится о цепочке критических запросов, которые позволяют браузеру загружать страницу как можно быстрее, с определением приоритетов загружаемых ресурсов и порядком их загрузки. Например, браузер обрабатывает HTML, к нему подключены CSS ресурсы, он начинает обрабатывать их, а далее обнаруживается, что к HTML подключены и шрифты, для обработки которых ему снова нужно отправить запросы. Решить проблему можно добавлением в тег link значение rel=preload. Более подробно смотрите выше, в разделе «Устраните ресурсы, блокирующие отображение».

Настройте подходящий размер изображений

Помимо рекомендации сжатия всех изображения без потери качества, есть еще несколько вариантов исправления данной ошибки в PageSpeed Insights:

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

Время ответа сервера для сайтов на Joomla

Что такое время ответа сервера?

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

Google Page Speed Insights

Согласно документации Google Page Speed:

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

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

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

Согласно документации Google Page Speed:

Время ответа сервера не должно превышать 200 мс.

Если значение фактора составляет более 200 мс, то в результатах проверки содержится рекомендация Сократите время ответа сервера:

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

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

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

Важно знать:

Первый фактор, влияющий на время ответа сервера — это мощность сервера. Чем выше мощность, тем быстрее сервер обрабатывает запросы и отправляет запрашиваемые страницы (ответы).

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

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

Кэширование ресурсов в браузере

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

Конфигурация сервера

Подразумеваеются версии PHP, MySQL и самого сервера: чем выше версия ПО, тем выше производительность.

Актуальные версии Joomla 3.x созданы под PHP 7, и скорость загрузки сайтов на Joomla 3, работающих на PHP 5.x, будет ниже.

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

Кэширование динамических страниц на сервере

Динамические страницы обрабатываются сервером медленнее из-за выполнения PHP-скриптов и обращений к базе данных, в результате чего формируется HTML-страница. Как следствие, при увеличении числа запросов к сайту в единицу времени нагрузка на сервер значительно возрастает. Именно так работают сайты на Joomla и любых других CMS.

Важно знать:

Значительно сократить время ответа сервера для Joomla позволит активация серверного кэширования веб-страниц целиком или частично, что сделает их относительно статическими HTML-страницами, для создания которых не требуется обращаться к базе данных.

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

Перераспределение ресурсов

Сбалансировать нагрузку на сервер можно с помощью перераспределения ресурсов веб-страниц:

  • видео и аудио

    Рекомендуется не размещать эти файлы на своём сервере, а использовать специализированные сервисы: YouTube, Vimeo, SoundCloud.

  • комментарии

    При большом количестве комментариев также рекомендуется использовать соответствующие сервисы: Disqus, IntenseDebate, cackle.me.

  • изображения и JS-файлы

    Эти ресурсы по возможности лучше размещать на CDN.

Смена хостинга или хостера

Если перечисленные выше методы не помогут, то спасёт лишь смена сервера: тарифа или хостинг-провайдера. В этом случае имейте ввиду:

  1. Виртуальный хостинг — самый нестабильный тариф, т. к. на сервере кроме вашего сайта размещается еще много других сайтов, которые могут значительно замедлять работу сервера.
  2. При выборе хостера обращайте внимание на характеристики серверов и up-time (процент времени бесперебойной работы).
  3. Самым оптимальным вариантом в соотношении цена/качество является виртуальный выделенный сервер (VPS): время ответа сервера не будет зависеть от других сайтов, т. к. на сервере будет размещен только ваш сайт.
    Кстати, у вас есть возможность воспользоваться бесплатным VPS на месяц, подробности здесь.
  4. Если вы решитесь арендовать выделенный сервер (не VPS), то имейте ввиду, что его необходимо настраивать (VPS не надо настраивать).

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

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