Клиентская оптимизация как сервис

[@Sytrus]

Классная штука. Жаль, что пока только для Drupal.

[@mdss]

хотелось бы такой для WP увидеть

[@heruvim]

уже в процессе разработки

[@Wott]

Да там полно похожего. Я б сказал проблема найти кошерный.
Да и сам WP нативно умеет сжимать и отдавать. А data:uri к нему прикрутить — пол часа.

[@heruvim]

я не торопясь больше года делал (ну конечно не целыми днями), а вы полчаса говорите :), есть много разных исключительных ситуаций

[@Wott]

Исключительные ситуации связаны с IE? — ну его нафиг, я лично тем ССЗБ что пользуются IE еще бы и своп в придачу досылал.

[@heruvim]

не только, правильно разобрать CSS и потом правильно его собрать

[@Wott]

а чем просто замена содержимого url() плоха?

[@heruvim]

как минимум тем что надо выносить data:uri в отдельный файл + проводить там оптимизацию по склеиванию правил с одинаковыми картинками, иначе при повторении ссылки на изображение она будет вставлена столько раз, сколько раз встречается в css

[@Wott]

не понимаю зачем нужен отдельный файл. А по поводу повторений — я вам по секрету скажу — gzip эти проблемы успешно решает :)

[@heruvim]

> не понимаю зачем нужен отдельный файл

тут есть описания принципов duris.ru/articles/, там вообще история развития, надеюсь вам поможет понять глубже архитектуру

> файл. А по поводу повторений — я вам по секрету скажу — gzip эти проблемы успешно решает :)

это вы прочитали где-то? или сами проверяли?

[@heruvim]

пример для сравнения

с дублями — 976k

без дублей — 163k

[@Wott]

А подумать? Вы бы еще пихнули в LZ бинарник :)
Алгоритм очень хорошо ужимает рядом расположенные одинаковые блоки.

Для адекватного примера

исходный сжатый css
с кучей дублей

разница в размере исходных файлов в 3.5 раза а архивов меньше чем на 10%

[@heruvim]

вот именно думать надо :) рядом расположенные одинаковые блоки :)
как в вашем примере в реальности так не бывает, если кто и рядом ставит, тогда уже просто правила объединяют

[@Wott]

у меня другой опыт, но пусть вам будет виднее

[@mdss]

и как я понимаю сервис duris.ru тоже Ваш. Можно сделать выбор, оптимизировать основной css-файл или нет. Сводить все классы в одну строку это просто жесть. Потом хрен разберешься

[@heruvim]

да, скоро появится удобное дополнение к файлу оптимизатору, которое позволит гибко и удобно управлять настройками оптимизации. пока секрет как это будет реализовано, но уверен вам понравится. захотите и выключите там себе css компрессию.

[@Wott]

Я вам по секрету скажу — объединяйте запросы. Должно быть в идеале запросов
1. текст ужатой страницы, включающей мелкую графику
2. ужатый стиль, с data:uri для background-ов
3. ужатый объединенный JS
далее большие картинки, потом уже не важные запросы из JS, включая аналитику, подзагрузка изображений и так далее…

По логу «оптимизированного» сайта видно много мелких запросов — это не порядок.

Про кэширование не буду распространятся, но имхо финт ушами с отложенным заполнением кэша нужен когда нужно долго и нудно отрабатывать какой-то сложный алгоритм. Но ведь что сжатие, что упаковка картинок в base64 — достаточно быстрые операции.

ну и на последок — правильное кэширование должно привести к отдаче статики

[@heruvim]

ну так и делается, за исключением текст HTML страниц не сжимается, в этом есть определенные технические трудности для CMS. В логах оптимизированного сайта — это загрузках обычных img, которые пока не оптимизируются, вообщем там и так запросов в раза меньше, а вообще обычно в 3-4 и больше, зависит от качества шаблона.

финт с отложенным заполнением кеша нужен именно потому что там долгий и нудный алгоритм разбора css и его последующей оптимизации, base64 это только цветочки.

с кешированием так и есть, отдается статика.

[@Wott]

в чем трудности с сжатием HTML?

мелкие img должны попадать в html как data:uri, крупные — желательны быть в ссылках и докачиваться по загрузке

