Основной полезный ресурс PageSpeed Insights от Гугль для проверки скорости загрузки сайта.
https://developers.google.com/speed/pagespeed/insights/
В результате мы видим оценку (отдельно для мобильных устройств и для десктопа) и рекомендации по оптимизации. На картинке ниже – для desctop – в целом неплохо.
Ответ от базы данных MySql
Самое узкое место в работе CMS. База данных – это таблицы с данными, фактически файлы, которые хранятся на сервере.
Читаем статью
Серверу нужно выбрать правильные записи, собрать страницу и отдать её браузеру для показа клиенту.
И чем база быстрее отвечает – тем быстрее клиент получит страницу. Но база рано или поздно разрастается, в ней добавляется мусор. И запросы обрабатываются медленнее.
Читаем статью
Загрузка внешних ресурсов
Проверяем в первую очередь. Ваш сайт может работать идеально – но может ждать результатов загрузки с других ресурсов.
Это может быть:
- загрузка шрифтов Google (встроено в WordPress) – желательно отключить
- картинки с других сайтов – такого надо избегать
- внешние джаваскрипты и таблицы стилей
На самом деле – самая опасная тема для продвижения сайта. Например, были случаи, когда шрифт от Гугль грузился более 1 сек. Какие-то технические проблемы либо у Гугль, либо на канале интернета, либо опять кто-то чего-то заблокировал.
Тут же все вебмастеры выкинули предупреждение, что сайт грузится более 3 сек. А это уже чревато понижением в выдаче с поиска (и потом потребуется время для восстановления). Поэтому лучше загрузку всех внешних ресурсов отключать.
В идеале должно остаться только два внешних скрипта:
- счетчик Яндекс
- счетчик Google
Вот они.
Проверьте только, что бы сам код счетчика был последней версии. Современные версии асинхронные и на скорость загрузки сайта практически не влияют.
По этой же причине сейчас и Яндекс и Гугль предлагают устанавливать счетчики в header, а не в конец страницы.
Замедляют ли плагины работу сайта?
Довольно популярная тема для обсуждения на форумах. В целом плагины написаны на PHP и выполняются сервером (до того, как отдать результат браузеру и пользователю).
Т.е. как бы на работу плагинов затрачивается процессорное время на сервере, но в реальности оно ничтожно мало по сравнению с работой самого ядра WordPress. К тому нам нужно получить функциональный сайт, а не экономить процессорное время (можно взять тариф подороже на хостинге).
Можно ставить большое количество плагинов себе для украшения сайта и будет только польза? Вреда не будет?
Не всё так просто :(
а) Первая больная причина – плагины пишут живые люди и они могут ошибаться. Но ядро WordPress может даже работать с плагином, в котором есть ошибки PHP. Вот конечно время на обработку сильно добавляется.
Есть хороший плагин для разработчиков Query Monitor
Устанавливаем, смотрим на раздел “ошибки PHP” (и другие разделы), принимаем меры.
Из личного опыта – в плагине была ошибка, при вызове хука функция была без кавычек = но всё работало. Да, плагин Query Monitor ругался на неопределенную переменную (в двух местах – в самом плагине и в системном файле, который отвечает за подключение плагинов). Но ядро WordPress все-таки “понимало”, что это указана функция, а не переменная – и плагин работал. Но время, время…. терялось сильно.
б) Вторая больная причина – плагины, они сложные, там у многих есть джаваскрипты и форматирование вывода (т.е. файл CSS). Итого сам сайт не замедляется, но с каждым таким установленным плагином скорость загрузки сайта замедляется на целых 0,2 секунды!
- 100 мс (в среднем) – на загрузку js
- 100 мс (в среднем) – на загрузку таблицы CSS
Вот например плагин popup для обратной связи
При загрузке сайта, будьте добры, потратить 180 ms (таблица стилей CSS и java script)
Итого 5 установленных плагинов = минус 1 секунда при загрузке сайта….
Для мониторинга временных затрат на использование плагинов устанавливаем P3 (Plugin Performance Profiler) и анализируем результат.
Смотрим за период использования (день, неделя и пр.) – анализируем “затраты” сервера PHP на работу активных плагинов.
Да – установленные и неактивные плагины только занимают место на сервере, на работе сайта это никак не сказывается.
Загрузка картинок
Вот отчет из сервиса PageSpeed Insights Гугль по скорости загрузки картинок.
В целом ничего не понятно, кроме предложений оптимизировать изображения.
На самом деле WordPress очень хорошо оптимизирован для показа картинок. Ключевые слова – “набор изображений srcset”. Т.е. WordPress “умеет” под разные устройства отдавать изображения разных размеров (точнее умеет браузер и html5 – но движок WP всё правильно готовит). Нужно только соблюдать правила “гигиены”
- не использовать картинки с чужих ресурсов (ибо время)
- не использовать формат PNG (нужна Вам прозрачность в обмен на большой размер файла?), а использовать JPG (ибо есть сжатие jpg)
- не вставлять изображение через тэги html, а использовать медиабиблиотеку WordPress (и тогда будет работать scrset)
- не забывать устанавливать у каждой записи / страницы изображение страницы featured image
В двух словах – не надо вставлять в статью картинку PNG вручную через тэги HTML и не надо использовать в качестве миниатюры первую полноразмерную картинку. Используйте медиабиблиотеку WordPress (даже Гугль это пишет) – и будет Вам счастье.
Читаем статьи (и тогда плагины дополнительной навигации не будут брать первую полноразмерную картинку для анонса)
Как добавить картинки на сайт CMS WordPress
Миниатюры (thumbnails) записей и страниц WordPress
Используем плагин для контроля за миниатюрами
Плагин добавления колонки featured image в административной панели
Читаем, почему нельзя использовать внешние картинки для миниатюр
Загрузка скриптов и таблиц CSS
Посмотрим на загрузку таблиц стилей и скриптов
Таблицы стилей:
- 11 файлов
- максимально 1120 мс = 1,1 сек
Загрузка java script
- 9 файлов
- 790 мс = 0,8 сек
Общее время загрузки = 1910 мс или 1,9 сек
Что с этим можно сделать? Это “дорогие” файловые операции на сервере, попробуем оптимизировать загрузку.
Есть такой плагин для оптимизации Clearfy
Заходим в раздел “Производительность”
Выбираем вариант “оптимизировать” и проверяем результат. В загрузке появились файлы вида
…css/wmac_single_0e55521….css
…js/wmac_single_5001783….js
Это оптимизированные файлы, которые создал плагин в своей папке кэша /wp-content/cache/wmac/ Общее время загрузки уменьшилось до 1750 мс, немного выиграли.
Плагин еще предлагает объединить файлы – но тут необходимо вручную проверять результат внешнего вида сайта.
Резюме
Можно заметить, что в настоящее время ни скорость канала интернета, ни скорость работы сервера не оказывают существенного влияние на скорость загрузки сайта. Зато как много мелких дисковых операций:
- загрузка изображений
- загрузка таблиц стилей CSS
- загрузка java script
- загрузка самой страницы html (готовой из кэша) или загрузка файлов PHP для обработки сервером
- еще чтение из базы MySQL
Можно и нужно пойти другим путем – на хостинге поменять тариф, что бы там был SSD. В отличии от HDD – твердотельный накопитель хорошо работает с большим количеством мелких файлов.
Подпишитесь в VKontakte - нажмите кнопку | ||
Подпишитесь в Telegram - нажмите кнопку | ||
Наша группа ODNOKLASSNIKI |
Вы можете сохранить ссылку на эту страницу себе на компьютер в виде htm файла
Пишите на электронную почту (тема и email будут добавлены автоматически в письмо)
В Вашем браузере должна быть настроена обработка ссылок mailto
site_post@bk.ru
или просто скопируйте адрес e-mail
Почитать в разделе
WordPress

(Читать полностью...)
- Всего статей в разделе: 11
- Показано статей в списке: 10
- Сортировка: название по алфавиту
“Мусорные” страницы

(Читать полностью...)
WP Cron – планировщик задач

(Читать полностью...)
Базовые настройки темы Graphene

(Читать полностью...)
Базовые темы WordPress

(Читать полностью...)
Выбор темы для сайта на WordPress

(Читать полностью...)
Дочерняя тема WordPress

(Читать полностью...)
Кэширование WordPress

(Читать полностью...)
Подготовка блога WP к работе нескольких авторов

(Читать полностью...)
Чистим базу данных WP

(Читать полностью...)
Что хранится в файле wp-config.php

(Читать полностью...)