Практическое руководство по Ruby on Rails
Я разрабатываю клон Твиттера как личный проект, и уже реализовав примерно 80% функционала, я решил попробовать некоторую оптимизацию сайта, так как он сильно ориентирован на краткий контент.
При этом я наткнулся на одну возможность улучшить его с помощью инструментов разработчика Chrome, а именно Lighthouse, который, для тех, кто не знает,
Автоматизированный инструмент с открытым исходным кодом для повышения производительности, качества и корректности ваших веб-приложений. (…) Lighthouse запускает множество тестов страницы, а затем создает отчет о том, насколько хорошо страница работает. — Маяк
Прежде чем углубляться в детали, позвольте мне рассказать о достигнутом прогрессе.
С самого начала скорость не была ужасной — и, как вы можете видеть из фрагмента самого отчета, приложение все еще находится на ранней стадии с точки зрения дизайна — в конце концов я добился двукратного улучшения как в First Contentful Paint (FCP), так и в Largest Contentful Paint (LCP).
- FCP — это время, которое требуется вашей странице, чтобы перейти от чистого листа к показу чего-либо вообще.
- LCP — это время, которое требуется вашей странице для загрузки самого большого фрагмента контента.
Google рекомендует FCP до 1,8 секунды и LCP до 2,5 секунды, поэтому это улучшение дает нам хороший старт.
Теперь, как я достиг этих результатов?
Lighthouse дает представление о том, на чем вы можете сосредоточить свое внимание, чтобы улучшить свою производительность, и в моем случае это были рекомендации:
Между этими двумя возможностями уже выделяется одна — сжатие текста.
Это намекает на то, что сжатие текста не включено в Rails по умолчанию, поэтому вам нужно настроить его вручную.
Часть волшебства Rails заключается в компонентах, с которыми он поставляется, и мы можем использовать Rack и его промежуточные слои, которые позволяют нам перехватывать, изменять и передавать запросы.
ДобавивRack::Deflater
, мы можем сжать страницу более чем на 80 % с помощью одной строки кода.
Как это работает?
Прежде чем прыгнуть прямо, не понимая, что он делает, вот краткое объяснение того, что происходит за кулисами:
Используя промежуточное программное обеспечение, Rack Deflater использует Zlib::GzipWriter
, который сжимает тело веб-страницы перед ответом на запрос. Получив ответ от сервера, клиент распознает заголовок Content-Encoding=gzip
и распаковывает страницу перед ее рендерингом.
Поскольку Rack Deflate уже поставляется вместе со Rack, вам не нужно ничего дополнительно. Просто добавьте эту строку в свой файл config/application.rb
, и все готово.
# config/application.rb config.middleware.insert_after ActionDispatch::Static, Rack::Deflater
Если вы будете искать вокруг, вы столкнетесь с этим предложением кода. config.middleware.use Rack::Deflater
. Однако это не оптимальное решение. Почему?
Потому что, если у вас есть статические ресурсы, обслуживаемые в вашем приложении Rails, они обрабатываются промежуточным программным обеспечением theActionDispatch::Static
.
Более того, если вы используете последнюю версию Rails, которая поддерживает доставку файлов GZip непосредственно с диска, некоторые из файлов могут быть уже заархивированы, поэтому, помещая Rack::Deflater
после ActionDispatch::Static
, вы избегаете избыточных попыток сжатия.
Внедрение этого быстрого и простого решения может повысить производительность вашего приложения Rails, приблизив вас к достижению более высоких скоростей загрузки.