После двух лет бета-тестирования компания Google объявила (http://googledevelopers.blogspot.com/2012/10/make-web-faster...) о переводе mod_pagespeed в разряд стабильных продуктов. В рамках проекта mod_pagespeed (http://www.modpagespeed.com/) развивается открытый модуль для http-сервера Apache, выполняющий работу по автоматической оптимизации сайта с целью увеличения отзывчивости и пропускной способности при отдаче контента. Код модуля распространяется (http://code.google.com/p/modpagespeed/) под лицензией Apache.
Модулем поддерживается более 40 фильтров для оптимизации web-страниц и сопутствующих ресурсов, таких как CSS, JavaScript и файлов с изображениями. Оптимизация производится в полностью прозрачном режиме и не требует изменения содержимого сайта. Встроенные механизмы кэширования сводят к минимуму дополнительную нагрузку на сервер, возникающую в процессе работы модуля, минимизируя число случаев, требующих выполнения преобразований на лету.
Большинство из используемых в mod_pagespeed методов направлены на увеличение эффективности кэширвоания на стороне клиента, сокращение числа запросов/ответов и уменьшение размера отдаваемых и принимаемых данных. В качестве примеров используемых в mod_pagespeed техник можно привести оптимизацию и сжатие изображений, уменьшение разрешения изображений (если не совпадают фактическое разрешение и указанное теге IMG), удаление избыточных данных из JavaScript-кода и CSS, удаление лишних HTML-тэгов, объединение нескольких JavaScript/CSS-файлов, оптимизация использования заголовков Expires, Cache-Control и Last-Modified.
Модуль mod_pagespeed разработан как продолжение развития инструментария PageSpeed (https://developers.google.com/speed/pagespeed/), предназначенного для анализа web-сайтов с целью выявления узких мест, отрицательно влияющих на скорость отдачи контента. Для насыщенных web-страниц, на которых загружается много дополнительных скриптов и изображений, эффект от использования mod_pagespeed заметен на глаз - страницы грузятся в несколько раз быстрее. Модуль полностью готов для промышленного применения и уже используется на более чем 120 тысячах сайтов, а также такими крупнейшими хостинг-провайдерами, как GoDaddy и DreamHost.<center><iframe width="640" height="360" src="http://www.youtube.com/embed/8moGR2qf994?rel=0" frameborder="0" allowfullscreen></iframe></center>
<center><iframe width="640" height="360" src="http://www.youtube.com/embed/6uCAdQSHhmA?rel=0" frameborder="0" allowfullscreen></iframe></center>URL: http://googledevelopers.blogspot.com/2012/10/make-web-faster...
Новость: http://www.opennet.me/opennews/art.shtml?num=35063
Интересно, если имеется nginx на фронте будет ли от этого модуля ощутимая польза?
Для nginx тоже есть модуль. И можно включить только некоторые фильтры, смотря как настроите.
https://github.com/pagespeed/ngx_pagespeed
Разработка порта, думаю к выпуску стабильной ветки 1.4 уже будет готово, как и многие другие плюшки.
Будет. Так и использую. Фронтенд - nginx. бекенд - apache+mod_pagespeed
интересно, быстро ли его портанут в nginx?
https://github.com/pagespeed/ngx_pagespeed
После двадцати лет бета-тестирования компания Google объявила о создании кнопки, которая автомагически делает всё, что вы хотите. Теперь не надо платить деньги программистам, дизайнерам, админам, прокладчикам кабеля и вообще никому: достаточно заплатить гуглу и поставить кнопку.
Типун тебе на язык!
то есть теперь во время разработки и не только надо учитывать не только тупняк кеша браузера и php и apache'вский но и эту хунту... спасиибо ..отлично..
Во время разработки - нет, зачем.
А при тестировании эта х-ня ещё и ошибки поможет исправить...
> то есть теперь во время разработки и не только надо учитывать
> не только тупняк кеша браузера и php и apache'вский но и
> эту хунту... спасиибо ..отлично..Интересно, что вы такое используете, где есть подобный, как вы говорите тупняк? Если говорить о кэширование на стороне сервера, то там всегда были механизмы не позволяющие происходить такому тупняку. Да и кэширование браузером, а тем более современными тоже такого не происходит.
тупняк у него потому, что системное время стоит далеко в прошлом вот и получается, что сервер высылает дату будущего и браузер строго этому следует )) - правда браузер будет ругаться если открыть https сайт )))
еще раз перечитал.. получается они заново изобрели кэш на стороне сервера, что ли?
еще пару раз перечитай
и теперь в DOM'e смотришь одно - а с сервера должно идти другое..??никак не въезжаю что нового они придумали за два года
Сжатие картинок, создание спрайтов, объединение CSS/JS в 1 файл и другие оптимизации на лету без участия разработчика
хорошая новость, используем больше года и очень довольны.
на сайтах с тяжелым и непредсказуемым контентом (блоги, wordpress in general) значительно снижает нагрузку с серверов.
> хорошая новость, используем больше года и очень довольны.
> на сайтах с тяжелым и непредсказуемым контентом (блоги, wordpress in general) значительно
> снижает нагрузку с серверов.Поместите папку кэша в RAM счастливы будите еще больше.
Varnish
Varnish только кэширует, pagespeed дополнительно оптимизирует контент
Господи, когда вымрут все админы, считающие, что размещение файлов на RAM диске ускоряет их отдачу. Люди, АУ! Размещение файлов на RAM-диске только в два раза увеличивает обьем потребляемой памяти!
> админыэникейки
// fftgj
Размешение файлов в РАМе снижает диск ио - у ускоряет загрузку файлов, держи кеш pagespeed/eaccelerator/tmp-sessions и т.д. на диске - угробиш ио.
рам дешевый = профит.
Господи, ну почитайте вы про buffer cache, а? Разница только при первом чтении будет заметна. При последующих нет. Поэтому вместо того, чтобы размещать файлы в рам - делайте на них cat, добьетесь ровного того же эффекта и памяти будет два раза меньше. В обычном случае: чтение файла с диска по памяти это буферный кеш (который LRU, поэтому наиболее популярные файлы будут и так из памяти читаться), а в случае рам - это размер файлов в рам + буферный кеш.
а у нас не прижился
сайт начал вообще странно работать - отображалось нормально, а часть функционала не работала, видно слишком урезывает JavaScript
наверное вы его "настривать" стали, по умолчанию модуль не делает никаких потенциально деструктивных изменений
т.е. модуль выпрямляет кривизну рук разрабов?
и ваще. опера, например, в режиме турбо искажает картинки что пипец. здесь также "эффект от использования mod_pagespeed заметен на глаз"?
Все же настраиваемо, там хуча настроек для овер 40 фильтров. По изображениям сами почитайте https://developers.google.com/speed/docs/mod_pagespeed/filte...
Картинки сжимаются без потерь. Опера, соотстветсенно, с потерями.
При чем тут кривизна рук разработчиков? Плагин создан для тех, кто не собирается писать велосипеды, а предпочитает использовать готовые решения — он не исправляет ошибки. В этом случае — модуль сжимает скрипты, картинки и css-стили.
https://github.com/mtourne/ngx_instaweb/tree/dev
Попробовал, работает :)Если кому надо, запихал deb в репозиторий для debian/wheezy[amd64] и собираюсь обновлять по мере появления:
deb [arch=amd64] http://mirror.mephi.ru/debian-mephi/ unstable main
часто возникают проблемы при настройке PageSpeed, многое зависит от настроек DNS провайдера http://nas.myftp.org/pagespeed-service/