Комментарии 27
Почему нельзя воспользоваться
ob_start('ob_gzhandler',9) ?
ob_start('ob_gzhandler',9) ?
Можно, но ob_gzhandler работает только на тех устройствах где есть поддержка gzip transfer encoding, а если этой поддержки нет - то в моем случае работает уменьшение HTML-кода путём удаления лишних пробелов.
Да это не много (не более 10%), но все-таки лучше уменьшить отдаваемый HTML на 10%, чем не уменьшать его вообще.
Да это не много (не более 10%), но все-таки лучше уменьшить отдаваемый HTML на 10%, чем не уменьшать его вообще.
а не повлияет ли сжатие контента на кроссбраузерность?
насколько я понимаю не все браузеры умеют расжимать полученный контент... или все?
насколько я понимаю не все браузеры умеют расжимать полученный контент... или все?
Сложно сказать, пока тестировалось все было ОК. Но особенность мобильных сайтов в том, что слишком много устройств для которых нужно тестировать. Вторая проблема это не сколько броузеры сколько кеширующие/некеширующие прокси, в основном проблемы именно с ними.
В данном исходнике используется достаточно стандартный и рекомендованный метод, сжатия, так что по-идее это должно снять какие-то проблемы с тестированием и совместимостью, но все равно хотелось-бы потестировать даный код по-больше.
В данном исходнике используется достаточно стандартный и рекомендованный метод, сжатия, так что по-идее это должно снять какие-то проблемы с тестированием и совместимостью, но все равно хотелось-бы потестировать даный код по-больше.
Преобладающее большинство современных устройств прекрасно понимает гзип
Браузер сам должен скать серверу что он понимает а что нет, дальше дело сервера))
Если нужно просто "почистить" (x)html код, попробуйте tidy.
Ваш код не очень хорош — будет кушать пробельные символы там где они важны — в тегах <textarea> и <pre>. Неплохую реализацию обработчика я видел в одном из модулей smarty (не могу вспомнить, правда вспомнить, в каком именно).
в комментах пишут что с ишаком могут быть проблемы
http://ru2.php.net/manual/ru/function.ob…
ps не забываем про
http://sysoev.ru/mod_deflate/ - модуль для apache
http://sysoev.ru/nginx/docs/http/ngx_htt… - модуль для nginx
http://ru2.php.net/manual/ru/function.ob…
ps не забываем про
http://sysoev.ru/mod_deflate/ - модуль для apache
http://sysoev.ru/nginx/docs/http/ngx_htt… - модуль для nginx
Про комментариях в описании ob_gzhandler - да, там много всего написано и большей частью по-существу, но данный код создавался как небольшое изменение текущего сайта дабы снизить трафик в сторону клиента.
Про nginx - в курсе, он сейчас активно тестируется и скорее всего пойдет вскоре на продакшен, но на данный момент на production-е стоит достаточно своеобразно собранный apache без mod_deflate, причем админских прав там нету. То есть совсем. Единственное что могу - остановить/запустить апач :-( объяснять админу что и как нужно собрать в апаче - достаточно заморочно (с административной стороны, да и ленив, он, как и все админы без меры :-)
И в основном предназначен для того что-бы понять как можно добавив 20 строк в свой сайт получить экономию трафика. Понятно, что этот код покроет 80-90% пользователей сайта, понятно что будут недовольные у которых что-то не будет работать...
Именно для этого и был создан данный пост, что-бы выяснить у почтенной публики где могут быть грабли, и подстелить соломку :-)
Про nginx - в курсе, он сейчас активно тестируется и скорее всего пойдет вскоре на продакшен, но на данный момент на production-е стоит достаточно своеобразно собранный apache без mod_deflate, причем админских прав там нету. То есть совсем. Единственное что могу - остановить/запустить апач :-( объяснять админу что и как нужно собрать в апаче - достаточно заморочно (с административной стороны, да и ленив, он, как и все админы без меры :-)
И в основном предназначен для того что-бы понять как можно добавив 20 строк в свой сайт получить экономию трафика. Понятно, что этот код покроет 80-90% пользователей сайта, понятно что будут недовольные у которых что-то не будет работать...
Именно для этого и был создан данный пост, что-бы выяснить у почтенной публики где могут быть грабли, и подстелить соломку :-)
лично я бы сделал бы более контролируемую систему
еще бы обязательно добавил такие заголовки
и не забыл бы проверить что вообще можно жать так
ps извиняюсь за поток сознания
$accept_encoding = isset($_SERVER['HTTP_ACCEPT_ENCODING']) ? $_SERVER['HTTP_ACCEPT_ENCODING'] : $_SERVER['HTTP_TE'];
$accept_encoding = explode(',', $accept_encoding);
foreach ($accept_encoding as $encoding)
{
$encoding = trim($encoding);
if ($encoding == ('gzip' || 'x-gzip'))
{
$encoding = 'gzip';
break;
}
if ($encoding == 'deflate')
{
break;
}
}
$this->encoding = $encoding;
if ($this->encoding == 'gzip')
{
$buffer = gzencode($Source, $this->compressionLevel);
}elseif ($this->encoding == 'deflate')
{
$buffer = gzdeflate($Source, $this->compressionLevel);
}else
{
$buffer = $Source;
}еще бы обязательно добавил такие заголовки
setHeader('Content-Encoding', $this->encoding);
setHeader('Vary', 'Accept-Encoding');и не забыл бы проверить что вообще можно жать так
if (!headers_sent() && extension_loaded("zlib") && !empty($Source) && (isset($_SERVER['HTTP_ACCEPT_ENCODING']) || isset($_SERVER['HTTP_TE'])))
ps извиняюсь за поток сознания
В принципе то-же самое делает и ob_gzhandler, Другое дело что в документации есть:
Что в моем примере кода не учтено, с другой стороны есть
Conteg Content Negotiation:
http://www.phpclasses.org/browse/package…
который предусматривает очень много, но написан не очень понятно и хорошо, хотя есть большое желание поковырятся в нем и взять кое-какие вещи для использования
If a browser doesn't support compressed pages this function returns FALSEЧто в моем примере кода не учтено, с другой стороны есть
Conteg Content Negotiation:
http://www.phpclasses.org/browse/package…
который предусматривает очень много, но написан не очень понятно и хорошо, хотя есть большое желание поковырятся в нем и взять кое-какие вещи для использования
тогда уж http://code.google.com/p/minify/source/b…
лицензия тоже подходящая
лицензия тоже подходящая
Не разъясните ли Вы мне один мучительный для меня вопрос.
а не влияет ли сжатие на скорость выполнения скрипта? и не утомительно ли серверу каждый раз перед показом сжимать, показывать, F5, сжимать, показывать?
заранее спасибо
а не влияет ли сжатие на скорость выполнения скрипта? и не утомительно ли серверу каждый раз перед показом сжимать, показывать, F5, сжимать, показывать?
заранее спасибо
Использование компрессии естественно влияет на скорость выполнения скрипта и на нагрузку создаваемую на сервере, но окупается тем что пользователь, для примера, при получении HTML кода размером 7355 байт затрачивает 2541 байт GPRS трафика. Ресурсов на клиенте потребляется существенно меньше, т.к. декомпрессия - существенно менее ресурсоемкий процесс.
Потом класс был расширен на предмет того что-бы кешировать полученные страницы в memcached-е, и если в качестве frontend-а используется nginx, то контент отдавался без участия php, а напрямую из memecache
ereg_replace( "[ \t\r\n]{2,}", ' ',
memecache, nginx, ereg...
я понимаю что прикрутить nginx и memcache обычно дешевле чем оптимизировать код, просто хотелось лично для себя уточнить откуда взялся такой загадочный коктейль...
Коктейль взялся из-за того что разработка происходит на nginx, а основной сайт крутится под своеобразно собранным апачем.
В дальнейшем хотелось-бы переползти сначала на nginx+apache а затем совсем отказаться от apache в пользу nginx + php in FastCGI mode.
Поэтому и родился такой гибрид :-)
Да а уменьшение HTML кода путем удаления пробелов - таки не все мобильники умеют gzip, следовательно хотелось-бы хоть что-то для этих клиентов уменьшить. :-)
Потом при использовании еще нескольких сайтов на виртуальных хостингах столкнулись с тем что трафик передаваемый в сторону клиента хотелось-бы уменьшить, при добавлении этих классов эта проблема решилась. То есть php был собран с zlib, но исходящий трафик не сжимался.
Следовательно инструмент получился не для конкретного сочетания сайт-сервер, но остались сомнения что все что сделано - сделано правильно, поэтому был создан данный топик на предмет узнать где могут быть грабли и куда смотреть дальше. :-)
В дальнейшем хотелось-бы переползти сначала на nginx+apache а затем совсем отказаться от apache в пользу nginx + php in FastCGI mode.
Поэтому и родился такой гибрид :-)
Да а уменьшение HTML кода путем удаления пробелов - таки не все мобильники умеют gzip, следовательно хотелось-бы хоть что-то для этих клиентов уменьшить. :-)
Потом при использовании еще нескольких сайтов на виртуальных хостингах столкнулись с тем что трафик передаваемый в сторону клиента хотелось-бы уменьшить, при добавлении этих классов эта проблема решилась. То есть php был собран с zlib, но исходящий трафик не сжимался.
Следовательно инструмент получился не для конкретного сочетания сайт-сервер, но остались сомнения что все что сделано - сделано правильно, поэтому был создан данный топик на предмет узнать где могут быть грабли и куда смотреть дальше. :-)
... вопрос был задан в контексте производительности ereg* супротив preg* ...
вот именно, preg_replace('/\w+/m','', $string) быстрее отработает
Просто на продакшене php собран без preg :-/
Как следствие везде используются POSIX regular expression, благо они есть практически везде.
По производительности preg vs ereg, говорят что preg быстрее, но на каких-то конкретных примерах...
Как следствие везде используются POSIX regular expression, благо они есть практически везде.
По производительности preg vs ereg, говорят что preg быстрее, но на каких-то конкретных примерах...
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PHP: Уменьшаем исходящий трафик (или изобретаем очередной велосипед)