Ну да, это удобно. А какие есть ограничения? Сколько запросов максимум? Платно\бесплатно?
Когда используешь PageSpeed для статистики сайта то он вроде кешируешь на какое-то время — сразу после внесения изменений не видит их. Как это решено через их API? На что он ориентируется для кеша?
Но нужно учитывать, что не все ответы можно отдавать 3-ей стороне. Бывает содержатся и приватные данные. Конечно их можно выдрать и отправлять отдельным запросом.
Например, я воспользовался данной библиотекой для того, чтобы после после конструктора сайта, создающего довольно трешовый код, выдерать inline-стили и потом оптимизировать их. Что-то уникальное часто руками приходится писать.
В общем любая проблема решается 100500 способами и каждый разработчик должен сам думать. А наличие большого разнообразия возможностей для решения — это хорошо.
Можете предоставить ссылку на пруф, что именно сжатый HTML влияет на СЕО?
Где указано, что влияет именно HTML без лишних пробелов и кавычек, а не просто более оптимальный HTML без лишних тегов или более правильный семантически.
Не было такого утверждения. Было написано
Cжатый html — это еще и плюс для SEO.
Не раскрывалось в чем плюс.
… минифицировать HTML (а тем более JSON)
Где здесь минифицируется JSON??
Лучше процессорное время потратить на обработку другого запроса
И это лично ваше мнение. Очень сильно зависит от нагрузки и целей. Я думаю каждый разработчик сам должен принимать решение.
Т.е. при условии, что HTML сжимается с помощь gzip, минификация дает крайне минимальный эффект (1% всего) — вот это я и называю «экономия на спичках».
Опять все зависит от ситуации. Может кто-то хочет уместить ответ в минимальное количество tcp пакетов и 1% может повлиять на результат.
Вообще здесь приведены абстрактные решения в вакууме для демонстрации функциональности. Например, я воспользовался данной библиотекой для того, чтобы после после конструктора сайта, создающего довольно трешовый код, выдерать inline-стили и потом оптимизировать их. Естественно нужно думать головой когда и как что использовать, чтобы было лучше, а не хуже. Каждый разработчик принимает решение в зависимости от многих критериев для свое ситуации. И я считаю, что лишний инструмент, расширяющий возможности — это хорошо.
Есть статика, как, наверное, у любого сайта. Они собирается webpack. Сами html страницы генерятся при запросе с помощью шаблонов, в проекте о котором и шла в частности используется ejs. Можно конечно заморочиться и сделать так, чтобы после шаблонизатора получался уже минифицированный ответ. Но там есть нюансы и на мой вкус лучше обрабатывать уже полностью собранный ответ. Кеш конечно используется — я ставлю перед node-приложением nginx. Вообще эта библиотека не обязательно должна использоваться для минификации чего-то. Она просто позволяет хукнуть ответ так, чтобы было полное тело и что то можно сделать с ним перед отправкой. Можно, например, вместо webpack собирать бандлы прям на приложении при запросе, а потом кешировать их уже на проксире. Конечно тут куча сложностей и в большинстве случаев так делать не надо, но я вполне могу представить себе кейс где бы это было хорошо. Ну например код после какого-либо конструктора сайта. Или же нужно менять то, что генерит какая-нибудь 3rd-либа без возможности влезть в нее. Или же у вас есть кеча inline-стилей, которые можно собрать во внешний бандл. Естественно я решал не каждодневную задачу — она не стоит перед всеми, раз нет в стандартной реализации. В общем я решал проблему, не нашел удобного мне способа в стандартной реализации, навелосипедил и решил выложить в opensource. Может быть кому-нибудь поможет когда-нибудь. Естественно нужно думать головой когда и как ее использовать, чтобы было лучше, а не хуже.
Открыл уже давно — есть такие проекты у меня. Но считаю, что не серебрянная пуля и не панацея. Нужно исходить и задач и кейса. Обычно эти 3-х буквенные сокращения идут рядом с реактивностью, а она не всегда бывает нужна. Кроме того, не все серверные рендеры дают минифицированный html.
«Экономия на спичках» дает в некоторых ситуациях сжатие до 10%.Cжатый html — это еще и плюс для SEO. Кроме того, одно другому не мешает, а дополняет: можно сначала пожать код, а потом gzip использовать. Я кстати так и делаю. Только я ставлю перед node приложением кеширующий проксер (nginx например), который и gzip-ает ответ клиенту. Кавычки из JSON не удаляются, а то это будет уже невалидный json)
Ну статику конечно можно и нужно пожать 1 раз и раздавать. Но есть же и динамический контент. Например html, созданный шаблонами. Конечно можно и его жать сразу в шаблонизаторе, но есть такой подход.
Когда используешь PageSpeed для статистики сайта то он вроде кешируешь на какое-то время — сразу после внесения изменений не видит их. Как это решено через их API? На что он ориентируется для кеша?
Но нужно учитывать, что не все ответы можно отдавать 3-ей стороне. Бывает содержатся и приватные данные. Конечно их можно выдрать и отправлять отдельным запросом.
Например, я воспользовался данной библиотекой для того, чтобы после после конструктора сайта, создающего довольно трешовый код, выдерать inline-стили и потом оптимизировать их. Что-то уникальное часто руками приходится писать.
В общем любая проблема решается 100500 способами и каждый разработчик должен сам думать. А наличие большого разнообразия возможностей для решения — это хорошо.
Не было такого утверждения. Было написано
Не раскрывалось в чем плюс.
Где здесь минифицируется JSON??
И это лично ваше мнение. Очень сильно зависит от нагрузки и целей. Я думаю каждый разработчик сам должен принимать решение.
Опять все зависит от ситуации. Может кто-то хочет уместить ответ в минимальное количество tcp пакетов и 1% может повлиять на результат.
Вообще здесь приведены абстрактные решения в вакууме для демонстрации функциональности. Например, я воспользовался данной библиотекой для того, чтобы после после конструктора сайта, создающего довольно трешовый код, выдерать inline-стили и потом оптимизировать их. Естественно нужно думать головой когда и как что использовать, чтобы было лучше, а не хуже. Каждый разработчик принимает решение в зависимости от многих критериев для свое ситуации. И я считаю, что лишний инструмент, расширяющий возможности — это хорошо.
Есть статика, как, наверное, у любого сайта. Они собирается webpack. Сами html страницы генерятся при запросе с помощью шаблонов, в проекте о котором и шла в частности используется ejs. Можно конечно заморочиться и сделать так, чтобы после шаблонизатора получался уже минифицированный ответ. Но там есть нюансы и на мой вкус лучше обрабатывать уже полностью собранный ответ. Кеш конечно используется — я ставлю перед node-приложением nginx. Вообще эта библиотека не обязательно должна использоваться для минификации чего-то. Она просто позволяет хукнуть ответ так, чтобы было полное тело и что то можно сделать с ним перед отправкой. Можно, например, вместо webpack собирать бандлы прям на приложении при запросе, а потом кешировать их уже на проксире. Конечно тут куча сложностей и в большинстве случаев так делать не надо, но я вполне могу представить себе кейс где бы это было хорошо. Ну например код после какого-либо конструктора сайта. Или же нужно менять то, что генерит какая-нибудь 3rd-либа без возможности влезть в нее. Или же у вас есть кеча inline-стилей, которые можно собрать во внешний бандл. Естественно я решал не каждодневную задачу — она не стоит перед всеми, раз нет в стандартной реализации. В общем я решал проблему, не нашел удобного мне способа в стандартной реализации, навелосипедил и решил выложить в opensource. Может быть кому-нибудь поможет когда-нибудь. Естественно нужно думать головой когда и как ее использовать, чтобы было лучше, а не хуже.
Как какойнить дженкинс будет обрабатывать динамически создаваемый контент и складывать на сервер?
Ну статику конечно можно и нужно пожать 1 раз и раздавать. Но есть же и динамический контент. Например html, созданный шаблонами. Конечно можно и его жать сразу в шаблонизаторе, но есть такой подход.