Как уменьшить время загрузки страницы сайта оптимизация на примере проекта Superbalist

Содержание материала:

Как ускорить сайт на WordPress в 17 раз. Пошаговая инструкция

Представляю наиболее полную инструкцию с способами по ускорению работы сайта на WordPress. Благодаря описанным ниже способам я ускорил загрузку своего сайта с 24,40 секунд до 1,41 секунды. Увеличил скорость загрузки в 17,3 раза! Хороший результат. Чтобы узнать как — читайте полную статью.

Замеры скорости работы сайта я проводил сервисом Pingdom Speed Test. Тестировал главную страницу сайта. Смотрите ниже показатели сайта «до» и «после» улучшений, и короткую и полную инструкцию по ускорению сайта.

Показатели сокрости загрузки сайта

Перед оптимизацией После оптимизации
Время загрузки 24.4 секунды 1.41 секунды
Количество запросов 94 запроса 76 запросов
Размер страницы 3.5 Мб 1.6 Мб

Скриншот замера скорости ПЕРЕД оптимизацией блога:

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

Короткое резюме по ускорению сайта на WordPress

Основное влияние на скорость оказали такие факторы как смена хостинга с использованием SSD дисков, оптимизация изображений, включение плагина кеширования W3 Total Cache, оптимизация БД сайта, удаление старых ревизий, включение сжатия файлов на стороне сервера, включение кеша для статичных файлов на стороне браузера. Далее следует полная развернутая инструкция по ускорению сайта на WordPress.

Полная инструкция как ускорить сайт на WordPress

1. Качественный SSD хостинг, быстрый пинг

Хостинг должен быть на SSD дисках. Желательно чтобы сервера хостинга располагались в вашей географической зоне, на которую ориентирован сайт. Если хостинг будет на SSD, но в США, а ваш блог ориентирован на Россию и страны СНГ, то толку от такого SSD будет мало. Так как будет идти долгий пинг для связи с сервером. Поэтому месторасположение дата центра хостинга также важно. Это важный параметр хостинга — быстрый пинг, отклик серверов. И чтобы хостер не делал оверселлинг услуг. Про тип хостинга — конечно лучше брать как VDS (виртуальный выделенный сервер) с необходимыми для вашего сайта параметрами, вместо обычного shared хостинга. Какую именно конфигурацию VDS выбрать — это зависит от нагрузки которую ваш сайт создает не сервер и от размера его суточной аудитории. Я бы советовал брать минимум 1Gb Ram, 1 ядро процессора и 10 Гб SSD. В начале у меня был VDS на обычных HDD дисках, затем я поменял его на SSD VDS хостинг.

Хостинг «До»:

VPS хостинг FreeHost.com.ua
Размер диска: 30 Gb HDD
Память: 2 Gb RAM
Частота CPU: 2,2 Ghz
Количество CPU: 1
Расположение серверов: Киев, Украина
Стоимость: 12,8 $/месяц

Хостинг «После»:

VDS хостинг от ihor.ru
Размер диска: 20 Gb HDD
Память: 1 Gb RAM
Частота CPU: 2,4 Ghz
Количество CPU: 1
Расположение серверов: Москва, Россия
Стоимость: 250 руб/месяц (примерно 5$/месяц)

По скриншотам теста скорости загрузки сайта, видно что на старом хостинге время ответа сайта достигало 12,3 секунды. Что непомерно много. На новом хостинге от ihor.ru время ответа сайта составляло 1,2 секунды, что в разы быстрее, по сравнению со старым хостингом. На этот показатель повлияли SSD диски, и более лучший дата центр с лучшим и более быстрым каналом.

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

2. Оптимизировать изображения

Проверьте используете ли вы оптимизированные jpg файлы изображений. Которые занимают небольшой размер и при этом обладают хорошим качеством. В Photoshop сохранять такие изображения можно командой Save for Web (Ctrl + Shift + Alt + S), или через функцию export assets если вы используете Photoshop CC. Не стоит сохранят большие непрозрачные картинки в .png формате, он занимает слишком много места, и для этого лучше использовать jpeg формат. Формат png подходит для небольшой графики которая используется в оформлении сайта, в шаблоне, это могут быть изображения кнопок, буллеты, изображения с прозрачным фоном.

Некоторые миниатюры к записям у меня были сохранены в .png формате, и размер изображения достигал 300 Кб. Пересохранив изображения в jpg формат, каждая миниатюра стала занимать 60-90 Кб в среднем. Таким образом вес некоторых изображений уменьшился в 3-4 раза, без потери качества.

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

3. Настройка wp-config.php для ускорения работы сайта на wordpress

Небольшой способ снизить загрузку на хостинг — отредактировать файл wp-config.php, который находится в коревой директории вашего сайта.

Находим в файле wp-config.php строку:

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

4. Настройка Robots.txt — запрет на индексацию ненужным сайтам.

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

Например, помимо роботов от Yandex и Google на сайт также заходит поисковый робот от поисковика Yahoo. Таким кодом можно запретить Yahoo роботу просматривать сайт:

Я прописал следующие запрещающие директивы:

Вот пример моего файла robots.txt

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

5. Настройка файла .htaccess для снижения нагрузки на сервер.

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

Настройка №1. Часто с сайтов копируют информацию вместе с картинками, не изменяя адреса картинок. И когда такое происходит картинки лежащие на нашем хостинге загружаются на других сайтах, и это создает ненужную нагрузку на хостинг.

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

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

Настройка №2. В файле .htaccess можно и следует указать кэширование для некоторых объектов сайта (изображений, css и js фалов) чтобы браузер кешировал их на своей стороне и не загружал их каждый раз. Для этого в .htaccess ниже первого кода добавляем следующий код:

Настройка №3. Включим gzip сжатие страниц перед отправкой их пользователю. Вставим в .htaccess следующий код:

Настройка №4. Ограничение спама в комментариях. Большинство спам комментариев отправляются автоматически. Этим кодом мы запретим напрямую отсылать комментарии минуя форму комментирования. Теперь спам боты не смогу отправлять комментарии.

Настройка №5. Если вы пользуетесь системой FeedBurner, то у вас явно установлены плагины, которые отправляют RSS-контент на сайт FeedBurner. Сегодня вы можете их удалить, потому что перенаправить контент можно и без плагинов, уменьшив нагрузку на хостинг.

ВНИМАНИЕ. Не забудьте в примерах выше заменить адрес yourdomain.ru на адрес своего сайта.

6. Оптимизация базы данных

Важное значение в скорости работы сайта имеет База Данных. При сохранении постов по нескольку раз WordPress создает ревизии записи — состояния постов в разные моменты их редактирования. В результате со временем база данных содержит большое количество ненужных ревизий постов, и их необходимо очищать и оптимизировать. Сделать это можно с помощью плагина Optimize DB. Установить его можно из админки WordPress. Например запустив его на своем сайте я удалили более 1200 ревизий постов. Что значительно улучшило скорость работы БД.

7. Оптимизация кода шаблона (темы)

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

Настройка №1. Найти код, который отвечает за стили в файле header.php:

Внимание. Не забудьте изменить yoursite.ru на ссылку своего сайта.

Настройка №2. Изменить код пинбеков:

Заменить с исправлением yoursite.ru на свою ссылку:

Настройка №3. Изменение кода RSS ленты:

Заменить с исправлением yoursite.ru на свою ссылку:

Настройка №4. Довольно часто в подвале сайта (footer.php), разработчики тем оставляют совершенно ненужные запросы к Базе данных. Например:

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

Некоторые маленькие советы, которые позволят ускорить загрузку сайта:

1) Если ваш сайт не использует комментарии, не стоит их скрывать с помощью плагинов, это создает совершенно ненужную нагрузку. Так как вам комментарии совершенно не нужны, просто удалите следующий код из файла темы (single.php):

2) Старайтесь не использовать внешние скрипты, такие как, комментарии от Вконтакте, различные виджеты социальных сетей. Да, это выглядит красиво и эффектно, но создает приличную нагрузку на сайт. Из примеров могу сказать что мой сайт значительно грузил код веб-визора от ЯндексМетрики, виджет Add.This. Кнопки соц сетей я поменял на отельный JS плагин.

