Улучшение воспринимаемой производительности с помощью Pingdom и GTmetrix
Эта статья является частью серии по созданию приложения (блога с галереей) для оценки и оптимизации производительности. (Посмотреть демо).
В этой статье мы проанализируем наше приложение галереи и рассмотрим возможные пути дальнейшего увеличение его производительности.
Перед началом тестирования настройте Ngrok и канал для локального обслуживания приложения. Или разместите приложение на собственном демонстрационном сервере. Статический URL-адрес позволит протестировать приложение с помощью внешних инструментов, таких как GTmetrix и Pingdom Tools.
Мы просканировали сайт с помощью GTmetrix, чтобы увидеть его слабые места. Вкладка отчета PageSpeed содержит список рекомендаций от Google. Первый ее элемент относится к нашему приложению, которое выводит изображения случайным образом. Поэтому мы пропустим это предупреждение. Следующее, что мы можем сделать для повышения производительности сайта, это реализовать кэширование в браузере.
Кэширование в браузере
У нас есть файл main.css, для которого нужно установить заголовки Expires. То же самое необходимо сделать и для файлов изображений в галерее. Для этого можно использовать конфигурацию Nginx:
location ~* .(?:ico|css|js|gif|jpe?g|png)$ {
expires 14d;
}Мы можем просто поместить это в блок server и положиться на Nginx? Ну, не совсем. Он позаботится о статических файлах, но не об изображениях.
Для изображений у нас есть специальный контроллер, который генерирует их на лету. Поэтому лучше добавлять заголовки ответов через него. Для этого откроем файл /src/ImageController.php в приложении галереи и добавим код в serveImageAction(), прямо перед строкой return $response:
// кэшируем на 2 недели
$response->setSharedMaxAge(1209600);
// устанавливаем пользовательскую директиву Cache-Control
$response->headers->addCacheControlDirective('must-revalidate', true);Этот код добавит заголовки Cache-Control и Expires.
Symfony имеет более гибкие возможности для кэширования ответов, как описано здесь.
Перезапустив Nginx, мы повторно протестировали приложение в GTmetrix, и вот результат:
Сжатие
Далее GTmetrix выдал предупреждение о размере и сжатии используемых ресурсов:
Изображения можно сжать заранее. Но поскольку это динамические изображения, созданные с помощью Glide, мы не будем этого делать.
Фактически, Glide предоставляет способы установить качество изображения. Но иногда мы не будем использовать Glide для обработки изображений, поэтому сначала давайте попробуем другой подход.
Внутри блока Nginx server мы добавим пару строк, которые активируют сжатие контента на сервере Nginx сжимать контент:
gzip on;
gzip_disable "msie6";
gzip_vary on;
gzip_proxied any;
gzip_comp_level 9;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/jpeg;Каждый из этих параметров объясняется на сайте Nginx. Но нас интересует gzip_comp_level.
Общеизвестно, что сжатие является определенным компромиссом. Мы немного увеличиваем пропускную способность сети, уменьшая размер файлов. Но при этом тратим ресурсы ЦП сервера на включения и выключения ресурсов при каждом запросе.
Вот почему редко для gzip_comp_level задают максимальное значение 9. Но мы будем развертывать приложение на CDN. Что полностью снимет нагрузку с нашего сервера.
Кроме этого мы используем кэширование страниц. Поэтому сжатие каждого ресурса на сервере будет выполняться только один раз. Благодаря этому мы смогли повысить эффект от сжатия с помощью gzip:
Но не при сжатии изображений. Изучив документации Glide и выяснили, как контролировать качество изображений. Внутри serveImageAction() в разделе ImageController мы нашли строку:
$cachePath = $glide->getGlide()->makeImage($file, ['w' => $size]);Затем мы добавили аргумент, отвечающий за качество, ко второму аргументу массива makeImage():
$cachePath = $glide->getGlide()->makeImage($file, ['w' => $size, 'q' => 60]);
Затем мы удалили все изображения из папки /var/uploads/cache и провели повторный тест. Его результаты показали, что мы смогли получить улучшение на 5%:
При проверке сайта в Pingdom Tools он получил 100% баллов. Это на 8%, чем раньше:
Эти рекомендации являются полезными. Но их соблюдение было бы неэффективным, если бы время загрузки оставалось равным 4,21 секундам. Поэтому мы активировали кэширование Nginx. Благодаря чему время загрузки сократилось до 1 секунды:
Мы прилагаем HAR-файл этого теста.
Заключение
Некоторые из практик мы не рассмотрели в этой статье. Например, сжатие Brotli. Модуль Nginx для сжатия Brotli можно найти здесь.
Если вам известны другие средства, которые могут существенно повлиять на производительность приложения, расскажите о них в комментариях!