Одной из самых популярных тем для обсуждения в сообществе WordPress является ускорение работы WordPress и оптимизация веб-страниц. Я не думаю, что есть блог WordPress без статьи «X Tips для ускорения WordPress». Не поймите меня неправильно, это хорошо. Но нам нужны лучшие статьи на эту тему вместо скучных обзоров плагинов.
Это может выглядеть как еще один «совет по ускорению WordPress», но в этой серии из трех частей мы рассмотрим все аспекты оптимизации и ускорения вашего WordPress-сайта.
Давайте начнем с самой популярной и, вероятно, самой простой вещи: кэширования.
Кеширование в WordPress
Я думаю, можно с уверенностью сказать, что это самая популярная тема, когда речь идет об ускорении WordPress. Конечно, это связано с популярными и простыми в использовании плагинами для кэширования WordPress, но это также один из фундаментальных методов снижения нагрузки на базу данных и ускорения работы сайтов WordPress.
Мы собираемся вернуться к плагинам кэширования, но давайте рассмотрим два типа кэширования: кэширование на стороне сервера и кэширование на стороне клиента.
Кэширование на стороне клиента
Кэширование на стороне клиента — это тип кэширования, которое делают браузеры ваших посетителей. Это означает, что когда посетители приходят на ваш сайт, их браузеры будут хранить данные определенных частей ваших страниц. Хотя браузеры автоматически кэшируют некоторые данные (например, кэшируют файлы JavaScript и CSS), мы можем выполнить некоторую настройку с помощью файлов .htaccess
.
Под точной настройкой файла .htaccess
я имею в виду добавление в него заголовка «Expires». Возможно, вы слышали термин «использование кэширования в браузере», потому что он обычно используется в руководствах по «оптимизации веб-сайтов» и является критерием высокого приоритета в службе Google PageSpeed.
К счастью, нам не нужно самим придумывать эти заголовки — в Интернете достаточно кода, который можно «позаимствовать». Мне нравится тот, что в HTML5 Boilerplate , где заголовки разделены по категориям типов файлов:
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
|
# ——————————————————————————
# |
# ——————————————————————————
# Serve resources with far-future expires headers.
# IMPORTANT: If you don’t control versioning with filename-based cache
# busting, consider lowering the cache times to something like one week.
<IfModule mod_expires.c>
ExpiresActive on
ExpiresDefault «access plus 1 month»
# CSS
ExpiresByType text/css «access plus 1 year»
# Data interchange
ExpiresByType application/json «access plus 0 seconds»
ExpiresByType application/ld+json «access plus 0 seconds»
ExpiresByType application/vnd.geo+json «access plus 0 seconds»
ExpiresByType application/xml «access plus 0 seconds»
ExpiresByType text/xml «access plus 0 seconds»
# Favicon (cannot be renamed!) and cursor images
ExpiresByType image/x-icon «access plus 1 week»
# HTML components (HTCs)
ExpiresByType text/x-component «access plus 1 month»
# HTML
ExpiresByType text/html «access plus 0 seconds»
# JavaScript
ExpiresByType application/javascript «access plus 1 year»
# Manifest files
ExpiresByType application/manifest+json «access plus 1 year»
ExpiresByType application/x-web-app-manifest+json «access plus 0 seconds»
ExpiresByType text/cache-manifest «access plus 0 seconds»
# Media
ExpiresByType audio/ogg «access plus 1 month»
ExpiresByType image/gif «access plus 1 month»
ExpiresByType image/jpeg «access plus 1 month»
ExpiresByType image/png «access plus 1 month»
ExpiresByType video/mp4 «access plus 1 month»
ExpiresByType video/ogg «access plus 1 month»
ExpiresByType video/webm «access plus 1 month»
# Web feeds
ExpiresByType application/atom+xml «access plus 1 hour»
ExpiresByType application/rss+xml «access plus 1 hour»
# Web fonts
ExpiresByType application/font-woff «access plus 1 month»
ExpiresByType application/font-woff2 «access plus 1 month»
ExpiresByType application/vnd.ms-fontobject «access plus 1 month»
ExpiresByType application/x-font-ttf «access plus 1 month»
ExpiresByType font/opentype «access plus 1 month»
ExpiresByType image/svg+xml «access plus 1 month»
</IfModule>
|
Поместите эти строки кода в свой файл .htaccess
и все готово!
Кэширование на стороне сервера
Когда речь заходит о кэшировании на стороне сервера в WordPress, мы можем говорить о четырех основных видах кэширования: кэширование страниц, кэширование базы данных, кэширование объектов и кэширование кода операции (кода операции). Сурав Кунду объясняет это в своей статье в WP Explorer , но давайте подведем итоги:
- Кэширование страниц. По сути, WordPress выводит ваши страницы, запрашивая базы данных и загружая результаты. Кэширование страниц, однако, сохраняет каждую страницу в виде файлов HTML в локальном хранилище сервера (на жестком диске или в оперативной памяти) и предоставляет файлы HTML, соответствующие вашим страницам, каждый раз, когда посетители посещают ваш сайт.
- Кэширование базы данных: хотя базы данных являются «мозгом» веб-сайта WordPress, на котором хранятся все данные, это не очень эффективно, когда WordPress снова и снова делает один и тот же неизменяющий запрос на каждой странице и для каждого посетителя. Кэширование базы данных сохраняет и обслуживает результаты этих запросов и обновляет результаты при изменении запроса.
- Кеширование объектов: это внутренний API WordPress, который позволяет плагинам хранить данные дорогостоящих запросов в памяти. Это немного неуместно для нашей серии — возможно, мы рассмотрим это в отдельном руководстве в будущем.
- Кэширование кода операции: так же, как вы добавляете муку, воду, яйца, сахар и еще много чего каждый раз, когда выпекаете торт, коды в ваших файлах PHP являются инструкциями для «компиляции» и выполнения ваших запросов. Кэширование кода операции — это вид кэширования, в котором хранится скомпилированный код, что значительно ускоряет процесс.
Плагины WordPress для кеширования
Наши главные главы посвящены аспектам ускорения WordPress, поэтому обзор плагинов может быть не по теме. Тем не менее, это хорошая идея, чтобы поговорить о паре плагинов в каждой главе. Что касается кеширования, я знаю, что вы уже знаете два самых популярных плагина:
- WP Super Cache : это самый популярный кеширующий плагин для WordPress, более 6 миллионов загрузок и рейтинг 4,2 звезды на момент написания этой статьи. Проще говоря, WP Super Cache генерирует статические HTML-файлы ваших страниц и обновляет их с заданным интервалом (по умолчанию один час). Это работает как по волшебству из коробки даже на общих хостах, но может быть недостаточно для сайтов с большим трафиком.
- W3 Total Cache . Являясь вторым по популярности плагином с почти 4 миллионами загрузок и рейтингом 4,5 звезды, W3 Total Cache является тем плагином, который больше подходит для веб-сайтов с высоким трафиком, работающих на VPS или в более качественной среде размещения. Благодаря широкому диапазону настроек и поддержке высокопроизводительных параметров кэширования, это может быть лучшим решением для вас, если вы знаете, что делаете. Однако, если вы не знакомы с жаргоном в настройках, вы можете использовать его «из коробки» и не изменять никакие параметры, иначе вы можете сломать свой интерфейс.
Оптимизация базы данных в WordPress
Базы данных являются «мозгом» вашего сайта: они хранят ценные данные, которые вы показываете на своих страницах. Статические HTML-сайты хранят свои данные внутри страниц, но системы управления контентом должны полагаться на базы данных (SQL, NoSQL, XML, JSON и т. Д.) Для хранения наших данных. WordPress ничем не отличается — он использует MySQL для хранения статического и динамического контента вместе с информацией о вашем сайте, настройками WordPress, пользовательскими данными и так далее.
Базы данных являются мощным стандартом для хранения, обслуживания и изменения ваших данных, но если вы используете их неправильно и не будете их обслуживать, они могут стать толстыми и раздутыми. Как и любое другое программное обеспечение, WordPress также нуждается в обслуживании. WordPress не создает слишком большой объем данных в базе данных, но это не значит, что он не замедлит работу вашего сайта.
Вам нужно следить за ревизиями ваших сообщений, мусором сообщений, страницами, комментариями и т. Д., А также любыми другими «устаревшими» данными. И время от времени вы должны проверять «накладные расходы» базы данных, которые часто сравнивают с дефрагментацией жесткого диска или заменой масла в вашем автомобиле.
Все это можно сохранить вручную: вы можете очистить корзину, отключить функцию «редакции», удалить спам-комментарии и оптимизировать накладные расходы базы данных, войдя в phpMyAdmin, но это не оптимизированный метод оптимизации базы данных. Вместо этого вы можете использовать плагин WordPress, чтобы сделать всю работу.
Существует более нескольких плагинов, которые позволяют оптимизировать базу данных одним щелчком мыши или даже автоматически. Больше всего мне нравится WP-Optimize : он автоматически очищает и оптимизирует вашу базу данных без каких-либо хлопот.
WP-Optimize перечисляет свои основные функции следующим образом:
- Удаление устаревших почтовых ревизий
- Удаление устаревших неутвержденных и спам-комментариев
- Удаление ненужных комментариев
- Удаление метаданных Akismet из комментариев
- Удаление других устаревших метаданных из комментариев
- Подходит для мобильных устройств, теперь вы можете оптимизировать свой сайт на ходу
- Удаление всех трекбеков и пингбеков
- Очистка авто черновиков
- Удаление переходных параметров
- Очистить почтовый мусор
- Автоматическая очистка всех встроенных параметров (также используется сохранение, если включено)
- Возможность сохранять данные выбранного количества недель при очистке
- Возможность добавить или удалить ссылку на панели администратора WP.
- Включить / отключить еженедельные графики оптимизации
- Примените собственные команды оптимизации WordPress MySql к таблицам базы данных без phpMyAdmin или каких-либо ручных запросов.
- Показать статистику таблицы базы данных. Показывает, сколько места можно оптимизировать и сколько места было очищено.
- Включено только для администраторов.
Обязательно ознакомьтесь с другими плагинами оптимизации базы данных , но не пренебрегайте обслуживанием вашей базы данных.
На части 2
В следующей части серии мы рассмотрим аспекты сжатия и минимизации, а также использование CDN для ускорения работы вашего сайта WordPress.
Что вы думаете об ускорении WordPress? Поделитесь своими мыслями ниже в разделе комментариев. И если вам понравилась статья, не забудьте поделиться ею.