Google выпускает mod_pagespeed для Apache

[@homm]

Топик без объяснения принципа действия? Такое даже Ализар себе бы не позволил.

[@niro]

Принцип, как я понял — оптимизация выходного кода для браузера.
Из коробки не работает — надо допиливать конфиг.

[@niro]

у меня не корректно работает с opera 10.70

[@litos]

Работает из коробки gzip/кэширование, но допилить можно там другие плюшки по оптимизации html-кода и перепаковке картинок

[@Kapustos]

В блоге google webmaster написано вот так:

Making changes to the pages built by the Content Management Systems (CMS) with no need to make changes to the CMS itself,
Recompressing an image when its HTML context changes to serve only the bytes required (typically tedious to optimize manually), and
Extending the cache lifetime of the logo and images of your website to a year, while still allowing you to update these at any time

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

[@freeek]

Google Chrome — полёт отличный.

[@homm]

А расскажите, что вы тестируете? Вы на свой сайт уже попробовали поставить?

[@freeek]

Только на localhoste пока попробовал, поигрался с фильтрами. Включал/выключал. Брал разные проекты, которые есть на локальной машине. Ну, думаю, вы примерно представляете, как это делается :)

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

[@developer]

LOL ^_^ Google Chrome вообще простите причем тут браузер?

[@freeek]

Ну, как же причём. Разные браузеры работают с разной скоростью. Я заходил на apache с подключённым модом и без него и увидел разницу. Воозможно, на других браузерах, результат будет не так заметен, из-за медленной работы самого браузера. Не проверял.

Плюс, вы смотрели принцип работы? Фильтры делают простые вещи довольно. Например, убирают лишние пробелы. 6-ой IE, например, вообще иногда работал некорректно, если пробелы оставить. Chrome же не обращает на это внимания.

Поэтому, конечно, главное — мод. Но, в каждом браузеры результаты будут отличаться.

[@developer]

понятно

[@pilezkiy]

О! Отличная новость. Хорошее начинание.
Только интересно, как это нововведение отразится на нагрузке сервера.

[@Artkumpel]

Интересно бы потестировать его в связке Apache+NginX

[@rednaxi]

если я сам не смогу то скорей всего кто то из моей команды в понедельник на одном из сайтов протестирует, если до этого не будет результатов — напишу свой топик

[@rednaxi]

Невовремя вы такие новости сообщаете.
Будем тестить в понедельник после праздников, а в целом инструмент интересный, особенно автоматическое сжатие картинок.

[@rednaxi]

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

Зато ускоряется загрузка сайта у клиента. Надо смотреть конкретные числа в общем

[@irsick]

«Google разгоняет Apache». Первая мысль: «Неужели Google купил Apache Foundation и уволил всех сотрудников?»

Исправьте, пожалуйста, заголовок на более однозначный.

[@kiryam]

Хм, то ли криво встало, то ли одно из двух.
В общем в мозиле работало вроде как
В ие открыл страница закешировалась и по ссылкам ходить не получилось (одна и та же страница по всем ссылкам)
В мозиле страница грузилась в 2 раза медленнее, чем без него.
ИМХО, пока на продакшен серверы это чудо не стоит ставить) и уж точно не вечером «пятницы»

[@DLag]

Этого можно добиться закешировав нужные страницы, включив gzip и сжав максимально изображения.
В любом случает это будет лучше чем давать своевольничать модулю.

[@psman]

ммм… webo.in на уровне апача… ждемс доп. плюшек от модуля и будет счастье.

[@popcha]

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

[@litos]

Какие именно проблемы решает по вашему данный модуль? Процессор меньше грузиться не стал, трафик вот уменьшится это да, и то не факт, картинки сжимать не стоит

[@popcha]

к примеру, дополняет функционал, который не обеспечивают некоторые фреймворки и CMS: пакует стили и скрипты, улучшает подачу статики пользователю. мелочь, я приятно.

[@litos]

