Комментарии 34
Классная штука. Жаль, что пока только для Drupal.
хотелось бы такой для WP увидеть
уже в процессе разработки
Да там полно похожего. Я б сказал проблема найти кошерный.
Да и сам WP нативно умеет сжимать и отдавать. А data:uri к нему прикрутить — пол часа.
Да и сам WP нативно умеет сжимать и отдавать. А data:uri к нему прикрутить — пол часа.
я не торопясь больше года делал (ну конечно не целыми днями), а вы полчаса говорите :), есть много разных исключительных ситуаций
Исключительные ситуации связаны с IE? — ну его нафиг, я лично тем ССЗБ что пользуются IE еще бы и своп в придачу досылал.
не только, правильно разобрать CSS и потом правильно его собрать
а чем просто замена содержимого url() плоха?
как минимум тем что надо выносить data:uri в отдельный файл + проводить там оптимизацию по склеиванию правил с одинаковыми картинками, иначе при повторении ссылки на изображение она будет вставлена столько раз, сколько раз встречается в css
не понимаю зачем нужен отдельный файл. А по поводу повторений — я вам по секрету скажу — gzip эти проблемы успешно решает :)
> не понимаю зачем нужен отдельный файл
тут есть описания принципов duris.ru/articles/, там вообще история развития, надеюсь вам поможет понять глубже архитектуру
> файл. А по поводу повторений — я вам по секрету скажу — gzip эти проблемы успешно решает :)
это вы прочитали где-то? или сами проверяли?
тут есть описания принципов duris.ru/articles/, там вообще история развития, надеюсь вам поможет понять глубже архитектуру
> файл. А по поводу повторений — я вам по секрету скажу — gzip эти проблемы успешно решает :)
это вы прочитали где-то? или сами проверяли?
А подумать? Вы бы еще пихнули в LZ бинарник :)
Алгоритм очень хорошо ужимает рядом расположенные одинаковые блоки.
Для адекватного примера
исходный сжатый css
с кучей дублей
разница в размере исходных файлов в 3.5 раза а архивов меньше чем на 10%
Алгоритм очень хорошо ужимает рядом расположенные одинаковые блоки.
Для адекватного примера
исходный сжатый css
с кучей дублей
разница в размере исходных файлов в 3.5 раза а архивов меньше чем на 10%
и как я понимаю сервис duris.ru тоже Ваш. Можно сделать выбор, оптимизировать основной css-файл или нет. Сводить все классы в одну строку это просто жесть. Потом хрен разберешься
Я вам по секрету скажу — объединяйте запросы. Должно быть в идеале запросов
1. текст ужатой страницы, включающей мелкую графику
2. ужатый стиль, с data:uri для background-ов
3. ужатый объединенный JS
далее большие картинки, потом уже не важные запросы из JS, включая аналитику, подзагрузка изображений и так далее…
По логу «оптимизированного» сайта видно много мелких запросов — это не порядок.
Про кэширование не буду распространятся, но имхо финт ушами с отложенным заполнением кэша нужен когда нужно долго и нудно отрабатывать какой-то сложный алгоритм. Но ведь что сжатие, что упаковка картинок в base64 — достаточно быстрые операции.
ну и на последок — правильное кэширование должно привести к отдаче статики
1. текст ужатой страницы, включающей мелкую графику
2. ужатый стиль, с data:uri для background-ов
3. ужатый объединенный JS
далее большие картинки, потом уже не важные запросы из JS, включая аналитику, подзагрузка изображений и так далее…
По логу «оптимизированного» сайта видно много мелких запросов — это не порядок.
Про кэширование не буду распространятся, но имхо финт ушами с отложенным заполнением кэша нужен когда нужно долго и нудно отрабатывать какой-то сложный алгоритм. Но ведь что сжатие, что упаковка картинок в base64 — достаточно быстрые операции.
ну и на последок — правильное кэширование должно привести к отдаче статики
ну так и делается, за исключением текст HTML страниц не сжимается, в этом есть определенные технические трудности для CMS. В логах оптимизированного сайта — это загрузках обычных img, которые пока не оптимизируются, вообщем там и так запросов в раза меньше, а вообще обычно в 3-4 и больше, зависит от качества шаблона.
финт с отложенным заполнением кеша нужен именно потому что там долгий и нудный алгоритм разбора css и его последующей оптимизации, base64 это только цветочки.
с кешированием так и есть, отдается статика.
финт с отложенным заполнением кеша нужен именно потому что там долгий и нудный алгоритм разбора css и его последующей оптимизации, base64 это только цветочки.
с кешированием так и есть, отдается статика.
в чем трудности с сжатием HTML?
мелкие img должны попадать в html как data:uri, крупные — желательны быть в ссылках и докачиваться по загрузке
прямо зависымых запросов со страницы должно быть не больше 8 :)
насчет нудного алгоритма — можно чуть подробнее сказать что и зачем?
мелкие img должны попадать в html как data:uri, крупные — желательны быть в ссылках и докачиваться по загрузке
прямо зависымых запросов со страницы должно быть не больше 8 :)
насчет нудного алгоритма — можно чуть подробнее сказать что и зачем?
трудности с HTML в том что контент собирается из БД динамически в отличии от стилей и скриптов. Конечно можно сделать оптимизацию перед отдачей уже собранной версии, но тогда надо заботится про очистку при изменениях текста в каком либо месте страницы.
img картинками пока не занимался из-за того что есть трудности с HTML.
повторюсь алгоритм анализа и компоновки css не тривиальный как кажется на первый взгляд. нужно import обработать, base учесть, filter, прочее, прочее…
+ периодически находятся какие-то ранее неучтенные моменты или просто улучшение оптимизации, в случае с сервисом обновление все получают автоматически.
img картинками пока не занимался из-за того что есть трудности с HTML.
повторюсь алгоритм анализа и компоновки css не тривиальный как кажется на первый взгляд. нужно import обработать, base учесть, filter, прочее, прочее…
+ периодически находятся какие-то ранее неучтенные моменты или просто улучшение оптимизации, в случае с сервисом обновление все получают автоматически.
нету трудностей с HTML — пользуйтесь буферезированным выводом, точнее его перехватом.
понятно :) ну балуйтесь дальше
понятно :) ну балуйтесь дальше
> нету трудностей с HTML
вы утверждаете как-будто собаку съели на этом.
вы не внимательно прочитали, проблема не так в отборе данных, как в их обновлении, и это сделать тоже можно — но нужно простое красивое решение, причем не под конкретную cms, а универсальное.
а так сжать HTML никаких проблем, гляньте к примеру в исходный код ide.hivext.ru
вы утверждаете как-будто собаку съели на этом.
вы не внимательно прочитали, проблема не так в отборе данных, как в их обновлении, и это сделать тоже можно — но нужно простое красивое решение, причем не под конкретную cms, а универсальное.
а так сжать HTML никаких проблем, гляньте к примеру в исходный код ide.hivext.ru
С учетом того что нет универсального способа хранить и компоновать контент, то решение будет cms зависимым.
Сабаку может и не сьел, но на хлеб с маслом хватает :)
Вообще я зашел в эту статью ибо я как раз предоставляю такой сервис как клиентскую оптимизацию сайта. И имхо это находится по другую сторону от универсальных велосипедов. Практически любую технологию саму по себе применять бесполезно — важен комплексный подход который уменьшает количество запросов через инкапсуляцию графики и сборку скриптов и стилей, плюс хорошее кэширование для быстроты ответа и итоговое сжатие для уменьшение влияния увеличения тогового размера. Если интересно тут в цифрах
Сабаку может и не сьел, но на хлеб с маслом хватает :)
Вообще я зашел в эту статью ибо я как раз предоставляю такой сервис как клиентскую оптимизацию сайта. И имхо это находится по другую сторону от универсальных велосипедов. Практически любую технологию саму по себе применять бесполезно — важен комплексный подход который уменьшает количество запросов через инкапсуляцию графики и сборку скриптов и стилей, плюс хорошее кэширование для быстроты ответа и итоговое сжатие для уменьшение влияния увеличения тогового размера. Если интересно тут в цифрах
без обид, но вам было бы полезно сначала глубже вникать в суть темы, а потом делать выводы. я бы сказал что велосипед как раз таки создается с вашей стороны ибо уже давно есть разработки мотоциклы такие как www.webogroup.com/ и www.aptimize.com/.
Постараюсь разжевать мысль — в данной статье основная в организации оптимизации как внешнего сервиса. А о принципах и подходах непосредственно оптимизации стилей, скриптов, и изображений уже давно все выяснено. Скажу вам по секрету и из своего опыта нет одной универсальной формулы, но есть универсальный набор формул, перемешиванием которых можно добиться оптимального результата.
И не нашел на вашем сайте где можно попробовать в реальности ваш оптимизатор.
Постараюсь разжевать мысль — в данной статье основная в организации оптимизации как внешнего сервиса. А о принципах и подходах непосредственно оптимизации стилей, скриптов, и изображений уже давно все выяснено. Скажу вам по секрету и из своего опыта нет одной универсальной формулы, но есть универсальный набор формул, перемешиванием которых можно добиться оптимального результата.
И не нашел на вашем сайте где можно попробовать в реальности ваш оптимизатор.
Вы хоть раз смотрели в них более менее оптимизированные сайты?
Извените, но эти сервисы будут работать только для какого замученного плагинами сайта на WP :) Некоторые советы очень условны, а некоторые просто вредны.
Мысль Вы явно не донесли.
Я не делаю инструмент — их и без меня полно. Я предоставляю сервис :)
Извените, но эти сервисы будут работать только для какого замученного плагинами сайта на WP :) Некоторые советы очень условны, а некоторые просто вредны.
Мысль Вы явно не донесли.
Я не делаю инструмент — их и без меня полно. Я предоставляю сервис :)
интересно знать что такое сервис клиентской оптимизации в вашем исполнении?
блин, ну «вручную» он оптимизирует
ЗЫ надо упомянуть о предварительной оптимизации картинок через www.smushit.com/ysmush.it/, а то бывает понасоздают спрайтов и data:uri с избыточной инфой
ЗЫ надо упомянуть о предварительной оптимизации картинок через www.smushit.com/ysmush.it/, а то бывает понасоздают спрайтов и data:uri с избыточной инфой
согласен, бывают пишут всякую хрень не разобравшись — duris.ru/ смотрим галочку — оптимизировать изображения Smush.it™
Долго будет работать (нагружая сервера сервиса). И WEBO Site SpeedUp все равно по технологии на голову впереди DURIS, тут конкурировать бесполезно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Клиентская оптимизация как сервис