Comments 52
Топик без объяснения принципа действия? Такое даже Ализар себе бы не позволил.
Принцип, как я понял — оптимизация выходного кода для браузера.
Из коробки не работает — надо допиливать конфиг.
Из коробки не работает — надо допиливать конфиг.
В блоге 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
Странные оптимизации, я бы не рисковал ставить такой модуль, который сам решает, когда пересжимать изображения.
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
Странные оптимизации, я бы не рисковал ставить такой модуль, который сам решает, когда пересжимать изображения.
Google Chrome — полёт отличный.
А расскажите, что вы тестируете? Вы на свой сайт уже попробовали поставить?
LOL ^_^ Google Chrome вообще простите причем тут браузер?
Ну, как же причём. Разные браузеры работают с разной скоростью. Я заходил на apache с подключённым модом и без него и увидел разницу. Воозможно, на других браузерах, результат будет не так заметен, из-за медленной работы самого браузера. Не проверял.
Плюс, вы смотрели принцип работы? Фильтры делают простые вещи довольно. Например, убирают лишние пробелы. 6-ой IE, например, вообще иногда работал некорректно, если пробелы оставить. Chrome же не обращает на это внимания.
Поэтому, конечно, главное — мод. Но, в каждом браузеры результаты будут отличаться.
Плюс, вы смотрели принцип работы? Фильтры делают простые вещи довольно. Например, убирают лишние пробелы. 6-ой IE, например, вообще иногда работал некорректно, если пробелы оставить. Chrome же не обращает на это внимания.
Поэтому, конечно, главное — мод. Но, в каждом браузеры результаты будут отличаться.
О! Отличная новость. Хорошее начинание.
Только интересно, как это нововведение отразится на нагрузке сервера.
Только интересно, как это нововведение отразится на нагрузке сервера.
Интересно бы потестировать его в связке Apache+NginX
Невовремя вы такие новости сообщаете.
Будем тестить в понедельник после праздников, а в целом инструмент интересный, особенно автоматическое сжатие картинок.
Будем тестить в понедельник после праздников, а в целом инструмент интересный, особенно автоматическое сжатие картинок.
Да, еще заголовок неверно немного написан: конкретно апач от этого модуля тормозится а не разгоняется (ведь ему приходится делать лишнюю работу).
Зато ускоряется загрузка сайта у клиента. Надо смотреть конкретные числа в общем
Зато ускоряется загрузка сайта у клиента. Надо смотреть конкретные числа в общем
«Google разгоняет Apache». Первая мысль: «Неужели Google купил Apache Foundation и уволил всех сотрудников?»
Исправьте, пожалуйста, заголовок на более однозначный.
Исправьте, пожалуйста, заголовок на более однозначный.
Хм, то ли криво встало, то ли одно из двух.
В общем в мозиле работало вроде как
В ие открыл страница закешировалась и по ссылкам ходить не получилось (одна и та же страница по всем ссылкам)
В мозиле страница грузилась в 2 раза медленнее, чем без него.
ИМХО, пока на продакшен серверы это чудо не стоит ставить) и уж точно не вечером «пятницы»
В общем в мозиле работало вроде как
В ие открыл страница закешировалась и по ссылкам ходить не получилось (одна и та же страница по всем ссылкам)
В мозиле страница грузилась в 2 раза медленнее, чем без него.
ИМХО, пока на продакшен серверы это чудо не стоит ставить) и уж точно не вечером «пятницы»
Этого можно добиться закешировав нужные страницы, включив gzip и сжав максимально изображения.
В любом случает это будет лучше чем давать своевольничать модулю.
В любом случает это будет лучше чем давать своевольничать модулю.
ммм… webo.in на уровне апача… ждемс доп. плюшек от модуля и будет счастье.
удобная вещь, решающая добрую часть тех проблем, которые чаще всего разработчики оставляют без должного внимания.
Вообщем на тестах работает, контент сжимает через gzip, статика (css-ка и картинки) появились в его кеше в /var/mod_pagespeed, только вот из пакета на CentOS 5.5 не поставилось
Пришлось ручками извлечь из RPM-пакета, а далее все элементарно, на папку с кэшем нужны права для записи апачем (chown www)
[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)
Если Гугл будет развивать этот модуль, то предрекаю смерть продукту от webo.in…
Прекрасный повод выйти на работу в праздники.
> If you'd like to try the Apache 2.2 module, please download mod_pagespeed.
а где модуль для Apache 1.3?
а где модуль для Apache 1.3?
> краткая версия коммента: некрофил детектед
зачем переходить на Apache 2.2, если используется prefork модель?
зачем переходить на Apache 2.2, если используется prefork модель?
Имхо еще один костыль для дилетантов.
Для кэширования, gzip-а и статики, а также для защиты от простых атак reverse proxy, типа nginx, намного лучше и правильней.
Прочие ошибки надо устранять в коде сайта, а не «оптимизировать» то говно что получается от необдуманного использования говнокода.
Может быть имеет смысл слияние скриптов и стилей, инкапсуляцию мелких изображений на уровне сервера, но cms с этим справляется тоже неплохо.
Для кэширования, gzip-а и статики, а также для защиты от простых атак reverse proxy, типа nginx, намного лучше и правильней.
Прочие ошибки надо устранять в коде сайта, а не «оптимизировать» то говно что получается от необдуманного использования говнокода.
Может быть имеет смысл слияние скриптов и стилей, инкапсуляцию мелких изображений на уровне сервера, но cms с этим справляется тоже неплохо.
интересно, какая CMS с этим уже сама справляется неплохо. Особенно, в области инкапсуляции мелких изображений :)
Да любая, если ей это приделать :) Там делов-то строчек на 5-10 кода, если забыть про IE.
nginx — это хорошо, но не панацея, порой делает больше проблем. Писать свой велосипед под каждую CMS — крайне сомнительное удовольствие и будет работать все равно медленней чем модуль к веб серверу. Так что решение как раз для профессионалов, которые хотят экономить время, а не маяться с самописными костылями под десятки скриптов.
Ну да, парсить и менять уже готовую страницу конечно правильнее и быстрее чем тоже самое делать при ее создании :)
Профессионалы, имхо не доводят сайт до состояния когда нужны вообще какие-то костыли. Я конечно понимаю что дешевле поставить бесплатный мод, чем заплатить за оптимизацию, но если nginx вызывает проблемы, то этот мод будет головной болью :)
Профессионалы, имхо не доводят сайт до состояния когда нужны вообще какие-то костыли. Я конечно понимаю что дешевле поставить бесплатный мод, чем заплатить за оптимизацию, но если nginx вызывает проблемы, то этот мод будет головной болью :)
там разницы в парсинге либо пре-парсинге (с учетом кэширования) реально миллисекунды и десятые доли их. Для обычных сайтов это совсем-совсем не критично.
А универсальный модуль под каждую CMS уже есть — это WEBO Site SpeedUp :)
А универсальный модуль под каждую CMS уже есть — это WEBO Site SpeedUp :)
А на хостинге вы тоже каждому в код сайта будете лазить и оптимизировать чей-то движок?
mod_сделать_чтоб_все_супер_2.2
такой бы фильтр для tomcat…
Я так понял, что кроме всего прочего он умеет вносить правки в изображения на сайта (rescale и пр.)? Бедные «автоматические» борцы с дублированием (плагиатом) картинок…
Под винду бы…
Sign up to leave a comment.
Google выпускает mod_pagespeed для Apache