Comments 26
до дома дойду, потестирую ;)
Быстро развиваетесь! Спасибо!
Сколь пишет про этот скрипт — сколько я хочу его поставить, но как-то боюсь.
Кто-то пробовал ставить Web Optimizer на бесплатную CMS Etomite?
Кто-то пробовал ставить Web Optimizer на бесплатную CMS Etomite?
Когда выйдет что то типа — Web Optimizer Stable Version обязательно попробую!
:) попробовать можно и сейчас. Stable от текущей редакции будет отличаться только уровнем надежности. Если сейчас это 95-99%, то станет 99,99%. В общем случае абсолютно безразлично, ставить сейчас или подождать полгодика.
Вы знаете, шаблонизатор Quicky, который пиарили полгода назад, тоже заявлял о 95-процентной совместимости, я повелся, и что? Оказалось, что он совместим в разы меньше, чем мой собственный самописный шаблонизатор, на который я уж и надежды-то не возлагаю, а автора и след простыл. Так что подождать stable release это самое разумное, имхо.
я всё никак не могу понять, если у меня свой движок на ЗФ со своей архитектурой, я могу полноценно пользоваться этой штукой или она годится только для популярных движков?
По поводу джавы, лично мне кажется, что часть web-optimizer'а должна существовать в другом виде, а именно в виде ant-таксов. Запускать их, так сказать, deploy-time. Сюда можно отнести:
— CSS / JS files merging
— CSS Tidy / YUI Compressor (#) for CSS
— JSMin / Packer / YUI Compressor (#) for Javascript
— CSS Sprites
— data:URI (+ IE7- hacks)
— Image optimization (#)
GZIP, HtmlMinify — настройкой фильтров в web.xml — это уже runtime.
Кстати, нашлась реализация YUI compressor в виде Ant task
— CSS / JS files merging
— CSS Tidy / YUI Compressor (#) for CSS
— JSMin / Packer / YUI Compressor (#) for Javascript
— CSS Sprites
— data:URI (+ IE7- hacks)
— Image optimization (#)
GZIP, HtmlMinify — настройкой фильтров в web.xml — это уже runtime.
Кстати, нашлась реализация YUI compressor в виде Ant task
в принципе, если сервер позволяет настраивать такие задачи (через Apache это только через cron вроде получается сделать или через его эмуляцию), то просто замечательно.
В любом случае нужен человек, который будет заниматься ant — на данный момент никого с требуемыми навыками в проекте нет.
В любом случае нужен человек, который будет заниматься ant — на данный момент никого с требуемыми навыками в проекте нет.
А зачем именно нужен крон? Предполагается, что css и js будет меняться на работающем сервере?
черт, сорри за два комментария. Для работающего сервера существует три основные схемы изменений:
1. По факту. Загрузили новые файлы — они пересчитались при первом же к ним обращении. Минусы в том, что нужно при каждом обращении проверять файлы
2. По расписанию. Есть набор директорий (или файлов), которые нужно обходить и оптимизировать находящиеся в них файлы. Также нужно изменять строки вызова оптимизированных файлов, если контрольные суммы изменились. Минусы в сложности конечной реализации (нужно знать не только где находятся сами файлы, но и откуда они вызываются, чтобы адекватно сбрасывать кэш).
3. На тестовом сервере. Протестировали, собрали «боевую» версию, выложили. Оптимизация может быть как в процессе выкладки (что немного хуже — тестировать где?), так и на этапе подготовки версии (с обязательным тестированием).
Web Optimizer направлен, в первую очередь, по первому пути решения проблемы. Однако текущие алгоритмы позволяют использовать его и для третьего пути — тут уже все будет на совести веб-технолога, который заправляет клиентской оптимизацией на месте.
Второй путь, как я уже говорил, сложен в реализации, но планируется все же довести Web Optimizer до работоспособного состояния для поддержки и этого направления (навскидку довольно много сложностей прикладного характера и не очень понятно, насколько это вообще востребовано — будет много настроек, много факторов и, как следствие, большое число мелких ошибок, которые придется находить, отлаживать и устранять).
1. По факту. Загрузили новые файлы — они пересчитались при первом же к ним обращении. Минусы в том, что нужно при каждом обращении проверять файлы
2. По расписанию. Есть набор директорий (или файлов), которые нужно обходить и оптимизировать находящиеся в них файлы. Также нужно изменять строки вызова оптимизированных файлов, если контрольные суммы изменились. Минусы в сложности конечной реализации (нужно знать не только где находятся сами файлы, но и откуда они вызываются, чтобы адекватно сбрасывать кэш).
3. На тестовом сервере. Протестировали, собрали «боевую» версию, выложили. Оптимизация может быть как в процессе выкладки (что немного хуже — тестировать где?), так и на этапе подготовки версии (с обязательным тестированием).
Web Optimizer направлен, в первую очередь, по первому пути решения проблемы. Однако текущие алгоритмы позволяют использовать его и для третьего пути — тут уже все будет на совести веб-технолога, который заправляет клиентской оптимизацией на месте.
Второй путь, как я уже говорил, сложен в реализации, но планируется все же довести Web Optimizer до работоспособного состояния для поддержки и этого направления (навскидку довольно много сложностей прикладного характера и не очень понятно, насколько это вообще востребовано — будет много настроек, много факторов и, как следствие, большое число мелких ошибок, которые придется находить, отлаживать и устранять).
Хотел спросить в связи с этим — можно ли включить опцию, чтобы файлы при обращении не проверялись?
Т.е. у меня схема работы получится следующая: включаем один раз WebOptimizator, пробегаем по всем страницам сайта (или не по всем — у меня везде одинаковые JS и CSS-файлы подключаются), после чего проверки на изменения этих файлов уже не производятся.
Вообще очень удобная и полезная вещь, уже себе подключил.
Т.е. у меня схема работы получится следующая: включаем один раз WebOptimizator, пробегаем по всем страницам сайта (или не по всем — у меня везде одинаковые JS и CSS-файлы подключаются), после чего проверки на изменения этих файлов уже не производятся.
Вообще очень удобная и полезная вещь, уже себе подключил.
пока нет. Думаем над такой возможностью. По идее, ее нужно будет внедрить на уровне админки: пересчет кэша по факту (или при первой установке).
Но в любом случае нужно каким-то образом вычислять контрольные суммы, наверное… Или же писать в «стандартные» файлы (просто с меткой времени). Вопросов пока больше, чем ответов. Но работать в этом направлении будем.
Но в любом случае нужно каким-то образом вычислять контрольные суммы, наверное… Или же писать в «стандартные» файлы (просто с меткой времени). Вопросов пока больше, чем ответов. Но работать в этом направлении будем.
Как идея — можно считать контрольные суммы только по именам файлов, не учитывая при этом их содержимое и не проверяя их дату изменения. Как реализовать — не знаю точно.
+ еще небольшая просьба. У меня на одном и том же движке находятся несколько альясов (WWW, WAP, PDA). Все они подключают CSS и JS-файлы с одного основного хоста. Сейчас проверил — на моей инсталляции эти подхосты «упали», поскольку (по моим подозрениям) WebOptimizator ищет файлы по $_SERVER['HTTP_HOST'].
Как вариант решения, могу предложить вынести эту опцию в конфигурационный файл, и сделать её по умолчанию равной $_SERVER['HTTP_HOST']. А те, кто знают, смогут её настраивать самостоятельно.
+ еще небольшая просьба. У меня на одном и том же движке находятся несколько альясов (WWW, WAP, PDA). Все они подключают CSS и JS-файлы с одного основного хоста. Сейчас проверил — на моей инсталляции эти подхосты «упали», поскольку (по моим подозрениям) WebOptimizator ищет файлы по $_SERVER['HTTP_HOST'].
Как вариант решения, могу предложить вынести эту опцию в конфигурационный файл, и сделать её по умолчанию равной $_SERVER['HTTP_HOST']. А те, кто знают, смогут её настраивать самостоятельно.
в принципе, если сервер позволяет настраивать такие задачи (через Apache это только через cron вроде получается сделать или через его эмуляцию), то просто замечательно.
В любом случае нужен человек, который будет заниматься ant — на данный момент никого с требуемыми навыками в проекте нет.
В любом случае нужен человек, который будет заниматься ant — на данный момент никого с требуемыми навыками в проекте нет.
Попробовал на Joomla 1.5 и на связке J1.5 + Virtuemart. Летает. Очень! Особенно Virtuemart.
Спасиба за такую фичу :)
Спасиба за такую фичу :)
Хорошо но возникает вопрос как эта система взаимодействует с другими системами кеширования?
можете привести конкретный пример? А то не очень понятно, про какой слой кэширования идет речь.
Речь идёт о встроенных в движок компонентах кэшироания например в joomle применяется JRECACHE и аналогичные?
«встроенные в движок» компоненты бывают разные. В частности, в Drupal их два уровня: кэширование сгенерированных HTML-страниц и объединенных CSS- и JS-файлов.
На серверное кэширование HTML-страниц никак не влияет, генерация страниц просто «оборачивается» еще одним слоем абстракции. Кэширование CSS- и JS-файлов из самой CMS никак не использует (ибо в том же Drupal это реализовано не лучшим образом).
На серверное кэширование HTML-страниц никак не влияет, генерация страниц просто «оборачивается» еще одним слоем абстракции. Кэширование CSS- и JS-файлов из самой CMS никак не использует (ибо в том же Drupal это реализовано не лучшим образом).
Что-то у меня сайт лёг после вашего мини-установщика :)
Internal Server Error…
Internal Server Error…
Круто… но
Notice: Use of undefined constant _WEBO_CHARSET — assumed '_WEBO_CHARSET' in /home/www/web-optimizer/libs/php/lang/ru.php on line 9
частый гость
Notice: Use of undefined constant _WEBO_CHARSET — assumed '_WEBO_CHARSET' in /home/www/web-optimizer/libs/php/lang/ru.php on line 9
частый гость
Fatal error: Cannot redeclare class csstidy in /..../../../web-optimizer/libs/php/class.csstidy.php on line 61
Sign up to leave a comment.
Версия 0.3.5