3) Почистите весь код вашего сайта от комментариев, данные комментарии вставляются с помощью тегов и /*код/. Оставьте только нужное, так как сайту приходится тратить лишние силы на их загрузку…

4) Старайтесь размещать все скрипты в конце страницы перед закрвающим тегом

Как упороться по оптимизации скорости загрузки страниц

При оптимизации скорости загрузки сайта я анализирую результаты автоматического тестирования в сервисах Google Lighthouse, Google PageSpeed Insights и Webpagetest.org и только потом готовлю рекомендации. Эти же инструменты мы будем рассматривать в статье.

Небольшое объявление. В ноябре 2020 года ребята из Google обновили инструмент Google PageSpeed Insights: теперь проверка страницы выполняется средствами инструмента Lighthouse. Таким образом, результаты проверки Google PSI теперь являются данными из Google Lighthouse.

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

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

Содержание:

Оптимизация изображений

Высота и ширина

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

В качестве примера рассмотрим довольно подробную статью от Serpstat про оптимизацию изображений. В статье используются картинки такого вида (скриншот из сервиса webspeedtest.cloudinary.com):

Браузер должен загрузить изображение огромного размера (2,7 мегабайта), а также с большей высотой и шириной, с которой оно будет использоваться на самой странице сайта:

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

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

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

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

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

Объём, или же размер изображения

Мной заботливо украдена таблица из справочника Google для разработчиков, где наглядно показана корреляция объёма изображения от его размера (ширины и высоты):

Размер Пиксели Размер файла
100 x 100 10 000 39 КБ
200 x 200 40 000 156 КБ
300 x 300 90 000 351 КБ
500 x 500 250 000 977 КБ
800 x 800 640 000 2500 КБ

Чем больше высота и ширина изображения, тем больше оно будет весить (логично), но масштабы увеличения этого объёма губительны для скорости загрузки.

То есть следует понимать, что для максимальной оптимизации изображения, необходимо:

  1. Уменьшить ширину и высоту
  2. Сжать качество

Для сжатия качества я чаще всего использую сервис compressor.io, однако у него есть существенный недостаток — работает только с одним изображением. Для оптимизации нескольких картинок нужно искать другие сервисы. Тут на помощь можно звать сервис Google PageSpeed Insights, который после анализа любой страницы предлагает скачать архив с уже оптимизированными и сжатыми ресурсами:

Lazy Load

Одна из рекомендаций в моём арсенале — реализация Lazy Load.

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

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

5 ноября Google добавил рекомендации для Lazy Load, а вот тут собрана подробная инструкция по настройке изображений и видео (материал на английском языке).

BASE64 и CSS-спрайты

Для небольших вспомогательных изображений-элементов дизайна рекомендуется рассмотреть кодирование картинок в BASE64 или использование CSS-спрайтов. Это позволит убрать дополнительный запрос к серверу, а изображение будет корректно отображаться на странице (во всех современных браузерах). Таким образом можно «разгрузить» сервер лишними обращениями, что тоже ускорит время загрузки. Как показывает практика, изображения лидируют по количеству обращений к серверу, однако вместе с использованием base64 можно изменить этот стандарт. Ниже показан скриншот из сервиса webpagetest.org. С перекодированием изображений в base64 мне удалось на одном своём сайте сократить количество реквестов до 14, и это очень мало.

Следует отметить, что использование base64 подходит только для совсем маленьких элементов — иконки или кнопки. Допускается использование для небольших не сложных изображений, например, однотонных или с добавлением текста. Для больших картинок использованный в html-разметке код будет занимать больше объема, чем объём самого изображения в формате, к примеру, jpeg. Подробнее про влияние большого нерационального количества Base64 в коде сайта можно почитать в этой статье на английском языке.

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

Оптимизация CSS

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

Для оптимизации CSS следует придерживаться нескольких техник:

Загрузка только нужных CSS

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

Для оптимизации этого сайта я воспользовался инструментом unused-css.com.
Суть его работы заключается в исследовании сайта и используемых CSS правил. Если инструмент находит правила, которые не используются на страницах, то он их удаляет. В конечном итоге можно получить из огромного файла список только необходимых сайту стилей:

Используемый мной файл стал на 72% процента «легче» после того как инструмент удалил 78% правил CSS.

Малые CSS лучше включить сразу в HTML-код

Лучше отказаться от загрузки небольших CSS файлов. Если отдельный документ CSS содержит 10-20 строк кода, содержимое этого файла рекомендуется встроить сразу в html код с помощью тега . Это позволит сократить время обработки правил CSS, минуя стадию загрузки отдельного файла (опять же, оптимизация серверных реквестов).

Использование только файлов CSS и тега

Не рекомендуется встраивать стили оформления в теги документа. Следует использовать файлы или теги в связке с атрибутами class. Пример некорректного использования:

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

Минификация файлов CSS

Рекомендуется для всех файлов CSS провести минификацию. Это позволит удалить ненужные символы и пустые строки / пробелы в файлах, что повлечёт за собой сокращение объёма каждого файла. Для CSS Google рекомендует использовать CSSNano или ccso.

Можно встретить примеры плагинов для разных CMS, которые делают минификацию файлов CSS, например, бесплатные AutoOptimize для WordPress, MinifyX для MODx Revolution или отдельные плагины для Битрикс.

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

Оптимизация JS

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

Для оптимизации скриптов на сайте необходимо следовать рекомендациям:

Загрузка только используемых файлов JS

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

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

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

Встраивание JS скриптов в HTML-код

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

Самый простой способ ускорить загрузку сайта

Скорость загрузки сайта влияет на позиции в поисковой выдаче.

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

Далее рассмотрим что делать и принцип действия.

Как ускорить загрузку сайта быстро и просто?

На большинстве сайтов используется код JavasScript. По умолчанию робот использует последовательную загрузку скриптов.

На практике наиболее распространенные сценарии применения скриптов следующие:

  • Подключение систем аналитики, таких как Google Analytics и/или Yandex Метрика;
  • Использование скриптов JavaScript при решении задач по user interface или user experience.

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

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

Критическим путем рендеринга (Critical Rendering Path) называется последовательность шагов, необходимых для первого отображения страницы.

Если нет желания разбираться в технических деталях (все-таки уже потеплело на улице), то для ускорения загрузки страниц сайта просто прочитайте и внедрите следующие правила:

  • Код JavaScript должен быть вынесен во внешний файл;
  • К тегу script должен быть добавлен атрибут defer.

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

До вывода страницы на экран проходит 6 этапов критического пути рендеринга:

  1. Построение DOM-дерева;
  2. Построение CSSOM-дерева;
  3. Запуск JavaScript;
  4. Создание Render-дерева;
  5. Генерация расположения;
  6. Визуализация.

Под термином DOM (Document Object Model) подразумевается объектная модель страницы.

Структура DOM выстраивается из узлов, так называемых нодов (от nodes).

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

Под термином CSSOM (CSS Object Model) подразумевается объектная модель стилей страницы сайта.

Не имеет значения то, как стили были заданы: объявлены явно или наследуются.

CSS является блокирующим обработку ресурсом, а значит Render-дерево не может быть построено без полного первоначального разбора CSS.

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

Render-дерево представляет собой объединение из DOM и CSSOM, и включает только видимые элементы. Например, исключаются элементы, которые были скрыты с использованием display none.

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

Поисковая оптимизация критического пути рендеринга

Модели DOM и CSSOM связаны с JavaScript.

JavaScript является блокирующим ресурсом для роботов, то есть JavaScript блокирует разбор HTML-документа.

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

Но блокировки робота можно избежать!

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

Есть 2 важных директивы:

  • async;
  • defer.

При не использовании директив код выглядит так:

5 способов увеличить скорость загрузки сайта

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

Вводные факты

В первую очередь скорость загрузки влияет на поведенческие факторы: глубину просмотра и количество отказов. У быстрых сайтов выше показатель конверсии. Также от скорости косвенно зависит успех поискового продвижения: при прочих равных Google учитывает время загрузки страницы.

  • Инженеры Google выяснили, что пользователь замечает даже пустяковую задержку загрузки — 0,4 секунды;
  • Пользователь с большой вероятностью покинет страницу, если та загружается 3+ секунд;
  • Мобильные пользователи готовы ждать немного дольше — 6-10 секунд;
  • 79% пользователей интернет-магазинов не сделают повторную покупку, если в первый раз сайт загружался долго.

Эксперимент Financial Times

Представители деловой газеты провели эксперимент с новым сайтом издания.

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

ТОП-100 лучших SEO-агентств России 2020

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

Ответ – в свежем рейтинге SEO-компаний за 2020 год по версии RUWARD.

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

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

Скорость загрузки можно измерить с помощью этих сервисов:

Как увеличить скорость загрузки сайта

1. Уменьшите объем загружаемых страниц

Используйте сжатие gzip, это сократит время передачи файлов браузеру. Объём передаваемых данных уменьшится в 4-5 раз, а скорость загрузки — увеличится.

Nginx

Для включения сжатия gzip в Nginx, измените конфигурацию сервера и добавьте эти строки:

server <
.
gzip on;
gzip_disable «msie6»;
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript;
>

Apache

Сначала убедитесь, что подключен модуль mod_deflate. После этого нужно добавьте в файл .htaccess следующие строки:

AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript

Уровень сжатия

Gzip поддерживает уровень сжатия от 1 до 9. В Nginx его можно регулировать таким образом:

Оптимальный уровень сжатия — 5.

2. Уменьшите объём графики

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

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

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

Как это работает:

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

3. Уменьшите количество запросов браузера

Этот пункт перекликается с предыдущим. Один из способов уменьшить количество запросов браузера — удалить со страницы часть элементов.

Используйте CSS-спрайты — графические файлы, содержащие сразу несколько изображений. Это оптимальный способ, если на сайте много маленьких изображений и иконок. Объедините несколько CSS- и JS-файлов в один, это сократит количество HTTP-запросов.

Чтобы посмотреть количество запросов браузера в Chrome, войдите в «Инструменты разработчика» (Настройки → Дополнительные инструменты) и перейдите во вкладку Network.

4. Включите кэширование данных

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

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

Как включить кэширование?

Используйте модуль headers веб-сервера Apache, который контролирует и изменяет заголовки HTTP-запросов и HTTP-ответов. Браузер загружает с сервера в локальный кэш данные, которые редко изменяются, и при посещении сайта загружает их уже из кэша. Также можно кэшировать файлы определённых типов на заданное время, по истечении которого они будут загружены с сервера заново.

Это можно сделать так:

Header set Cache-Control «max-age=1234000»

Укажите нужные расширения файлов в конструкции FilesMatch, где для них устанавливается заголовок Cache-Control и переменная max-age, с помощью которой указывается время хранения файлов в секундах. Те файлы, которые не нужно кэшировать, просто не включайте в список.

Также можно запретить кэширование файлов. Добавьте приведённый ниже код в .htachess, предварительно указав, какие типы файлов кэшировать не нужно:

Header unset Cache-Control

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

ExpiresActive On
ExpiresDefault «access plus 2 month»

ExpiresByType image/png «access plus 4 months»
ExpiresByType image/swf «access plus 4 months»

ExpiresByType text/html «access plus 2 month 14 days 7 hours»
ExpiresByType image/gif «modification plus 8 hours 3 minutes»

5. Сократите размер кода CSS и JavaScript

Специальные сервисы для упрощения JavaScript и CSS удаляют из кода «лишние» символы (пробелы, комментарии) и сокращают время его загрузки. Для увеличения скорости они могут быть эффективнее, чем стандартное сжатие gzip. Google рекомендует СSS-файлы небольшого размера вставлять непосредственно в документ HTML.

Вы можете воспользоваться этими сервисами:

Размещайте CSS-файлы в начале страницы, а JS-файлы — в конце.

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

Источник фото на тизере: Depositphotos

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

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

Время чтения: 9 минут Нет времени читать? Нет времени?

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

Насколько быстрой должна быть скорость загрузки сайта?

  • 1 секунда – великолепно.
  • 2-3 секунды – очень хорошо.
  • 4-7 секунд – нормально, но есть куда расти.
  • 8-10 секунд – плохо.
  • 11 секунд и более – ужасно, начинайте бить тревогу, т.к. огромные деньги утекают прямо из-под вашего носа.

Согласно исследованию Strangeloop, в ходе которого была протестирована скорость загрузки 2000 топовых интернет-магазинов, в среднем скорость загрузки коммерческих сайтов составляет 10 секунд. Возможно, вы спросите: «С какой стати мы должны улучшать скорость загрузки своего сайта, если даже топовые интернет-магазины грузятся так долго?» А вот и ответ:

  • 57% посетителей покидают страницу, которая грузится более 3-х секунд.
  • В те моменты, когда сайт тормозит из-за большого количества трафика, более 75% онлайн-покупателей предпочитают уйти на сайт конкурента.
  • 2 секунды – столько примерно будет ждать терпеливый пользователь до тех пор, пока на экране появится информация. Добавление такого элемента, как «прогресс-бар» может продлить время его ожидания до 38 секунд.
  • Сайт, который грузится 3 секунды, имеет на 22% меньше просмотров, на 50% больше отказов и на 22% меньше конверсии, чем сайт, который грузится 1 секунду. Сайт, который грузится 5 секунд, имеет еще более плохие показатели – на 35% меньше просмотров, на 105% больше отказов и на 38% меньше конверсии.
  • 8% людей считают, что главной причиной их ухода с сайта является медленная загрузка страниц.

Сервисы, с помощью которых можно протестировать скорость загрузки сайта:

Обращаем ваше внимание, данные сервисы не смогут решить ваши проблемы. Их главная функция – проанализировать скорость загрузки сайта. Все дальнейшие действия должны исходить именно от вас.

Чем быстрей загружается сайт, тем лучше конверсия

Чтобы убедиться в этом, изучите следующие результаты исследований:

  • Исследование Aberdeen Group показало, что в результате задержки в 1 секунду уменьшается количество просмотров (на 11%), процент удовлетворенности аудитории (на 16%), а также коэффициент конверсии (на 7%).
  • Компания Shopzilla увеличила скорость сайта на 5 секунд и тем самым повысила конверсию на 12%
  • Сократив время загрузки своих посадочных страниц, компании Mozilla удалось увеличить количество загрузок на 15,4%, что привело к 60 млн дополнительных загрузок.
  • 85% мобильных юзеров ожидают, что сайты будут грузиться так же быстро, как и на компьютере. Не получая такого же результата, они покидают сайт.

Источники: gomez.com, aberdeen.com, en.oreilly.com, blog.mozilla.com

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

5 способов увеличить скорость загрузки сайта

Итак, что же можно сделать, чтобы ускорить загрузку сайта:

1. Уменьшите размер страниц сайта

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

Чтобы уменьшить размер страниц, в первую очередь воспользуйтесь сжатием данных в протоколе HTTP. Это уменьшает размер текстовых ресурсов, включающих элементы HTML, CSS и JavaScript, на 50% и более. Для сжатия данных протокола HTTP используются технологии zip, gzip и другие.

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

2. Снизьте «вес» графики

Графика часто составляет 80% и более от общего размера страниц. Поэтому очень важно правильно оптимизировать публикуемые фотографии. Следующие рекомендации помогут вам уменьшить размер изображений на 50% и более:

  • Публикуйте фотографии в формате JPEG, избегайте формата PNG. Формат JPEG позволяет сильно сжимать изображения без потери качества. Например, в день представления Windows 8 компания Microsoft опубликовала на главной странице сайта фото в формате PNG, «вес» которого составил 1 МБ. Фото аналогичного качества в формате JPEG имеет размер приблизительно 140 КБ.
  • Не злоупотребляйте использованием формата PNG для обеспечения прозрачности графики. Эффект прозрачности — это очень красиво, но не всегда функционально.
  • Корректно выбирайте уровень качества картинок в формате JPEG. Уменьшив качество фото на 25-50%, вы практически не заметите разницы по сравнению с исходным изображением. При этом «вес» иллюстрации значительно уменьшится.
  • Очищайте графические файлы от цифрового мусора. Различные редакторы фото, которыми наверняка пользуется ваш дизайнер, оставляют в файле много различных данных, например, комментарии, рабочие версии изображения, неиспользуемые палитры и т.п. Этот цифровой мусор не нужен вашим читателям. Чтобы очистить файл, воспользуйтесь сервисами Pngcrush, или Smush.it.

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

3. Упростите код JavaScript и CSS

Использование специальных средств упрощения кода JavaScript и CSS уменьшает «вес» соответствующих элементов сильнее, чем стандартные технологии сжатия, например, gzip. Сервисы упрощения удаляют из кода лишние элементы, а также сокращают названия функций.

Чтобы упростить код элементов JavaScript и CSS, воспользуйтесь программными средствами или онлайн-сервисами, например, Online Javascript Compression Tool или Online JavaScript/CSS Compression.

4. Уменьшите число запросов браузера

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

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

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

  • Разрешите браузерам кэшировать данные. Если страницы вашего сайта являются статическими, нет нужды «заставлять» посетителей всякий раз загружать их содержимое заново. Попросите администратора сервера или хостинг-провайдера включить опцию кэширования фотографий, элементов CSS и JavaScript. Чтобы проверить результат этого действия, воспользуйтесь, например, сервисом Redbot.
  • Комбинируйте и сжимайте файлы CSS и JavaScript. Объединяя эти элементы, вы значительно уменьшаете количество запросов браузера. Этот метод подходит для статических страниц. Чтобы объединить файлы CSS и JavaScript, воспользуйтесь специальными сервисами и ПО, например, CakePHP.
  • Объединяйте небольшие фотографии в CSS-спрайты. Это особенно удобно для ресурсов, на которых есть много иконок, кнопок и других маленьких изображений. Специальные сервисы позволяют объединить их в один файл, который называется CSS-спрайт. Воспользуйтесь инструментом SpriteMe, чтобы проверить эффективность данной рекомендации на практике.

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

5. Сократите расстояние между сайтом и пользователями

Если сервер вашего хостинг-провайдера находится во Владивостоке, посетителям из Санкт-Петербурга придется набраться терпения, ожидая загрузки страницы. Эта проблема особенно актуальна для сайтов с «тяжелым» контентом, которые посещают пользователи, физически удаленные от сервера на большие расстояния. Чтобы решить эту проблему, воспользуйтесь сетями доставки контента (CDN), например, Amazon CloudFront или Akamai.

Как уменьшить время загрузки страницы сайта: оптимизация на примере проекта Superbalist

Наиболее частая задача, с которой ко мне обращаются клиенты — это оптимизация сервера для работы информационных сайтов на WordPress. Да и не только на WordPress, но на ней 90% сайтов. Не менее часто обращаются люди, которым нужно оптимизировать сервер для быстрой работы интернет-магазинов. Это история отдельная, ибо там есть особенности. И которая тоже когда-нибудь выйдет на страницах моего блога. Так вот, это, можно сказать, стало уже типовой задачей. Поэтому я решил подробно описать что такое оптимизация сервера и как это происходит. Какие возможности и настройки при этом затрагиваются. Каковы причины, из-за которых возникает необходимость в оптимизации. С них, пожалуй, и начнём.

Зачем нужна оптимизация сервера? Наиболее частые причины

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

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

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

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

SEO-специалисты, оптимизаторы рекомендуют добиться хорошей оценки в Google Pagespeed Insights

Типичная картина вторая: кто-то где-то как-то вам поведал о том, что сайт плохо растет в поиске если у него долгое время отклика. Мол, гугл имеет православный инструмент Pagespeed Insights, и если сайт не набирает достаточное количество попугаев в гугловой оценке, то будет у него все плохо, и вообще это чуть ли не единственная причина всех проблем с продвижением сайта. А вот если гугл покажет зелень — то все будет огонь, сайт взлетит в топы как ракета.

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

Вкратце — этот инструмент НЕ ВЛИЯЕТ ни на что сам по себе. Имеет значение время отклика сайта. Если оно более 2 сек — есть смысл оптимизировать. Время отклика можно увидеть там же, если раскрыть подробности по пункту «Сократите время ответа сервера». Я же предпочитаю смотреть его через отладчик браузера. Так же стоит знать, что многие сайты из топов имеют оценку «ниже плинтуса» — по 20-40 баллов, но это им не мешает сидеть в топах. И с другой стороны, сайт может выдавать зелень — 90 попугаев, но быть «ниже плинтуса» уже в выдаче. Сайт может иметь хорошую оценку, но открываться по 3-5 секунд. Или иметь 20-40 баллов — и летать за 0,3-0,5 секунд. Так что логику гугла и тех сеошников тут не уловить. Гугл предоставил неплохой инструмент, но не стоит доводить до маразма. Ориентироваться ли на его показания? Конечно! Но без фанатизма. И без завышенных ожиданий.

Сервер «падает» от большой посещаемости сайтов

Чуть менее типичная картина третья ( может быть и продолжением и дополнением первой, второй, или обеих):
Сайт имеет приличную посещаемость от 10000 уников в сутки ( хотя может быть и меньше) и есть проблема со временем открытия страниц. Сначала в часы пик, а потом и вообще постоянно. При этом время открытия страниц дольше 1-2 секунд. Сайт может перестать расти или начать падать.

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

Что происходит при этом и почему сервер не держит нагрузку?

Итак, для начала разберём почему могут быть подобные трудности. Нагрузка на сервер может возникать по трем наиболее частым причинам:

  1. У вас действительно очень посещаемый сайт и софт при стандартных настройках начинает захлебываться. Появляются лаги, некоторые или все страницы открываются дольше, особенно в часы пик.
  2. Вторая причина — это поисковые боты. Особенно если большое количество страниц — то при посещениях индексирующих ботов могут появиться проблемы с производительностью. Это может быть как самостоятельная причина, даже когда на сайте относительно небольшой трафик, так и в совокупности с первым случаем — и люди и боты. Определить это можно по логам вебсервера — access лог можно проанализировать и это сразу будет видно.
  3. Паразитный трафик. Это может быть обычный тупой брутфорс(перебор паролей) на админки сайтов, может быть попытка атаки на xmlrpc, а может быть банальный парсинг контента с вашего сайта.

Так ли необходима оптимизация под Google Pagespeed Insights?

Теперь стоит ещё раз остановиться на ситуации второй — когда вам нужна оптимизация ради оценки Гугла, якобы для продвижения сайта. На самом деле это миф, по большей части. Ибо пока сайт открывается быстрей 1-2 секунд — это МГНОВЕННО! И это практически не влияет на продвижение. Проблемы действительно могут быть, если сайт грузится дольше одной-двух секунд. Тогда это в самом деле может ухудшать поведенческие факторы, и влиять на SEO. Пруфы.

Как решить рекомендацию гугла «Сократите время ответа сервера»?

Тем не менее, Гугл считает, что сайт недостаточно быстр, если TTFB более 0.2 секунды (200 ms). Такой загрузки можно добиться обычно только лишь кэшированием, и на этом остановлюсь чуть подробнее далее.

Но без кэширования норма времени генерации страниц сервером для того же wordpress обычно в пределах 0.5-1 сек. На очень быстром сервере с дефолтным шаблоном и php 7 пустой вордпресс будет показывать что-то около 0.3-0.5 секунд.
Если же в вашем случае это ощутимо дольше, то скорей всего можно комплексной оптимизацией настроек софта на сервере добиться более быстрой работы сайтов.

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

Какой софт на сервере обеспечивает работу сайта?

Прежде всего надо говорить об nginx. В большинстве случаев он и так уже стоит. Он обрабатывает все входящие запросы, и делает это очень легко и быстро. Второй компонент это — обработчик PHP. Это чаще всего apache. Как универсальный обработчик он стал стандартом де-факто практически у любых хостеров. Апач — прекрасный софт, как раз в силу своей универсальности.

Но он не выдерживает конкуренции с режимом php-fpm там, где появляется нагрузка. Он как раз чаще всего и является узким местом в производительности системы. Это решается подбором более производительного вашем случае режима работы и/или подбором настроек. (подробней о режимах работы и связках вебсервера — компоненты nginx, apache, php-fpm, php-cgi)

Но режим имеет значение при ооочень больших нагрузках. Сотни тысяч посещений в сутки. Хотя, иногда и при десятках килоуников могут быть проблемы. Надо понимать, что php-fpm не прибавляет скорости. Он даёт лишь производительность.

Что это такое? Это значит, что он позволяет быстрее обрабатывать запросы при больших нагрузках. Там, где появляется большой трафик — апач начинает захлебываться, потреблять больше ресурсов. И там для быстрой загрузки страниц возникает потребность увеличивать ресурсы сервера, переходить на более мощные тарифы или серверы. Php-fpm же может держать бОльшие нагрузки даже на минимальных аппаратных конфигурациях.

Какую нагрузку может держать сервер для WordPress? Как расчитать мощность сервера?

Если в цифрах — то php-fpm примерно в 3-5 раз производительней apache. Это не значит, что он будет быстрей отдавать страницы, но. К примеру, возмем дешевый VPS с 1 GB памяти и 1 CPU. Возьмем типовой сайт на wordpress. Без кэширования, сайт на apache при этих ресурсах будет работать с минимальным временем отклика примерно до посещаемости 2-3 тысячи посетителей в сутки. Там конечно еще имеет значение количество хитов, но в среднем из практики цифры примерно такие. (Кейс — как я оптимизировал сайты на недорогом VPS )

Свыше 3к суточного трафика у wordpress на апаче на таком VPS начнутся тормоза. Особенно в часы пик. Часто эта проблема решается кэширующими плагинами. С ними можно говорить уже о 5-10к трафика при такой конфигурации. Если же сайт на этих ресурсах запустить в режиме nginx+php-fpm, то он будет откликаться максимально быстро даже при 10-20к трафика. Если поставить кэширующий плагин — можно еще получить запас прочности в 2-3 раза — до 30к трафика.

И наконец, если использовать серверное кэширование nginx, на таком VPS можно держать сотни тысяч посещений ��

Настройка сайтов в режиме nginx+PHP-FPM

К примеру, любая из популярных CMS из заголовка статьи гораздо лучше держит нагрузку в режиме nginx+php-fpm. У меня почти все сайты на wordpress, так я только в таком режиме их и запускаю. Типовая конфигурация для wp имеет примерно такой вид:

server <
server_name vpsadm.ru www.vpsadm.ru;
charset off;
index index.html index.php;
disable_symlinks if_not_owner from=$root_path;
include /etc/nginx/vhosts-includes/*.conf;
include /etc/nginx/vhosts-resources/vpsadm.ru/*.conf;
access_log /var/www/httpd-logs/vpsadm.ru.access.log;
error_log /var/www/httpd-logs/vpsadm.ru.error.log notice;
set $root_path /var/www/user/data/www/vpsadm.ru;
root $root_path;
location / <
try_files $uri $uri/ /index.php?$args;
location

[^/]\.ph(p\d*|tml)$ <
try_files /does_not_exists @php;
>
>
location @php <
fastcgi_index index.php;
fastcgi_param PHP_ADMIN_VALUE «sendmail_path = /usr/sbin/sendmail -t -i -f [email protected]»;
fastcgi_pass unix:/var/www/php-fpm/vpsadm.sock;
fastcgi_split_path_info ^((?U).+\.ph(?:p\d*|tml))(/?.+)$;
try_files $uri =404;
include fastcgi_params;
>
listen *:80;
>

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

try_files $uri $uri/ /index.php?$args;

Панель этого не умеет, по крайней мере пока. Именно она обеспечивает корректную работу ЧПУ, и заменяет привычный файл .htaccess, используемый в Apache. А вот в VestaCP есть шаблоны конфигов под работу популярных CMS в этом режиме.
Joomla тоже будет работать с аналогичным конфигом в связке nginx+php-fpm. А в случае с DLE все выглядит чуть сложнее:

Впрочем, ДЛЕ крайне редко нуждается в такой оптимизации, ибо сама CMS легкая и быстрая, да ещё и внутренний кэш имеет.

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

Основа оптимизации всего и вся — кэширование

Это единственный принцип, который даёт ощутимый эффект к производительности в работе любого серверного софта, и в том или ином виде он применяется на всех уровнях стека LAMP/LEMP(классически аббревиатура обозначает Linux Apache Mysql PHP, но сейчас уже давно стандартом де-факто стало использование nginx+apachе/php-fpm+mysql).

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

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

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

Оптимизация и ускорение исполнения PHP-кода

С этим обычно связаны самые большие накладные расходы в работе CMS. Чтобы это было понятней вам, мне придется объяснить что такое язык PHP.

Дело в том, что языки программирования делятся на компилируемые и интерпретируемые. К первым относится например C++ и его дедушка C(си), на котором написано больше всего софта в мире. Это значит, что код однажды переводится в машинный язык и в таком виде остаётся, это и есть готовая программа. Поэтому он выполняется очень быстро — сразу в процессор, грубо говоря. PHP же, и многие другие языки, которые используются ныне для веб-разработки (python, js, ruby) относятся к языкам интерпретируемым или скриптовым. Это значит, что программа представляет собой набор команд и исполняется последовательно, «на лету».

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

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

66 — это не много. Чаще всего при работе с wordpress запросов около сотни. В случае с интернет-магазинами — может быть и 200-300.

Обращение к PHP при этом производится к одному скрипту, но тому для получения результата нужно чтобы выполнились десятки или сотни других скриптов. В случае с wordpress — обычно это index.php. И каждый из таких скриптов выполняется аналогично — последовательно и на лету. Это уже совсем дебри, но я, пожалуй, покажу вам, как это выглядит изнутри:

Для загрузки одной страницы веб-сервер исполняет 82 скрипта самого wordpress и плагинов на этом сайте. У меня не влез в один экран список вызовов скриптов, который я вытащил с помощью ядерного отладчика strace. Но должно быть отчетливо видно, что все эти скрипты от index.php до footer.php были исполнены в одну секунду «17:22:59» и время исполнения составило около 0,3 секунд. 0,304571, если быть точным ��

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

О нём же и говорит гугл в своей многим непонятной рекомендации о сокращении ответа сервера. Примерно соответствует, верно? Откуда взялись еще 80 милисекунд? А это время, затраченное вебсервером nginx на «общение» с обработчиком php и сборку html-страницы. Как видите, на фоне исполнения PHP он молниеносен. Это действительно так. В этом легко убедиться, если исключить всю работу php и mysql, оставив отдачу страницы одному только Nginx:

Тут видим всё же не 0,08 сек, а чуть больше — 0,11. Чем объяснить? Я не знаю, а копаться еще и в системных вызовах nginx у меня желания нет �� Тут на таких малых цифрах может быть всё что угодно — может просто скачки нагрузки на оборудование, а может быть во время обработки PHP nginx не всё время просерает ждёт, а делает что-то ещё параллельно. Зная его и восхищаясь этим крутым веб-сервером, я подозреваю что так и есть — и эти 0,03 сек никуда не теряются, а лишь накладываются на время исполнения PHP. Ну да ладно. На последнем скрине — это идеальный вариант отдачи страницы, и о нем будет речь чуть дальше.

Оптимизация исполнения PHP кода CMS с помощью акселераторов opcache, xcache, APC

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

Впервые я с этим столкнулся когда всюду использовалась версия PHP 5.3. Я стал использовать это в виде расширения APC, и это стало довольно таки прорывной вещью для меня и проекта, над которым я тогда работал. Начиная с версии 5.5 обычно используется opcache, и говорят он вроде как встроен. Но на самом деле не всегда. Обычно это дополнительное расширение, которое нужно доустанавливать. С установкой проблем нет, его можно легко включить в том же ISPmanager в разделе «Расширения PHP». В случае если вы не юзаете панель управления, то оно ставится с помощью yum (centos) или apt-get (ubuntu, debian). Что-то вроде:

yum install php-opcache

Иногда достаточно одной лишь установки, если у вас один небольшой сайт на простенькой CMS. И чаще бывает так, что акселератор opcache установлен, но работает неэффективно, ибо по-умолчанию ему выделено недостаточно памяти.

Как проверить установлен ли opcache или другой акселератор PHP?

Обычно из консоли можно просто просмотром версии PHP, комадной php -v:

Но то что он установлен ещё не гарантирует, что он задействован на вашем сайте. При проверке таким образом можно точно сказать что он оптимизирует ваши сайты, если на сервере установлена лишь одна версия PHP. Кроме этого при проверке таким способом срабатывает PHP-CLI — интерфейс командной строки. Но расширение может быть не подключено для режима PHP, на котором работает сайт — для apache, например.

Во-первых, он может быть установлен не для той версии PHP, которая используется для сайта. Как на 100% убедиться, что он задействован? Исполнить проверку с помощью функции phpinfo(). Этот метод (описывал тут ) позволяет со 100% точностью определить все настройки PHP для вашего сайта.

Но и это ещё не всё. Дело в том, что opcache может не работать, если PHP запущен в режиме CGI. Почему — вдаваться в подробности не буду. Просто потому, что такие особенности у этого режима. Недаром он самый низкопроизводительный. Если вы хотите чтобы opcache работал, то нужно запускать сайт в режиме модуля apache или php-fpm.

Как посмотреть настройки и эффективность работы opcache?

Для этого можно добавить в корень сайта файлик opcache.php с таким кодом. Затем, при обращении по адресу site.com/opcache.php можно будет увидеть статистику работы акселератора:

Чаще всего вы увидите аналогичную картину. Это значит что акселератору не хватает памяти. Кэшируется лишь часть скриптов. Соответственно, те, что не закэшированы всякий раз исполняются полностью, что снижает производительность веб-сервера. Там же можно посмотреть список закэшированных скриптов и прочие настройки расширения. Эффективность работы можно увидеть на вкладке hits.

В данном случае казалось бы эффективность не сильно снижена, что и отражает данная статистика. Hits это попадания — т.е. выполнение кэшированных скриптов, которые выполняются гораздо быстрей. Misses — пропуски, т.е скриптов в кэше нет. В данном случае мимо кэша идёт всего лишь 0,7% скриптов. Но тут надо понимать, что в эти 222 тысячи миссов может попадать тот самый скрипт, который требует больше памяти и выполняется по 5 секунд �� Гораздо эффективней акселератор будет работать, если у вас статистика использования памяти имеет такой вид:

А статистика исполнения скриптов из кэша примерно такая, или еще лучше:

В данном случае opcache настроен «на грани» ибо память как видите забита почти вся, осталось 16 байт �� Такая ювелирность связана с небольшим количеством памяти на VPS, я подсчитал чтобы ровно столько сколько нужно использовалось и не килобайтом больше… На самом деле нет. Просто я не заглядывал туда давно, и эти копейки там уже особо роли не играют, а значения 128 и 256 это стандартные «айтишные» числа — степень двойки, и «ювелирная точность» просто совпадение. Вряд ли у меня там упускается и не попадает в кэш что-то критичное. Вот, а в случае с клиентом, с которого взяты первые три скрина — увеличение памяти повлияло ощутимо. Там нормальные настройки opcache ускорили сайт примерно с 2 сек до 1,3.

Какое ускорение и прирост производительности даёт opcache?

Тут не угадаешь. Обычно от 30 до 100% ускоряет. Иногда больше, иногда меньше. Но в целом примерно такая картина — наличие и отлаженная работа акселератора ускоряет отклик страниц в 1,5-2 раза

Где и какие изменить настройки opcache?

Нужно искать файлик opcache.ini где-то в /etc/. В разных системах и разных версиях PHP он может называться по-разному — 20-opcache.ini например, быть в /etc/php5/apache2/conf.d/opcache.ini или в /etc/php/php.d/20-opcache.ini. А иногда даже в /opt/remi/php70/etc/php/php.d/2o-opcache.ini, как например при использовании ISPmanager 5 и настройке opcache для альтернативных версий PHP. Имеет он примерно такой вид:

Итак, для оптимизации требуется подобрать количество памяти в мегабайтах, в очевидном параметре opcache.memory_consumption, также стоит изменить и opcache.max_accelerated_files — количество прекомпилированных скриптов. Нужное вам количество можно подобрать поглядывая на третью вкладку scripts в статистике opcache. Увеличивайте, пока количество кэшированных скриптов при работе сайтов не станет меньше чем указанное значение. Точно так же подбирайте.

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

Смысл в отключении валидации файлов скриптов на изменения. Кэшер всякий раз проверяет изменился ли скрипт, прежде чем использовать кэшированную версию. Это дополнительные ресурсы и время. Отключение этой валидации позволяет добавить еще процентов 20-30 к производительности выполнения кода. Причем, вам необязательно что-то реально разрабатывать чтобы столкнуться с проблемами. Элементарная настройка шаблона или плагинов через панель управления того же wordpress может глючить. Посему, не используйте эти настройки. О них очень легко забыть и потом биться в истерике пару часов, пока вспомните почему не работают настройки и не появляются изменения �� Проверено.

systemctl restart service_name #новые OS, например centos 7

service service_name restart #новые debian или ubuntu

или такой вариант, который работает в старых версиях OS (centos 6, debian 6, ubuntu 12.04, etc):

вместо service_name нужно подставить имя настраивемой службы: nginx, mysql(d), apache2/httpd, php5-fpm/php-fpm/php-fpm70 — они могут иметь какие-то такие названия. К примеру, после настройки opcache вам нужно сделать рестарт apache — значит это будет httpd в centos или apache2 в deb-системах

Оптимизация настроек xcache

Фухх. Это только opcache. Есть еще apc, который уже устарел, и после версии 5.4 больше не используется. Хотя и есть костыли для обратного портирования даже на php 7, но юзать их тот еще гемор. Да и смысла в этом обычно нет. А вот Xcache в принципе заслуживает внимания. Просто потому что он по эффективности почти не уступает opcache (см. график с хабра выше). Но в них настройки сводятся все к тем же принципам — увеличение памяти и количества скриптов. В Xcache еще нужно подбирать count — количество пулов в зависимости от количества ядер и/или процессоров в системе. Но останавливаться на этом сильно не буду. Покажу лишь как выглядит его статистика до и после оптимизации, бо недавно делал и скрины недалеко:

Это работа неоптимизированного акселератора. Всего 16 мегабайт памяти.

А вот так он работает после настройки:

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

Настройка пулов PHP-FPM

При использовании PHP-FPM не стоит оставлять ему конфиг по-умолчанию. Дело в том, что он с ним работает нестабильно и непонятно потребляет ресурсы. У fpm, кстати, довольно редко, но случаются странные зависания, выяснить причину которых практически невозможно. Ну по крайней мере я за 4 года работы с этим софтом способов не нашел. Зато на сотнях серверов опытным путём нашел, что при использовании режима dynamic FPM то чаще всего и ведёт себя неадекватно. Поэтому конфиг пула я делаю примерно таким:

Вот это три самые важные параметра, а все остальные можно оставить по-умолчанию. Первое режим. Всего там могут быть три варианта — кроме указанного еще static и dynamic есть. По умолчанию стоит именно dynamic и он самый нестабильный из всех возможных. Static — более стабильный, но ресурсоёмкий. Ибо он сразу запускает все процессы и выделяет на них память, поэтому с количеством процессов в таком режиме нужно быть очень осторожным. Ondemand самый удобный режим. Он работает так же стабильно как статик, но не жрет ресурсы. Как только ему нужны еще процессы — он их запускает. Не нужны — процессы умирают.

Далее, максимальное количество процессов, которые могут быть запущены — pm.max_children. Я обычно ставлю в зависимости от мощности сервера. Примерно 10-15 процессов на каждые 2 Gb памяти.

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

Этот конфиг по умолчанию находится где-то в /etc/php-fpm.d/www.conf в centos, и в /etc/php5/fpm/pool.d/www.conf в deb-based системах (debian, ubuntu). Но это, как всегда, не точно �� Во-первых, у вас сайты и пулы могут быть запущены под другим юзером. Тогда вместо www.conf нужный файлик будет именован как username.conf. Соответственно пулов и конфигов может быть несколько, они могут запускаться параллельно. А во-вторых, у вас может быть использоваться php альтернативной версии, и тогда нужно искать конфигурации пулов в другом месте. В каком — лучше всего смотреть через phpinfo().

Очистка любого конфига от примеров и комментариев, документации

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

Сделать это можно так:

cat /etc/php/php-fpm.d/www.conf|grep -v ‘^;\|^$’

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

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

Соответственно вариант будет таким:

cat /etc/httpd/conf/httpd.conf|grep -v ‘^#\|^$’

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

Базовые настройки PHP под нагрузку и тяжелые скрипты

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

Максимальное время исполнения скрипта. К примеру, вы заливаете на дорвей миллион ключей из файла через какой-то веб-интерфейс.

По-умолчанию:

max_execution_time = 30

Это в секундах. Лучше добавить сюда как минимум ноль, установив в 300. А иногда надо даже 600.

Максимальный объем памяти для выполнения одного (1!) скрипта.

memory_limit = 128M

По-умолчанию оно установлено в 128 мегабайт. Я недаром заострил внимание что речь идет лишь об одном скрипте. Помните сколько скриптов исполняется при запросе одной страницы? Это значит, что если у вас какое-то простое приложение, то обычно не нужно большое количество памяти для одного скрипта. И если приложение ее требует, то это повод задуматься о том, что что-то не так в коде. Но когда речь идет об импорте данных, это ситуация нормальная. Просто задавайте больший объем, перезапускайте apache и пробуйте еще раз. Увеличивать рекомендую с шагом в x2, обычно 256-512-1024 — ну просто для удобства используют эти числа.

Кроме этих параметров есть и другие, например максимальный объем загружаемого файла:

post_max_size = 8M
upload_max_filesize = 10M

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

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

Оптимизация настроек производительности apache (httpd)

Почему я пишу apache(httpd)? Потому что в rpm-based системах (centos, rhel, fedora) сам apache нигде не фигурирует. Он там называется httpd. В deb-based системах это именно apache, причем apache2. Ну это не относится непосредственно к оптимизации, просто это следует знать, чтобы не потратить кучу времени на поиск конфигов и сервиса.

Соответственно конфигурации их будут где-то в /etc/apache2/apache2.conf и /etc/httpd/httpd.conf.

Оптимизация apache сводится к настройке количества процессов и запросов. По аналогии с вышеописанными пулами PHP-FPM.

Однако в apache кроме этого есть разные режимы работы — prefork, worker, event. В 98% случаев у вас будет именно первый.

И его конфигурация имеет примерно такой вид:

Этим в принципе оптимизация apache и исчерпывается. Ну иногда еще есть смысл настроить таймауты и KeepAlive, но в случае с обычными сайтами скорей всего оно не влияет ни на что. А вот вышеуказанные настройки влияют на распределение и использование ресурсов.

StartServers — количество процессов запускаемых при старте Apache

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

MaxSpareServers — максимальное число неиспользуемых процессов. И тоже, не следует его слишком большим ставить. Так, например ставят часто по 20 или даже 50 процессов. В этом нет никакого смысла, по опыту. 5-10 процессов — это потолок, даже в самых нагруженных серверах. Тем более если будете проводить комплексную оптимизацию и менять настройки остального софта.

ServerLimit и MaxClients — максимальное количество одновременных соединений. Если указать их слишком большим, то при атаке или большом трафике есть риск, что апач ляжет пытаясь принять много соединений, но не успевая их обработать. И нужно понимать, что такое одновременные соединения. Это значит что пользователи одновременно в одну и ту же секунду нажали ссылку. 256 соединений могут образовать примерно 1-2 тысячи человек, находящихся на сайте онлайн. Таким образом, если ваш потолок трафика 10к в сутки — то никаким образом вы не упрётесь в эти ограничения — на апач будет лишь 10-20 одновременных подключений.
MaxRequestsPerChild — этот параметр задает максимальное количество запросов, обработанных каждым процессом, прежде чем оный будет перезапущен (уничтожен). Это означает, что ваше приложение с меньшей вероятностью может зависнуть или сожрать память. Процессы всегда «свежие», в которых наверняка нет каких-либо зависших запросов.

Настройка и оптимизация mysql или mariadb под нагрузку и производительность

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

Конфигурация mysql обычно где-то в /etc/my.cnf (centos) или /etc/mysql/my.cnf (deb).

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

query_cache_size=256M
query_cache_limit=8M
join_buffer_size = 8M
tmp_table_size =256M
max_heap_table_size =64M
thread_cache_size=16
table_open_cache= 4000
max_connections=50
max_allowed_packet=300M

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

query_cache_size и query_cache_limit — это первое что нужно включить. Это объем кэша запросов. От его объема зависит эффективность работы, примерно так же как и с opcache — малый объем памяти не позволяет кэшировать все запросы, которые можно.

join_buffer_size — джоины — это наиболее сложные и ресурсоемкие операции. Поэтому под них часто недостаточно объема памяти по умолчанию. Из-за этого джоины могут выполняться гораздо дольше

tmp_table_size и max_heap_table_size — это тоже парные параметры, которые стоит использовать вместе. Объем временных таблиц.

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

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

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

Самый главный вопрос — какие значения в my.cnf указывать?

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

Утилита устанавливается аналогично всему остальному софту из репозиториев — yum install mysqltuner (centos) или apt-get install mysqltuner (deb, ubuntu). Она правда редко обновляется в репозиториях, и там версия менее функциональная, чем если поставить новую из исходников с гитхаба. Но на 98% вам будет достаточно и этой.

После чего запускается просто вызовом без параметров

mysqltuner

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

Иногда она выдаст сообщение о том, что не может подключиться к серверу. В этом случае с сервером mysql у вас всё плохо и он действительно лежит. Если данные для авторизации не прописаны в конфиге в домашней папке пользователя, то нужно указать данные логин пароль. Тут варианта два. Нужно либо указать при подключении логин пароль административного юзера, как правило root. Этот путь хорош, если вам пароль известен, либо вы его можете посмотреть. К примеру, в ISPmanager 5 можно его увидеть в панели, вот так:

Либо, если у вас нету ispmanager, можно подсмотреть логин-пароль в файлике /root/.my.cnf (обратите внимание на точку, это скрытый файл):

cat /root/.my.cnf

Выдаст нечто подобное:

Правда тут есть одно «но». Если у вас этот файлик есть, то mysqltuner просто отработает и всё.

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

Как пользоваться mysqltuner, что означает его вывод?

А мы продолжаем тюнить mysql.

Утилита выдаст что-то вроде такого:

Вывод делится на два раздела. Это статистика работы и рекомендации. Причем с указанием конкретных параметров и пороговых значений. Расписывать всю интерпретацию вывода это очень муторно, и еще сложней объяснить как этим всем пользоваться. Но суть такова, что в первой части вывода есть пункты, напротив которых не стоит статус «ОК». Это не всегда проблема, некоторые из пунктов часто даже не решить, например «[!!] Temporary tables created on disk» — он обычно будет вылазить снова и снова, сколько бы вы не увеличивали tmp_table_size. Тем не менее, если на вашем сервере настройки по-умолчанию, там будут другие параметры, и рекомендации, которые дадут существенную прибавку к производительности. В частности, включение кэша запросов (помните да, что кэширование — это самая эффективная оптимизация? здесь тоже!). Также и буферы, пулы. В общем, в самом низу вам выведется список параметров и пороговых значений. Сделайте как там указано. После чего понадобится рестарт mysql:

systemctl restart mariadb #(centos 7)

/etc/init.d/mysqld restart #старые системы и дебиан

service mysqld restart #новые deb — ubuntu

Но может и не сработать, ибо могут быть и другие варианты перезапуска, тут зависит от вашей OS и варианта СУБД — mysql или mariadb.

Итак, после этого можно запустить повторно mysqltuner, чтобы проверить эффект. Увидеть вывод. Причем, лучше подождать, или хотябы немного покликать по своим сайтам на этом сервере, бд которых вы и оптимизируете. И обычно там… будут еще какие-то рекомендации ��

Часто будут просить еще увеличить что-то, а могут и появиться новые параметры. Дальше повторяем процедуру с их изменением, рестартом mysql и повторным запуском тюнера после «прогрева» базы. Это может повторяться и 5, и 10, и даже 20 раз, особенно при отсутствии опыта и… каком нибудь перфекционизме �� Не стоит зацикливаться на буфере под временные таблицы, например. Обычно можно ставить его сразу побольше 1-2 гб — и больше не обращать внимания. Но вот, innod_buffer_pool и query_cache_size — это вещи довольно важные, и их за несколько итераций следует привести к статусу «ОК». В идеале это может выглядеть примерно так:

Проблемы при оптимизации mysql

Иногда ( а при отсутствии опыта чаще всего �� ), вы можете столкнуться с проблемами при попытке оптимизировать mysql. Например, mysql может отказаться перезапускаться, и показать что-то вроде fail.

В этом случае нужно срочно что-то делать, ибо ваши сайты отдают ошибку что не могут подключиться к БД ��

Бэкапьте конфиги перед любой настройкой!

Поэтому, всегда(!) делайте бэкапы конфигов ПЕРЕД ЛЮБЫМ В НИХ ВМЕШАТЕЛЬСТВОМ! Это касается не только mysql, а вообще любых манипуляций описанных в данной статье. Лучше всего сделать бэкап всех конфигов, а они лежат в папке /etc/ , как вы могли заметить, если были внимательны. Бэкап можно сделать например так:

rsync -avh /etc/ /root/etc_backup_before_tuning/

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

К примеру так:

cp /root/etc_backup_before_tuning/mysql/my.cnf /etc/mysql/my.cnf

Именно в таком виде, только проблемный конфиг, ни в коем случае НЕ обратным откатом всех файлов!

Другой вариант:

cp /etc/mysql/my.cnf /etc/mysql/my.cnf_orig

И откат:

cp /etc/mysql/my.cnf_orig /etc/mysql/my.cnf

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

Как решать проблемы?

Всего одно слово. Л-О-Г-И. Нужно смотреть логи. Это относится к любому софту и к любым проблемам. Там есть всё. Даже в тех редких случаях, когда там ничего нет, скорей всего просто не там смотрите �� Логи нужно читать внимательно. Ошибки там обычно видно. Любая ошибка в 98% случаев гуглится и решается. Другой вопрос насколько это может быть легко и быстро. Я вот показывал скрины о фейле при рестарте mysql. Это реальная ситуация, я пишу эту статью, и для того чтобы всё это показать вам на практике — я делаю оптимизацию mysql на сервере, где работает вот этот сайт. Итак, допустим, у меня не запустился mysql. Я иду читать лог. В ubuntu у меня лог mysql где-то в /var/log/mysql/error.log. Он может быть и чуть в другом месте, но чаще всего именно в /var/log/

Открываю лог, и вижу, что mysql не может запуститься, потому что не хватает памяти под пул innodb. Я задал его в 360 мегабайт, ибо в рекомендациях мне показывало что данные сейчас имеют объем в 340. По-хорошему, нужно бы делать мегабайт 512, но у меня на этом vps всего 1gb памяти, поэтому я сделал 360, с минимальным запасом. И то, я получил ошибку при рестарте, что все равно не хватает. Я иду и уменьшаю до 256, тогда все запускается. Но 256 это не оптимальное значение. Я знаю, что у меня большая часть памяти занята обработкой php, и он просто берет памяти обычно больше чем надо. Если я его рестартану, то часть памяти он высвободит, и скорей всего mysql запустится сразу после этого нормально даже с пулом в 360 мегабайт. Так и происходит �� А хватит ли потом памяти для PHP, резонный вопрос?) Я думаю хватит, ядро линукс очень хитрая и мощная штука, оно разрулит.

Кроме этого, я запустил mysqltuner еще раз, и увидел такую картину, на которой я сразу же нарисую решение:

Нужно обращать внимание на сообщение:

*** MySQL’s maximum memory usage is dangerously high ***
*** Add RAM before increasing MySQL buffer variables ***

Особенно если памяти на сервере мало. Мало — это 1-2 гб. Если у вас там 8 и более, то иногда бывает небходимо задрать настройки mysql такб что оно будет выдавать этот алерт, но при большом количестве памяти на него можно забивать. Чем больше памяти — тем меньше вероятности что её не хватит, даже если вы там выделили для буферов mysql в 2-3 раза больше чем её есть в системе. Но в моём случае это обязательно нужно решить, если я не хочу чтобы у меня начал падать mysql. Тут он почти со 100% вероятностью будет падать, если этого не сделать. Самое простое решение уменьшить максимально разрешенный объем — уменьшить количество возможных одновременных подключений — max_connections. По-умолчанию оно может быть слишком велико, и пропорционально этому растет разрешенный объем памяти. 151 — это обычно и есть значение по умолчанию. А тюнер показывает мне, что используется всего 2. Я уменьшаю до 50, думаю это с большим запасом, но при этом практически в 2-3 раза сократится максимальный объем выделенной памяти. Так и вышло.

После этого я сделал еще 2-3 итерации с изменением параметров и запуском mysqltuner. И только тогда у меня показало то, что выше там есть как пример близкой к идеалу настройки. Но то было как раз при снятии статистики на «холодную», пока буферы и кэши еще не заполнились. Через полчаса работы mysql без рестартов это выглядит так:

Это почти всё было о бэкенде, о том, что влияет на время ответа сервера. Эти все вещи подходят для абсолютно любых сайтов, хоть статейных-информационных, хоть для сервисов, хоть для интернет-магазинов. Далее речь пойдёт только о том, что можно использовать только для простых сайтов — статейников, информационных и дорвеев, конечно. Причем, на любых CMS и доргенах ��

Кэширование Nginx — 100% решение проблем с любой нагрузкой и временем отклика

Но это не точно, не 100%. Обычно… на 1000% и более. Можно вообще всё вышеописанное пустить побоку и ничего не делать — включить одно лишь только кэширование в nginx, причем можно только для самых нагруженных сайтов. И это мало того что ускорит время отклика чуть ли не в 10 и более раз, но еще и снимет 80% нагрузки с сервера, если таковая имеется.

Всё довольно просто:

Этот «шедевр изобразительного искусства» я рисовал для другой статьи об ускорении сайтов. Механика такова, что nginx очень быстро обрабатывает входящие запросы. Просто неебически неимоверно быстро! Он способен отдать любую страницу из своего кэша за 0,1-0,2 секунды (100-200 ms) . А если еще и железо быстрое — то он это может и за 0,06 сек. делать. Как-то так:

Как то поспорили мы со Спартанцем, широко известным в узких кругах человеком, который разрабатывает всякий разный софт для нужд дорвейщиков. Речь была о его плагине для wordpress c лаконичным названием d. Плагин интересный, позволяет неплохо разогнать wordpress, отключить кучу функционала, который может быть «лишним». Но он не решает одной очевидной проблемы — он не может работать без бэкенда. Ему в любом случае необходим PHP, а значит apache, а значит всё так же подвержен тормозам при сверхнагрузках.

В общем, так или иначе доспорились мы с ним до того что стали меряться письками выяснять чьё кунг-фу круче — его плагин или кэширование nginx, которое настраиваю я. И произвели тесты. Вот замеры с тех тестов, там использовался дефолтный wordpress с несколькими страницами:

632 ms — это нормальное время отклика для дефолтного wordpress. Иногда можно разогнать до 300, но в среднем 0,5-1 сек.

Кэширование nginx ускорило его вот так:

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

Итак, кэширование nginx для wordpress реализуется примерно таким конфигом:

Самый важный параметр, который надо понимать в этом конфиге — это fastcgi_cache_valid. Он задает срок жизни кэша. Тут указан 1 час. Это означает, что все изменения на сайте будут появляться не позднее, чем через час после того как они сделаны. От срока жизни зависит эффективность работы кэширования. Очевидно — что чем меньше срок жизни, тем чаще будут запросы на бэкенд поступать, тем больше нагрузка и чаще будут отдаваться страницы не из кэша, а значит время отклика в среднем дольше. Но для очень часто обновляемых сайтов по-другому никак — например новостники, там бывает нужно обновлять контент каждые 10 минут. Соответственно это значение и нужно менять на 10m. Если же у вас сайт чуть ли не статический, например дорвей — то можно ставить срок жизни хоть месяц — работать со временем будет только лучше. С другой стороны, чем больше посещаемость ресурса — тем эффективней кэширование даже при малом сроке жизни. Т.е. представьте себе на очень посещаемом сайте 100 запросов в минуту с откликом по 1 секунде. Это очень пригружает сервер. Если же вы кэшируете хотя бы на 10 минут — то в течение этих 10 минут 1000 гипотетических запросов практически не создадут никакой нагрузки на apache и mysql, кроме первого запроса, т.н. «холодного старта» — пока страница еще не в кэше.

Здесь кэширование для связки nginx+php-fpm. Для apache соответственно fastcgi_ нужно изменить на proxy_
Это нужно включить в конфигурацию сайта. Можно и просто вписать, а можно добавить в отдельный файл, и включить в нужный сайт с помощью include, как я обычно делаю сам и рекомендую делать. Это нужно включать до каких либо location в конфиге. Примерно так:

Кроме этого, нужно описать сам кэш в /etc/nginx/nginx.conf такой директивой:

fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=one:10m max_size=1024m inactive=1h;

Это нужно добавить в блок http. И снова надо помнить, что для apache директива должна быть proxy_cache_path. Это все что касается настройки.
Как проверить что кэширование работает? Очевидно по времени отклика. Если все работает — сайт будет летать. Но есть и другие способы.
Можно добавить директиву:

add_header X-Cache $upstream_cache_status;

Как обычно, после любых изменений конфигов нужно делать /etc/init.d/nginx restart

У вас в заголовках ответа после этого должен появиться статус кэширования, который может принимать три основных значения. MISS, HIT, BYPASS:

Статус HIT — означает что страница выдана из кэша. Время отклика будет у нее максимально быстрым. Противоположный статус — MISS, означает, что это «холодный старт» и страницы еще нету в кэше. После обновления этой страницы он должен смениться на HIT. Если не меняется — значит что-то либо не так делаете, либо вам этот конфиг не подходит. Такое тоже бывает, что нужна отладка, менять какие-то директивы, ибо какие-то другие настройки вебсервера могут мешать работе кэшера.

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

И ещё один способ — можно посмотреть файлы в папке кэша.

Эта команда означает «найти только файлы в папке /var/cache/nginx/ и подсчитать их количество». Если количество не 0 — значит как минимум что-то уже работает ��

Этот способ ускорения и защиты от атак используется у известного всем сервиса cloudflare. Есть так же менее популярные решения типа айри.рф — однако странно, что у них в зависимости от тарифа меняется некий коэффициент ускорения �� Впрочем, мне доподлинно неизвестно какие технологии используют они, но подозреваю, что всё то же самое, что я тут и описал, плюс CDN. Но в CDN обычно нет необходимости, если всё это настроено. Они предлагают оптимизировать даже интернет-магазины, а я утверждаю что кэширование Nginx плохо подходит для интернет-магазинов. Но и остальных возможностей бывает достаточно для оптимизации и сокращения времени ответа сайта.

Очистка кэша Nginx

Иногда бывает и такая необходимость. Например при смене дизайна, и необходимости сразу же увидеть изменения. Тут можно использовать тот же самый метод с удалением только файлов, чтобы nginx’y не пришлось заново создавать структуру папок в кэше.

find /var/cache/nginx/ -type f -delete

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

find /var/cache/nginx/ -type f |xargs grep site.com|xargs rm -f

Вместо site.com нужно указать свой домен, конечно.

Вот теперь, пожалуй, всё… что мне известно на данный момент об оптимизации серверов в максимально сжатой форме ��

Разумеется, всё я это писал, прежде всего, не по доброте душевной. А в расчёте на то, что кому-то понадобится просто заказать оптимизацию сервера под нагрузку или сократить время ответа сервера �� Но гайд полностью рабочий, если есть время и желание, разумеется любой может по нему настроить свой сервер. Рождал я его чуть ли не неделю. Ну как, неделю. Непрерывного времени я думаю потратил часов 8-10. Пост претерпел 39 редакций.

Стоимость и сроки оптимизации сервера

  1. Настройка сайта в режиме php-fpm — 2000 руб. (для известных CMS. Для самописов или каких-то малоизвестных CMS может быть дороже — от 3000 руб, ибо требует более сложной настройки и отладки)
  2. Настройка кэширования Nginx — 2000 руб. (Аналогично. Для сервисов и интернет магазинов хотя и возможно (дороже), но крайне не рекомендуется, оно может работать некорректно)
  3. Установка и настройка акселератора PHP — opcache, xcache — 2000 руб.
  4. Оптимизация настроек mysql — 2000 руб.
  5. Оптимизация настроек apache, установка nginx — под нагрузку, или наоборот под меньшее потребление ресурсов — 2000 руб.

На этом собственно исчерпываются потенциальные возможности по тюнингу под сайты. На сервере обычно больше нечего настраивать. Однако, не всегда есть необходимость настраивать это всё. Если вы не знаете что именно нужно настроить — я обычно предлагаю предварительный аудит сервера. В рамках которого я могу исследовать настройки, протестировать время отклика сайтов, выявить узкие места и определить возможности для оптимизации. После чего всю инфу выдаю в виде отчёта — что, где, и почему тормозит, и как это можно улучшить и ускорить. Такой аудит стоит 2000 руб, в том случае, если больше никаких работ не требуется, или вы будете заказывать их не у меня. В случае, если вам нужен только аудит — он будет стоить 4000 руб.

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

Комплексная оптимизация сервера стоит 5000 рублей. В неё входит настройка — nginx, apache, mysql и акселератора PHP. И это обычно гораздо выгоднее, чем брать отдельными опциями из прайса выше.

Сюда не включено кэширование Nginx, ибо оно идёт отдельной опцией, и стоимость его неизменна. При необходимости оно просто добавляется к стоимости комплекса работ.

Также и перевод на php-fpm обсуждается отдельно. Может быть включено в стоимость комплексной оптимизации только если у вас сайт на wordpress.

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

Кроме этого, также напомню, что я здесь не ускоряю сайт на 100 баллов по Google Pagespeed. Я ускоряю ответ сервера. А как оно повлияет (или не повлияет) на оценку гугла — это уже другой вопрос.

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

Срок выполнения работ — примерно 2-3 часа, с момента, как я приступил к задаче. То есть всё будет готово обычно в тот же день. Но последнее время всё реже бывает что я могу приступить сразу же, ибо бывает очередь из заказов. Тогда я говорю день, в который я смогу заняться вашими задачами.

Ну вот, с коммерческой частью тоже вроде всё.

Вопросы и консультации — в комментах. Или по контактам. Желаю вам быстрых сайтов и не «греющихся» серверов!

10 лучших способов ускорить загрузку сайта

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

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

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

1. Оптимизируйте HTML-код и CSS-, JS-файлы

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

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

  • Удалить лишние символы, элементы разметки и теги исходного кода. Автоматизировать процесс поможет добавление небольшой вставки в начало и конец HTML-кода сайта.

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

  • Сгруппировать однотипные CSS-файлы и JS-файлы. Объединить элементы помогут бесплатные PHP-приложения, вроде JCH Optimize, Cloudflare или Minify, которые копируются в отдельную директорию и пропускают через себя все файлы сайта.
  • 2. Уберите лишние HTTP-запросы

    Выгрузка элементов страницы (JavaScript, изображений, CSS- и флеш-файлов) занимает львиную долю ресурсов системы при загрузке сайта. HTTP-запросы к таким элементам заметно тормозят работу сайта.

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

    Сделать это можно несколькими способами:

    • Комбинировать нескольких изображений в один графический файл (CSS-спрайт);
    • Использовать встроенные изображения (Inline-картинки) в таблице стилей страницы;
    • Несколько CSS-файлов или скриптов на одной странице объединить в один файл;
    • Минимизировать число скриптов и плагинов.

    3. Расположите JavaScript и CSS в нужном порядке

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

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

    4. Уменьшите число внешних скриптов

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

    Конечно, упор на локальные скрипты создаст определённые ограничения во внешнем виде и функциональности сайта. Но полученное преимущество в скорости загрузки стоит этих «жертв».

    5. Задействуйте функцию flush

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

    Размещать функцию flush лучше в начале исходного кода страницы, сразу за head. Из заголовка HTML-контент будет открываться быстрее, к тому же так можно включить параллельную загрузку элементов CSS и JavaScript.

    6. Кэшируйте страницы

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

    Подключить кэширование можно путём добавления в HTML-код заголовка expires. Сайты на WordPress легко кэшируются с помощью установки плагинов с бесплатным или частично бесплатным функционалом, вроде W3 Total Cache, Cache Enabler или Zen Cach.

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

    7. Пользуйтесь CDN

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

    Сеть доставки и дистрибуции контента делает информацию доступнее для людей по всему миру

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

    Популярные сети доставки контента (CDN)

    8. Оптимизируйте графику и видео

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

    Рекомендуемые форматы под разный веб-контент

    • SVG – для векторных логотипов и несложных элементов интерфейса;
    • PNG – для схем и не векторных логотипов;
    • JPG – для фото и изображений;
    • MPEG4 – для видео и анимации.

    Также для видео и анимации доступен еще относительно новый формат WEBM. В большинстве случаев он обеспечивает меньший размер видео при аналогичном качестве. Однако, формат имеет ограниченную поддержку браузерами (например, нет поддержки в браузере MacOS/iOS Safari). Поэтому рекомендуется приоритетным источником видео использовать файл в формате WEBM, а альтернативным – установить MPEG4. Также можно использовать только MPEG4, если совместно использование недопустимо или неудобно.

    Отдельно отметим, что векторный формат (SVG) позволяет осуществлять масштабирование без потерь качества графики.

    Этапы оптимизации изображений

    Шаг 1 – Уменьшение размера изображения.

    Во многих популярных CMS, таких как WordPress или Joomla есть встроенные плагины для оптимизации изображений из оригинала. Но такой способ создаёт дополнительную нагрузку и может замедлить сайт. При каждой загрузке страницы браузер сперва обращается к исходнику, а только затем меняет размеры изображения «на лету».

    Избежать потерь скорости при загрузке изображений помогут встроенные в ОС графические редакторы, вроде Preview (Mac) или Microsoft Paint (Windows), а также онлайн-сервисы с похожим функционалом. Для работы с ними потребуются минимальные навыки работы с графикой.

    Шаг 2 – Сжатие файла перед загрузкой.

    Даже после оптимизации размеров изображения, его «вес» обычно ещё далёк от оптимального. Уменьшить размер без потери качества картинки помогают такие удобные и бесплатные сервисы, как ImageResize или TinyPNG. Большинство процессов здесь автоматизировано. Пользователю нужно только залить файлы и скачать уже ужатые до оптимального размера изображения.

    9. Примените Gzip-сжатие файлов

    Gzip-сжатие файлов, производится для того, чтобы уменьшить количество запросов на сервер с браузера. Проще говоря, эта технология уменьшает исходный вес файлов до 70% для ускорения загрузки.

    Способы внедрения Gzip-сжатия

    • Добавить следующий фрагмент кода в конфигурационный файл веб-сервера «.htaccess».
    • Добавить следующий отрывок кода в начало HTML- или PHP-страницы. Он проверяет поддерживается ли gzip-сжатие файлов браузером. Если поддерживается – использует его.
    • Инсталлировать на сайт Gzip-плагин. Например, W3 Total Cache для сайтов на WordPress.

    10. Сменить хостинг

    Самый радикальный метод ускорения загрузки – смена хостинг-провайдера. Экономия на размещении ресурса часто приводит к значительному ухудшению качества услуг, что подрывает все попытки ускорить сайт на корню.

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

    Вывод

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

    Ищите надёжную площадку для размещения сайта? Веб-хостинг от Eternalhost – надёжный фундамент, который обеспечит быструю и бесперебойную работу интернет-ресурса!

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

    Ускорение WordPress — 18 советов по оптимизации сайта

    WordPress – отличная CMS для сайта, но она довольно медленная из коробки, если ее не оптимизировать правильно. В этом руководстве, составленном KeyCDN, мы рассмотрим основные способы оптимизации и ускорения сайта на WordPress.

    WordPress также одна из самых популярных CMS для сайтов компаний. Более половины сайтов, на которых можно определить систему управления контентом, работают на WordPress. А это более чем 74 миллиона сайтов.

    По данным W3Techs, WordPress используется на 60% сайтов с известной CMS. Это 31,6% всех сайтов в мире.

    Инструменты для измерения скорости сайта

    Один из самых важных инструментов при работе над оптимизацией скорости сайта — тестировщики скорости загрузки (page speed tool). Мы рекомендуем проводить измерения перед началом работ по оптимизации, и в процессе, после каждого внесенного изменения. Это даст лучшее понимание, изменения каких параметров оказывают положительное или отрицательное влияние на производительность.

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

    Важность скорости работы сайта в 2020 году

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

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

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

    Сервис Google Impact calculator позволяет оценить примерный уровень роста годового оборота в зависимости от скорости загрузки сайта.

    Например, если вы ускорите загрузку сайта с 2,2 секунд до 1,4 секунд, при трафике 200 000 уников в месяц, среднем чеке $50 и конверсии 3%, вы можете получить дополнительно $146 000 годового дохода.

    Техники ускорения WordPress, актуальные в 2020 году

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

    1.Выбор качественной темы/фреймворка

    Каждый сайт на WordPress сделан на основе какой-то темы или фреймворка-пейджбилдера. Они обычно содержат много лишнего избыточного функционала. У разработчиков тем разные подходы к созданию своих продуктов, и поэтому темы для WordPress значительно отличаются друг от друга. Например, дефолтные темы WordPress типа Twenty Seventeen обычно сделаны довольно качественно и работают быстро.

    Нужно очень тщательно выбирать темы для покупки на маркетплейсах типа ThemeForest или Creative Market. Большинство тем там сделано довольно некачественно, потому что разработчики гонятся за универсальностью и пихают в тему все подряд. Это дает им больше продаж, но темы в итоге выходят тяжелыми и медленными. Зато с красивым интерфейсом покраски кнопок из админки. На таких площадках важнее найти адекватных разработчиков, и пользоваться их темами. Например, Total WordPress theme от ребят из WPExplorer неплохая тема. Имея довольно богатый функционал, сайт на ней, наполненный контентом, загружается в пределах 800 мс.

    Фреймворки Thesis Theme framework и Genesis тоже имеют хорошую репутацию, благодаря своей скорости и качеству кода.

    2. Настройка кэширования WordPress

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

    Кэширование на WordPress организуется с помощью плагинов, которые создают кэш страниц на сервере и в браузере клиента.

    Плагины кэширования WordPress

    Для кэширования сайта на WordPress чаще всего используются следующие плагины:

    • Cache Enabler
    • W3 Total Cache
    • WP Super Cache
    • WP Rocket

    Кэширование в браузере – включаем Expire Headers в WordPress

    Усилить эффект браузерного кэширования ресурсов можно с помощью технологии leverage browser caching, добавив заголовки expire. Они говорят браузеру, загружать конкретные файлы с сервера или взять их из кэша браузера. Это позволит уменьшить количество запросов к серверу. Некоторые кэширующие плагины WordPress позволяют включить expire headers в настройках, но эту функцию также можно активировать, добавив следующий код в файл .htaccess .

    Кэширование WordPress на сервере

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

    Предзагрузка (prefetch) популярных доменов

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

    Активировать прездагрузку (prefetch) в WordPress можно путем добавления следующего кода в файл header.php между тэгами и . Это неблокирующий загрузку страницы процесс, и он исполняется, когда есть возможность. Приведем некоторые примеры:

    Предварительная загрузка шрифтов Google

    Предварительная загрузка Google Code (jQuery)

    Предварительная загрузка Google Analytics

    Remove Query Strings – Удаляем строку запроса со статических ресурсов

    Эта настройка может дать положительный эффект, так как окончания файлов типа ?ver=4.7 могут привести к проблемам с кэшированием статики, особенно при использовании прокси и CDN. Удалить Query Strings в WordPress можно несколькими способами.

    • Внести следующие изменения в файл functions.php – вставить функцию, которая удалит query strings.
    • Если вы используете кэширующий плагин типа W3 Total Cache, для удаления query strings в нем может быть соответствующая настройка.
    • Существуют специальные плагины для WordPress, основная функция которых заключается в удалении query strings, такие как Query Strings Remover и Remove Query Strings From Static Resources.

    3. Подключение CDN (Content Delivery Network)

    Использование CDN может принести пользу любому сайту, независимо от его размера и количества посетителей. Content Delivery Network загружает статические файлы вашего сайта (CSS, Javascript, изображения) с ближайшего к пользователю сервера, снижая время загрузки сайта. Кроме скорости, использование CDN положительным образом влияет на пользовательский опыт посетителей сайта, снижает показатель отказов, увеличивает время, проведенное на сайте, конверсию и даже SEO.

    Для использования CDN на WordPress существуют специальные плагины, как правило, провайдер CDN разрабатывает плагин под свою сеть, например, KeyCDN или Селектел.

    Загружайте через CDN все, что можно

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

    На примере ниже можно видеть, как 100% статики грузятся с CDN

    Граватары также можно грузить с CDN.

    4. Оптимизация базы данных WordPress

    Если не оптимизировать базу данных, WordPress может начать работать медленнее. Среди способов оптимизации БД WordPress удаление и ограничение или отключение редакций записей, удаление старых ревизий, и соблюдение ограничения на 100 страниц в WordPress.

    Отключение и лимит ревизий постов WordPress

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

    Для решения этой проблемы можно ограничить количество сохраняемых ревизий или вообще отключить их.

    Отключение редакций постов WordPress

    Для того, чтобы отключить создание редакций записей в WordPress, достаточно добавить следующий код в файл wp-config.php . Он изменит интервал автосохранения записей с 60 секунд до 5 минут и отключит создание ревизий. По умолчанию останется только одна предыдущая редакция записи.

    Если вы не хотите ковыряться в коде, можно сделать то же самое с помощью бесплатного плагина Disable Post Revision.

    Ограничение количества редакций записей в WordPress

    Для того, чтобы ограничить количество редакций записей в WordPress, достаточно добавить следующий код в файл wp-config.php . Он изменит интервал автосохранения записей с 60 секунд до 5 минут и установит количество сохраняемых редакций до трех. Можно задать количество ревизий любым числом.

    Удаление старых редакций записей из базы данных WordPress

    После отключения или ограничения количества редакций нужно почистить базу данных от старых сохраненных ревизий. Для этой цели можно временно установить плагин WP-Optimize.

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

    Следите за ограничением на 100 страниц в WordPress

    При планировании структуры сайта стоит помнить о том, что WordPress не был предназначен для работы с большим количеством страниц, больше 100. При наличии большого количества страниц на сайте в админке начнутся тормоза из-за нехватки памяти. Впрочем, на фронтенде это никак не отразится. Упоминание об этом ограничении есть в документации WordPress.

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

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

    5. Оптимизация изображений с помощью сжатия

    На современных сайтах в среднем 56% веса страниц составляют изображения. Следовательно, оптимизация изображения и их сжатие должны быть приоритетной задачей при ускорении сайта на WordPress.

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

    6. Сжатие Gzip/Brotli

    Gzip это еще одна технология сжатия, которая используется для сжатия страниц, стилей и скриптов на уровне сервера перед отправкой браузеру. Проверить, работает ли сжатие Gzip на сайте WordPress можно с помощью сервиса Check GZIP Compression.

    GZIP позволяет сохранить от 50 до 80% трафика, тем самым значительно ускорив скорость загрузки сайта. – Check GZIP compression

    Apache

    Настроить сжатие на сервере Apache можно, добавив следующий код в файл .htaccess

    Nginx

    Если вы используете веб-сервер Nginx, сжатие активируется путем включения следующих инструкций в файл настроек nginx.conf .

    Кроме этого, можно также внедрить технологию сжатия Brotli на WordPress. Brotli это новый алгоритм сжатия, разработанный Google. Brotli показывает значительное преимущество перед Gzip при сжатии файлов.

    7. Уменьшение количества плагинов WordPress

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

    Есть плагины, которые позволяют оценить степень влияния установленных плагинов на скорость работы сайта, но они устарели и не поддерживаются разработчиками. Это плагины P3 Plugin Performance Profiler и WP Performance Profiler

    При установке новых плагинов на сайт с WordPress следует обратить внимание на дату последнего обновления плагина и на совместимость с текущей версией WordPress. Если плагин давно не обновлялся, вы увидите следующее предупреждение:

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

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

    8. Оптимизация производительности веб-шрифтов

    По данным исследований, в 2020 году 57% сайтов используют не стандартные шрифты, это рост на 850% по сравнению с 2011 годом. Очень важно использовать только те шрифты, которые нужны, в форматах WOFF и WOFF2. Сервисы типа Typekit base64 преобразуют шрифты во все возможные форматы, замедляя тем самым скорость загрузки сайта.

    По результатам тестов, шрифты Google показывают хороший уровень производительности, потому что используют CDN для загрузки и предоставляются только в форматах WOFF. Open Sans — самый быстрый из 10 популярных шрифтов.

    Важно также помнить о разнице между шрифтами Google и безопасными веб шрифтами, она может достигать 200 мс. Это преимущественно из-за скорости загрузки и дополнительных HTTP запросов к серверам Google.

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

    Можно пойти еще дальше и поместить все шрифты в отдельный css файл и хранить их в localStorage. Браузерный кэш сбрасывается довольно часто, особенно на мобильных устройствах. А сохраняя файлы в localStorage, можно хранить их у пользователя постоянно. Smashing Magazine сэкономили 700 мс при загрузке страницы с помощью localStorage.

    Рекомендуем использовать сервис localFont tool от Jaime Caballero. Можно перетащить свой шрифт в окно и конвертировать его в CSS и Javascript для размещения на сайте WordPress.

    9. Оптимизация иконок Font Awesome

    Если вы используете Font Awesome, можно ускорить их загрузку, поместив файлы на CDN. Если вы используете тему WordPress с Font Awesome, ее придется немного доработать.

    Хранение Font Awesome на своей CDN уменьшит количество запросов к серверу и поисков DNS.

    10. Lazy Load для изображений, видео и Disqus

    Lazy loading – это технология загрузки объекта только в тот момент, когда он нужен. В случае WordPress это означает, что элемент не загружается до тех пор, пока пользователь не прокрутит страницу до него. Lazy load можно применить для любых элементов страницы, от изображений и видео, до блока комментариев Disqus.

    Отложенная загрузка изображений

    Для отложенной загрузки картинок на сайте WordPress можно использовать хороший бесплатный плагин BJ Lazy Load. Он заменяет все изображения, ярлыки и фреймы на странице плейсхолдерами и загружает контент по мере приближения его к границе окна при прокрутке пользователем. Это также работает и для текстовых виджетов. Если вы пользуетесь плагином WP Rocket, в нем есть настройки для включения Lazy Load.

    Отложенная загрузка видео

    Для отложенной загрузки видео на WordPress можно использовать бесплатный плагин Lazy Load for Videos. Он заменяет встроенное видео Youtube и Vimeo кликабельным изображением превью. Если у вас на сайте много видео, этот плагин поможет значительно улучшить скорость загрузки страниц.

    Отложенная загрузка Disqus

    Disqus – это очень удобная система комментирования, которая очень хорошо борется со спамом. Но стандартный плагин Disqus создает более 10 HTTP запросов, которые могут значительно замедлить загрузку страницы. Чтобы решить эту проблему, разработчик James Joel сделал плагин Disqus Conditional Load, который откладывает загрузку Disqus. Он в том числе не вредит SEO, то есть поисковые системы все равно могут индексировать комментарии.

    11. Минификация и объединение CSS и Javascript файлов

    Минификация и объединение файлов стилей и скриптов может сыграть значительную роль в ускорении сайта на WordPress.

    Минификация

    Минификация файлов означает удаление лишних символов из файлов HTML, Javascript, и CSS, таких как:

    • Пробелы
    • Переносы строки
    • Комментарии
    • Разделители блоков

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

    Объединение (конкатенация)

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

    Для минификации и конкатенации файлов в WordPress можно использовать плагины, например, WP Rocket

    Большинство плагинов кэширования для WordPress имеет настройку для включения этих функций, но можно также использовать отдельные плагины, такие как Better WordPress Minify и Autoptimize. Хорошей практикой в WordPress считается размещение файлов стилей вверху страницы, а файлов скриптов снизу.

    12. Уменьшение количества HTTP запросов

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

    Рассмотрим несколько важных способов по уменьшению количества запросов к серверу.

    Граватары

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

    Есть несколько способов решения этой проблемы.

    Вариант 1 — отключить граватары

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

    Для этого нужно установить бесплатный плагин WP User Avatar. И в настройках включить опцию «Отключить Граватары и использовать только локальные аватары»

    Вариант 2 – использовать Disqus

    Можно использовать комментарии Disqus вместе с плагином lazy load Disqus. Кажется странным, что подключать дополнительный плагин, скрипты, делать вызов к сторонним сервисам предпочтительнее использования родного функционала. Но если сравнить скорость на записи с 5 или более комментариями, окажется, что Disqus быстрее из-за меньшего количества HTTP запросов.

    Отключение Emoji

    С выходом WordPress 4.2 появилась поддержка Emoji. Это привело к добавлению лишнего скрипта wp-emoji-release.min.js?ver=4.3.1 в хедере. Этот скрипт создает дополнительный HTTP-запрос, от которго нужно избавиться, если вы не собираетесь использовать Emoji.

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

    В настройках «Написание» отключите “convert emoticons”.

    Вариант 1 – WordPress плагин

    Установите бесплатный плагин для WordPress “Disable Emojis” by Ryan Hellyer. Этот плагин отключает функционал emoji в WordPress 4.2.

    Вариант 2 – функция WordPress

    Чтобы не перегружать сайт лишними плагинами, можно избавиться от emoji путем добавления в functions.php следующего кода:

    Отключение скриптов на странице

    Обычно мы стараемся избавиться от лишних плагинов, но есть один плагин Gonzalez, который позволяет отключать неиспользуемые скрипты на уровне страницы или всего сайта. Например, плагин Contact Form 7 загружает свои скрипты на всех страницах сайта, а не только на той, где используются формы. То же самое с плагинами шаринга в соцсети. Отключив ненужные на данной странице скрипты, можно избавиться от нескольких лишних HTTP запросов. Плагин не бесплатный, но своих денег стоит.

    Отключаем Embeds

    С версии 4.4 в WordPress загружается новый скрипт wp-embed.min.js , который позволяет упростить вставку видео, изображений, твитов, и т.п. Например, WordPress автоматически преобразует URL в YouTube вставку и сделает превью в визуальном редакторе. Но не всем нужна подобная функция, можно просто скопировать готовый код для вставки с YouTube или Twitter. Проблема с этой функцией в том, что она загружает свой скрипт на каждой странице. Есть несколько способов избавиться от него.

    Вариант 1 – WordPress плагин

    Установите WordPress плагин “Disable Embeds” by Pascal Birchler. Он делает следующее:

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

    Вариант 2 – функция WordPress

    Можно добавить следующий код в файл functions.php, это отключит функцию вставки.

    Отключаем комментарии

    Независимо от того, используете вы или нет систему комментариев WordPress, скрипт comment-reply.min.js подключается на каждой странице сайта. Это не всегда оправдано, на сайте могут быть не нужны комментарии вообще или подключен Disqus. Тогда можно отключить этот ненужный скрипт.

    Для этого можно добавить следующий код в файл functions.php .

    13. Отключение хотлинков

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

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

    14. Отключение Pingback и Trackback

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

    Отключить pingback и trackback можно в настройках обсуждения. Это изменение коснется только новых записей.

    15. Задание размеров изображений

    Все видели похожие рекомендации при проверке скорости сайта Google Pagespeed:

    Optimization suggestion: “By compressing and adjusting the size of … you can save 5.8 KB (51%).”

    Эти рекомендации относятся к изображениям на сайте, которые масштабируются браузером. Например, если изображение имеет ширину 500 пикселей, а на странице помещено в колонку шириной 400 пикселей. В результате оно будет уменьшено до 400 пикс.

    Правильным решением будет подготовка изображений нужного размера в графическом редакторе перед загрузкой на сайт. Это сэкономит ресурсы сервера и будет соответствовать рекомендациям Google Pagespeed. Еще можно загрузить на сайт изображения в разных размерах для разных устройств.

    16. Решение проблемы медленной загрузки admin-ajax.php

    В WordPress 3.6 бал представлен WordPress Heartbeat API, который позволил WordPress общаться с сервером и браузером. Это улучшило управление сессиями, контроль ревизий и автосохранение.

    WordPress Heartbeat API использует admin-ajax.php для AJAX запросов из браузера. Это может привести к повышенной нагрузке на процессор и большому количеству вызовов PHP. Например, если оставить открытой страницу с админкой, она будет посылать POST запросы к этому файлу постоянно с заданным интервалом.

    Существует бесплатный плагин Heartbeat control, который позволяет задать частоту обращений WordPress heartbeat API.

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

    Таким образом можно вычислить, какой плагин выполняет запрос. В этом примере это был плагин соцсетей, для которого не было включено кэширование. Как только кэширование плагина активировали, постоянные обращения к admin-ajax.php прекратились.

    17. Настройка MySQL сервера

    Оптимизация работы сервера баз данных MySQL также очень важна для быстрой работы сайта на WordPress. Настройки MySQL в большой степени зависят от конфигурации серверного окружения на вашем хостинге, поэтому нет универсальных рекомендаций по оптимизации MySQL. Обычно настройки MySQL/MariaDB находятся в файле /etc/my.cnf . Вот несколько параметров, на значение которых стоит обратить внимание:

    • tmp_table_size
    • query_cache_type
    • query_cache_size
    • query_cache_size
    • join_buffer_size
    • max_heap_table_size

    Очень полезный инструмент — скрипт MySQL Tuner. Он делает обзор производительности сервера и дает некоторые базовые рекомендации по возможной оптимизации. Вот еще несколько инструментов, которые могут пригодиться при настройке MySQL:

    18. Выбор качественного хостинга для WordPress

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

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

    Как уменьшить время загрузки страницы сайта: оптимизация на примере проекта Superbalist

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

    Нажав кнопку «Принять и продолжить», вы соглашаетесь с Политики конфиденциальности

    Мы запустили рейтинг зарплат интернет-маркетологов! Прими участие в анонимном опросе.

    How-to – Читать 5 минут – 24 апреля 2020

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

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

    Еще одним популярным инструментом сокращения кода скриптов считается Closure Complier от Google. Интерфейс сервиса состоит из двух вертикальных полей. Вставлять код JS нужно в левое поле:

    Оптимизировать JavaScript с целью сокращения его размера можно вручную и с помощью онлайн-инструментов. Каждая манипуляция по сжатию должна сопровождаться параллельной проверкой страниц сайта.

    После удаления пробелов, комментариев, лишних строк замените обычные переменные на их сокращенные версии. Оптимизация кода JS для сайтов на WordРress и других СMS может проводиться с помощью встроенных плагинов.

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

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

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

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

    • – 47% интернет-пользователей хотят, чтобы веб-страницы загружались в течение двух секунд;
    • – 40% пользователей покинут страницу, если время ее загрузки превысит три секунды;
    • – 52% интернет-покупателей говорят о том, что склонны больше доверять веб-сайтам с быстрой загрузкой.

    Но это только начало. Исследование Akamai и Gomez показывает, что 79% пользователей никогда не вернутся на сайт, у которого возникают проблемы с загрузкой. Более того, 44% этих пользователей поделятся негативными впечатлениями со своими друзьями и порекомендуют им держаться подальше от этого сайта. Таким образом, можно потерять не только фактических посетителей сайта, но и потенциальных.

    В исследовании также приводятся данные о том, что у сайтов, загружающихся за 3 секунды, на 22% меньше просмотров страниц, на 50% выше показатель отказов и почти на 22% ниже конверсия по сравнению с теми, продолжительность загрузки которых составляет не больше секунды. Если ваш сайт загружается за 5 секунд, статистика будет еще более удручающей: просмотров страниц будет меньше на 35%, показатель отказов превысит 105%, а уровень конверсии снизится на 38%.

    Некоторые эксперты пошли дальше и проанализировали так называемое терпимое время ожидания пользователями загрузки страниц сайта. Например, отчет Strange Loop демонстрирует, что в пиковые периоды трафика более 75% онлайн-покупателей предпочтут перейти на сайт конкурента, чем томиться в ожидании загрузки. Тем не менее, отчет содержит несколько советов, позволяющих дольше удерживать внимание посетителей сайта. К примеру, наличие прогресс-бара, индикатора выполнения процессов может побудить пользователей оставаться на вашем сайте до 38 секунд.

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

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

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

    По данным специалистов Yahoo 80% времени уходит на загрузку различных компонентов страницы, включая таблицы стилей, изображения, скрипты, flash-анимацию и т. д. Помните, что для каждого из этих компонентов требуется отдельный HTTP-запрос. Следовательно, чем больше подобных элементов на странице, тем дольше будет происходить ее полная загрузка.

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

    • – Использовать меньшее количество элементов на каждой странице.
    • – Заменить изображения на CSS-свойства там, где это возможно.
    • – Объединить несколько CSS-элементов.
    • – Сократить скрипты или убрать их там, где это возможно.

      Снизьте количество плагинов

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

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

      Уменьшите размер страниц

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

      Для того чтобы снизить вес страниц без ущерба для качества контента, используется метод сжатия. В процессе сжатия уменьшается размер каждого файла, тем самым сокращается время HTTP- отклика. Распространенным методом для эффективного сжатия страниц сайта является GZip. Кроме того, большинство современных браузеров поддерживают GZip-сжатие! Статистика Yahoo показывает, что этот прием позволяет увеличить время загрузки на 70%.

      Включите кэширование браузером

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

      Тенни Тойрер (Tenni Theurer), ранее сотрудничавший с Yahoo, поясняет, что кэширование может уменьшить время загрузки сайта до 40%. Это связано с тем, что большинство элементов страницы, как правило, уже сохранены браузером пользователя, поэтому при последующих посещениях остается подгрузить лишь малую часть.

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

      Для картинок важны три фактора: размер, формат и атрибут src.

      Размер изображения

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

      Формат изображения

      Всегда используйте формат JPEG там, где это возможно. Поскольку такие картинки легче, они быстрее отображаются браузером. Изображения в формате PNG тоже хороши, но могут не поддерживаться старыми браузерами. Что касается расширения GIF, то его лучше использовать только для небольших по размеру картинок, в случае с простой графикой или для анимированных изображений. Рекомендуем избегать таких форматов, как BMP и TIFF.

      Атрибут src

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

      Сократите редиректы

      Автоматическая переадресация или редирект с кодом 301 – это стандартный способ изменения структуры сайта без потери рейтинга в поисковой системе. Однако редиректы также замедляют работу сайта, генерируя ненужные HTTP-запросы к серверу, так как браузер вынужден сначала обратиться к старому адресу и затем перейти к новому.

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

      Используйте сеть доставки контента (CDN)

      Если ваш сайт крайне популярен, и вы опасаетесь, что применение других вышеперечисленных стратегий может негативно сказаться на потоке трафика и конверсии, вам необходимо обратить внимание на CDN. Использование различных CDN, как например CloudFront, CacheFront или MaxCDN сродни тому, что вы перекладываете все заботы по доставке контента на другие плечи, чтобы сконцентрироваться на более насущных вопросах. Веб-серверы CDN доставляют контент в зависимости от местоположения пользователя. Чем ближе к пользователю расположен сервер, тем быстрее будет загружаться сайт.

      Заключение

      Ни одна компания не должна терять трафик и упускать конверсию из-за проблем с загрузкой сайта. Проверьте скорость загрузки с помощью Google Web Analytics или плагина Google Analytics от Yoast для WordPress и подберите для себя оптимальный способ, который поможет уменьшить время загрузки сайта.

      Топ-пост этого месяца:  МИТ его знает, как набить кошелек на многоканальной добыче трафика
    Добавить комментарий