Практическое руководство по 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, приблизив вас к достижению более высоких скоростей загрузки.