Pull to refresh

Comments 27

На практике 9 слишком расточительно и не эффективно, оптимально не больше 5.
Можно, но ob_gzhandler работает только на тех устройствах где есть поддержка gzip transfer encoding, а если этой поддержки нет - то в моем случае работает уменьшение HTML-кода путём удаления лишних пробелов.
Да это не много (не более 10%), но все-таки лучше уменьшить отдаваемый HTML на 10%, чем не уменьшать его вообще.
а не повлияет ли сжатие контента на кроссбраузерность?
насколько я понимаю не все браузеры умеют расжимать полученный контент... или все?
Сложно сказать, пока тестировалось все было ОК. Но особенность мобильных сайтов в том, что слишком много устройств для которых нужно тестировать. Вторая проблема это не сколько броузеры сколько кеширующие/некеширующие прокси, в основном проблемы именно с ними.

В данном исходнике используется достаточно стандартный и рекомендованный метод, сжатия, так что по-идее это должно снять какие-то проблемы с тестированием и совместимостью, но все равно хотелось-бы потестировать даный код по-больше.
Преобладающее большинство современных устройств прекрасно понимает гзип
Браузер сам должен скать серверу что он понимает а что нет, дальше дело сервера))
Если нужно просто "почистить" (x)html код, попробуйте tidy.
tidy хорош когда нужно однократно переформатировать код, а мне-бы хотелось иметь красиво сформированный код внутри проекта, и код с минимальным оверхедом на выходе (или на входе в пользовательский броузер :-)
Ваш код не очень хорош — будет кушать пробельные символы там где они важны — в тегах <textarea> и <pre>. Неплохую реализацию обработчика я видел в одном из модулей smarty (не могу вспомнить, правда вспомнить, в каком именно).
Да, я знаю о том что функция filter написана не оптимально, о чем я писал в своем посте, здесь она просто для демонстрации того что конкретно происходит.
Ну а про smarty - Большое спасибо за информаци, буду посмотреть на код.
да, в смарти пробелы убивет функция {strip}
Про комментариях в описании ob_gzhandler - да, там много всего написано и большей частью по-существу, но данный код создавался как небольшое изменение текущего сайта дабы снизить трафик в сторону клиента.

Про nginx - в курсе, он сейчас активно тестируется и скорее всего пойдет вскоре на продакшен, но на данный момент на production-е стоит достаточно своеобразно собранный apache без mod_deflate, причем админских прав там нету. То есть совсем. Единственное что могу - остановить/запустить апач :-( объяснять админу что и как нужно собрать в апаче - достаточно заморочно (с административной стороны, да и ленив, он, как и все админы без меры :-)

И в основном предназначен для того что-бы понять как можно добавив 20 строк в свой сайт получить экономию трафика. Понятно, что этот код покроет 80-90% пользователей сайта, понятно что будут недовольные у которых что-то не будет работать...

Именно для этого и был создан данный пост, что-бы выяснить у почтенной публики где могут быть грабли, и подстелить соломку :-)
лично я бы сделал бы более контролируемую систему
$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, Другое дело что в документации есть:
If a browser doesn't support compressed pages this function returns FALSE
Что в моем примере кода не учтено, с другой стороны есть
Conteg Content Negotiation:
http://www.phpclasses.org/browse/package…
который предусматривает очень много, но написан не очень понятно и хорошо, хотя есть большое желание поковырятся в нем и взять кое-какие вещи для использования
Не разъясните ли Вы мне один мучительный для меня вопрос.
а не влияет ли сжатие на скорость выполнения скрипта? и не утомительно ли серверу каждый раз перед показом сжимать, показывать, 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, но исходящий трафик не сжимался.

Следовательно инструмент получился не для конкретного сочетания сайт-сервер, но остались сомнения что все что сделано - сделано правильно, поэтому был создан данный топик на предмет узнать где могут быть грабли и куда смотреть дальше. :-)
... вопрос был задан в контексте производительности ereg* супротив preg* ...
вот именно, preg_replace('/\w+/m','', $string) быстрее отработает
То есть говоря на Perl-е :-), то:
s/\s+//mg;
В данном конкретном случае это не совсем правильно, хотелось-бы заменить два и более "пробельных" символов (пробел, табуляция, перевод каретки, перенос стоки, вертикальная табуляция и пр.) на один пробел.
следовательно можно записать как:
s/\s{2,}/ /mg;
Просто на продакшене php собран без preg :-/
Как следствие везде используются POSIX regular expression, благо они есть практически везде.
По производительности preg vs ereg, говорят что preg быстрее, но на каких-то конкретных примерах...
Only those users with full accounts are able to leave comments. Log in, please.