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

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

Оптимальное время загрузки сайта

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

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

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

  • Большую конверсию;
  • Увеличение времени просмотра;
  • Увеличение чека и выручки в целом;
  • Улучшение ранжирования в поисковиках;
  • Меньшее количество отказов.

Все эти показатели имеют прямое влияние на прибыльность ресурса. Существует сервис (https://www.sharpedigital.com/seo/speed-conversion-rate-tool/), который показывает конверсию сайта относительно скорости загрузки.

Способы сокращения количества запросов к серверу

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

  • Определить по логам самых затратных по времени операций. Далее следует исправление и удаление лишних. Упрощение серверной логики.
  • Сократить базу данных. Удаление «мусора».
  • Включить Gzip сжатие на сервере для поточного архивирования текстовых данных.
  • Расширить кеш для CSS и JavaScript.
  • Объединение всех стилей JavaScript и CSS в один файл (точнее в два файла – каждый для своего формата).
  • Сократить порядок загрузки (стили CSS→ контент→JavaScript).
  • Уменьшить код JavaScript и CSS (удаление пробелов и комментариев).
  • Внедрение HTTP/2 для одновременной обработки большего количества запросов.
  • Подключение Lazyload (загрузка изображений только во время прокрутки до них).
  • Для того чтобы избежать двойной отрисовки отдельных частей элементов дизайна, необходимо перенести стили CSS с тела страницы в head.
  • Согласование МЕТА-тегов с HTTP-заголовками.
  • Внешне подключенные стили CSS и JavaScript необходимо перенести в общий файл стилей сайта. Это сократит общее количество запросов.
  • Смена абсолютных URL на относительные (название сайта.ru/page→/page)
  • Использование поддоменов для распределения части контента. Это позволяет сократить расстояние сервера и пользователя.
  • Уменьшить размер изображений (сжатие).
  • Связывание nginx и Apache. Это повышает скорость вычисления сервера.
  • Настройка OPcache.

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

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

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

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

<!—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. Ошибки в базе данных и данные долго считываются.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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