Comments 19
Ну статику конечно можно и нужно пожать 1 раз и раздавать. Но есть же и динамический контент. Например html, созданный шаблонами. Конечно можно и его жать сразу в шаблонизаторе, но есть такой подход.
Как какойнить дженкинс будет обрабатывать динамически создаваемый контент и складывать на сервер?
Или же у вас css зависит от того какой пришел запрос?
Есть статика, как, наверное, у любого сайта. Они собирается webpack. Сами html страницы генерятся при запросе с помощью шаблонов, в проекте о котором и шла в частности используется ejs. Можно конечно заморочиться и сделать так, чтобы после шаблонизатора получался уже минифицированный ответ. Но там есть нюансы и на мой вкус лучше обрабатывать уже полностью собранный ответ. Кеш конечно используется — я ставлю перед node-приложением nginx. Вообще эта библиотека не обязательно должна использоваться для минификации чего-то. Она просто позволяет хукнуть ответ так, чтобы было полное тело и что то можно сделать с ним перед отправкой. Можно, например, вместо webpack собирать бандлы прям на приложении при запросе, а потом кешировать их уже на проксире. Конечно тут куча сложностей и в большинстве случаев так делать не надо, но я вполне могу представить себе кейс где бы это было хорошо. Ну например код после какого-либо конструктора сайта. Или же нужно менять то, что генерит какая-нибудь 3rd-либа без возможности влезть в нее. Или же у вас есть кеча inline-стилей, которые можно собрать во внешний бандл. Естественно я решал не каждодневную задачу — она не стоит перед всеми, раз нет в стандартной реализации. В общем я решал проблему, не нашел удобного мне способа в стандартной реализации, навелосипедил и решил выложить в opensource. Может быть кому-нибудь поможет когда-нибудь. Естественно нужно думать головой когда и как ее использовать, чтобы было лучше, а не хуже.
Когда используешь PageSpeed для статистики сайта то он вроде кешируешь на какое-то время — сразу после внесения изменений не видит их. Как это решено через их API? На что он ориентируется для кеша?
Но нужно учитывать, что не все ответы можно отдавать 3-ей стороне. Бывает содержатся и приватные данные. Конечно их можно выдрать и отправлять отдельным запросом.
Например, я воспользовался данной библиотекой для того, чтобы после после конструктора сайта, создающего довольно трешовый код, выдерать inline-стили и потом оптимизировать их. Что-то уникальное часто руками приходится писать.
В общем любая проблема решается 100500 способами и каждый разработчик должен сам думать. А наличие большого разнообразия возможностей для решения — это хорошо.
Относительно неплохо срабатывание не просто минимизация html, но и включение внешних javascript/css файлов непосредственно в страницу, сборка нескольких файлов в бандлы, оптимизация картинок и т.д. Более подробно лучше посмотреть в их документации.
А наличие большого разнообразия возможностей для решения — это хорошо.
Несомненно данное решение имеет право на жизнь. Модель middleware, встроенного в собственное приложение позволяет работать в любом окружении, где бы приложение не запускалось.
Моя мысль заключается в том, что подобная оптимизация для серьезного продукта более уместна вне приложения, а именно настройками окружения.
Посмотрите например www.npmjs.com/package/compression
Cжатый html — это еще и плюс для SEO
Можете предоставить ссылку на пруф, что именно сжатый HTML влияет на СЕО?
Где указано, что влияет именно HTML без лишних пробелов и кавычек, а не просто более оптимальный HTML без лишних тегов или более правильный семантически.
Кроме того, одно другому не мешает, а дополняет: можно сначала пожать код, а потом gzip использовать.
Давайте проведем эксперимент. Возьмем довольно большую страницу, например habr.com/post/425351 и сожмем ее по разному:
- Исходный размер HTML: 582KB
- Размер после html-minifier: 543KB (-7%)
- Размер после html-minifier и gzip: 78KB (-87%)
- Размер после одного gzip: 81KB (-86%)
Т.е. при условии, что HTML сжимается с помощь gzip, минификация дает крайне минимальный эффект (1% всего) — вот это я и называю «экономия на спичках».
Лучше процессорное время потратить на обработку другого запроса, чем минифицировать HTML (а тем более JSON)
я ставлю перед node приложением кеширующий проксер (nginx например)
Это, безусловно, правильное решение.
Можете предоставить ссылку на пруф, что именно сжатый HTML влияет на СЕО?
Где указано, что влияет именно HTML без лишних пробелов и кавычек, а не просто более оптимальный HTML без лишних тегов или более правильный семантически.
Не было такого утверждения. Было написано
Cжатый html — это еще и плюс для SEO.
Не раскрывалось в чем плюс.
… минифицировать HTML (а тем более JSON)
Где здесь минифицируется JSON??
Лучше процессорное время потратить на обработку другого запроса
И это лично ваше мнение. Очень сильно зависит от нагрузки и целей. Я думаю каждый разработчик сам должен принимать решение.
Т.е. при условии, что HTML сжимается с помощь gzip, минификация дает крайне минимальный эффект (1% всего) — вот это я и называю «экономия на спичках».
Опять все зависит от ситуации. Может кто-то хочет уместить ответ в минимальное количество tcp пакетов и 1% может повлиять на результат.
Вообще здесь приведены абстрактные решения в вакууме для демонстрации функциональности. Например, я воспользовался данной библиотекой для того, чтобы после после конструктора сайта, создающего довольно трешовый код, выдерать inline-стили и потом оптимизировать их. Естественно нужно думать головой когда и как что использовать, чтобы было лучше, а не хуже. Каждый разработчик принимает решение в зависимости от многих критериев для свое ситуации. И я считаю, что лишний инструмент, расширяющий возможности — это хорошо.
Node.JS: библиотека для модификации http ответов