Вообщем на тестах работает, контент сжимает через gzip, статика (css-ка и картинки) появились в его кеше в /var/mod_pagespeed, только вот из пакета на CentOS 5.5 не поставилось

[root@centos ~]# rpm -i mod-pagespeed-beta_current_i386.rpm
warning: mod-pagespeed-beta_current_i386.rpm: Header V3 DSA signature: NOKEY, key ID 7fac5991
error: Failed dependencies:
        at is needed by mod-pagespeed-beta-0.9.0.0-128.i386

Пришлось ручками извлечь из RPM-пакета, а далее все элементарно, на папку с кэшем нужны права для записи апачем (chown www)

[@developer]

значит в связке
nginx -> Apache
можно прописать эту папочку для поиска и из нее раздавать статику nginx-ом

[@Sannis]

$> sudo yum install at

Не пробовали? /bin/rpm не умеет автоматически устанавливать зависимости :-)

[@remal]

Если Гугл будет развивать этот модуль, то предрекаю смерть продукту от webo.in…

[@benone]

Для webo.in это наоборот большая возможность.

[@sunnybear]

да, но нам эта ситуация только на руку: рынок-то гуглу двигать проще :) А чем больше рынок, тем больше и мы с ним

[@ZloeSabo]

Прекрасный повод выйти на работу в праздники.

[@phasma]

> If you'd like to try the Apache 2.2 module, please download mod_pagespeed.

а где модуль для Apache 1.3?

[@weirdan]

краткая версия коммента: некрофил детектед
длинная версия: Apache 1.3 не поддерживается Apache Foundation. Разрабатывать новые модули под него сейчас — все равно, что писать новые экстеншены под PHP3 или драйвера под DOS. Можете портировать сами или нанять человека, который это сделает за вас.

[@Vii]

краткая версия коммента: некрофил детектед

Таких «некрофилов» целый nichost например :(

[@phasma]

> краткая версия коммента: некрофил детектед

зачем переходить на Apache 2.2, если используется prefork модель?

[@weirdan]

Встречный вопрос: зачем использовать префок, если вебсервер общается с аппсервером(ами) через FastCGI?

[@phasma]

Prefork стабилен, при падении одного процесса все остальные продолжают работать.

[@Wott]

Имхо еще один костыль для дилетантов.

Для кэширования, gzip-а и статики, а также для защиты от простых атак reverse proxy, типа nginx, намного лучше и правильней.

Прочие ошибки надо устранять в коде сайта, а не «оптимизировать» то говно что получается от необдуманного использования говнокода.

Может быть имеет смысл слияние скриптов и стилей, инкапсуляцию мелких изображений на уровне сервера, но cms с этим справляется тоже неплохо.

[@sunnybear]

интересно, какая CMS с этим уже сама справляется неплохо. Особенно, в области инкапсуляции мелких изображений :)

[@Wott]

Да любая, если ей это приделать :) Там делов-то строчек на 5-10 кода, если забыть про IE.

[@Plohich]

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

[@Wott]

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

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

[@sunnybear]

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

А универсальный модуль под каждую CMS уже есть — это WEBO Site SpeedUp :)

[@Plohich]

и его можно прозрачно установить на все 2500 аккаунтов на виртуальном хостинге, не тревожа их владельцев? :-)

[@sunnybear]

Можно. И мы такое уже делаем :)

[@Yukko]

А на хостинге вы тоже каждому в код сайта будете лазить и оптимизировать чей-то движок?

[@Wott]

А какая разница хостингу как быстро грузиться страница на клиенте?

[@sunnybear]

хостингу важно, что меньше процессора все это хозяйство ело. Поэтому очень вряд ли они будут этот модуль устанавливать :)

[@Wott]

ППКС :)

[@equand]

mod_сделать_чтоб_все_супер_2.2

[@maxcom]

такой бы фильтр для tomcat…

[@Vii]

Я так понял, что кроме всего прочего он умеет вносить правки в изображения на сайта (rescale и пр.)? Бедные «автоматические» борцы с дублированием (плагиатом) картинок…

[@ruzzz]

Под винду бы…