прямо зависымых запросов со страницы должно быть не больше 8 :)

насчет нудного алгоритма — можно чуть подробнее сказать что и зачем?

[@heruvim]

трудности с HTML в том что контент собирается из БД динамически в отличии от стилей и скриптов. Конечно можно сделать оптимизацию перед отдачей уже собранной версии, но тогда надо заботится про очистку при изменениях текста в каком либо месте страницы.

img картинками пока не занимался из-за того что есть трудности с HTML.

повторюсь алгоритм анализа и компоновки css не тривиальный как кажется на первый взгляд. нужно import обработать, base учесть, filter, прочее, прочее…

+ периодически находятся какие-то ранее неучтенные моменты или просто улучшение оптимизации, в случае с сервисом обновление все получают автоматически.

[@Wott]

нету трудностей с HTML — пользуйтесь буферезированным выводом, точнее его перехватом.

понятно :) ну балуйтесь дальше

[@heruvim]

> нету трудностей с HTML
вы утверждаете как-будто собаку съели на этом.
вы не внимательно прочитали, проблема не так в отборе данных, как в их обновлении, и это сделать тоже можно — но нужно простое красивое решение, причем не под конкретную cms, а универсальное.

а так сжать HTML никаких проблем, гляньте к примеру в исходный код ide.hivext.ru

[@Wott]

С учетом того что нет универсального способа хранить и компоновать контент, то решение будет cms зависимым.

Сабаку может и не сьел, но на хлеб с маслом хватает :)
Вообще я зашел в эту статью ибо я как раз предоставляю такой сервис как клиентскую оптимизацию сайта. И имхо это находится по другую сторону от универсальных велосипедов. Практически любую технологию саму по себе применять бесполезно — важен комплексный подход который уменьшает количество запросов через инкапсуляцию графики и сборку скриптов и стилей, плюс хорошее кэширование для быстроты ответа и итоговое сжатие для уменьшение влияния увеличения тогового размера. Если интересно тут в цифрах

[@heruvim]

без обид, но вам было бы полезно сначала глубже вникать в суть темы, а потом делать выводы. я бы сказал что велосипед как раз таки создается с вашей стороны ибо уже давно есть разработки мотоциклы такие как www.webogroup.com/ и www.aptimize.com/.

Постараюсь разжевать мысль — в данной статье основная в организации оптимизации как внешнего сервиса. А о принципах и подходах непосредственно оптимизации стилей, скриптов, и изображений уже давно все выяснено. Скажу вам по секрету и из своего опыта нет одной универсальной формулы, но есть универсальный набор формул, перемешиванием которых можно добиться оптимального результата.

И не нашел на вашем сайте где можно попробовать в реальности ваш оптимизатор.

[@Wott]

Вы хоть раз смотрели в них более менее оптимизированные сайты?
Извените, но эти сервисы будут работать только для какого замученного плагинами сайта на WP :) Некоторые советы очень условны, а некоторые просто вредны.

Мысль Вы явно не донесли.

Я не делаю инструмент — их и без меня полно. Я предоставляю сервис :)

[@heruvim]

интересно знать что такое сервис клиентской оптимизации в вашем исполнении?

[@Masterkey]

блин, ну «вручную» он оптимизирует

ЗЫ надо упомянуть о предварительной оптимизации картинок через www.smushit.com/ysmush.it/, а то бывает понасоздают спрайтов и data:uri с избыточной инфой

[@sirus]

согласен, бывают пишут всякую хрень не разобравшись — duris.ru/ смотрим галочку — оптимизировать изображения Smush.it™

[@Masterkey]

дурис тут непричем
кстати в нем надо побольше настроек, я его использую только для получения data:uri из кучи картинок/
в особенности меня возмущает это ограничение картинок до 10кб — откуда оно взялось, в ие8 ограничение до 32кб.

[@sunnybear]

Долго будет работать (нагружая сервера сервиса). И WEBO Site SpeedUp все равно по технологии на голову впереди DURIS, тут конкурировать бесполезно.

[@sunnybear]

а, черт, это же все ты :)

[@heruvim]

ну ну :), спасибо за хорошие слова

[@Masterkey]

… и сашлись титаны оптимизации на просторах хабры…