Pull to refresh

Comments 29

а давайте ваш код спрячем под хабракат? :)
ребята, вы помоему сильно всё усложняете...

используйте обычный mod_rewrite:


SetOutputFilter DEFLATE



"да будет свет!" :-)
объединять файлы в один всё-равно надо
в большинстве случаев это зависит от размера.
заметил что плохо себя ведут файлы больше чем 50кб.
Согласен, надо придерживаться золотой середины - маленькие убивают своей многочисленностью, большие слишком долго грузятся. Верхняя планка с ростом пропускной способности канала будет понемного повышаться, а вот нижняя - наврядли, хотя я мало знаком со статистикой улучшения пакетной производительности рутеры в WAN-сетках.
ребята, не усложняйте...

используйте обычный mod_rewrite:
<IfModule mod_deflate.c>
<FilesMatch "\.(js|css|html|php)$">
SetOutputFilter DEFLATE
</FilesMatch>
</IfModule>
</code>

"да будет свет!" :-)
можно попросить перенести в Клиентскую оптимизацию? Я бы выложил еще и на webo.in, только решение хорошо бы отформатировать и прокомментировать построчно (например, подразумевается наличие gzlib — или как ее?)
Отформатировал и прокомментировал. Переносить в другие блоги не научился. Можно и на webo.in выложить если сошлётесь :)
для переноса в другой блог нужно в него вступить, а затем в редактировании статьи выбрать его из выпадающего списка

заметил еще, что https:// не проверяется в адресе файла
исправил (думаю мало кто называет файлы с http..) и перенёс
> $intLastModified=$intLastModifiedfilemtime($strGzipFile) || !file_exists($strGzipFile)){

Помоему у вас тут в коде какаято ошибка.
Это тоже валидатор порезал.. смотрите оригинал, там < filemtime($strFilename) ?
Исправил. Валидатор — жесть, кавычек одинарных тоже не понимает.
да, это javascript.ru почему-то ломается
Да, я где-то делал такое. Правда, за одним исключением — имя результирующего файла был не хешем, а UnixTimestamp-ом для обеспечения корректной загрузки клиентами обновленной версии стилей/скриптов в случае применения агрессивного кеширования средствами web-сервера, а также при работе через агрессивно кеширующий прокси.
Господа, один вопрос. Где-то я слышал, что gzip-нутый контент не кешируется ни проксями ни браузерами.
Неспроста ведь в настройках gzip для Tomcat стоит exclude для .css и .js. То есть при каждом посещении страницы все стили и скрипты грузятся по новой. Так что...
кто-то где-то слышал... Некоторые прокси, действительно, так делают. Проблема сложная и малоисследованная, скорее всего, должно помогать Cache-Control: private
Все конечно отлично, но вы каждый раз читаете содержимое всех js файлов.
Предлагаю делать так:

foreach ($jsFiles AS $file)
{
$compressedName .= filemtime($file).'|'.$file;
}
$compressedName = md5($compressedName);

if (!file_exists($compressedName))
{
// тут собираем все файлы, компрессим и записываем в $compressedName;
}

+ рядом со сжатым ява-скриптом хорошо бы положить несжатый (дальше расскажу, почему)
+ в папку с сжатым файлом можно положить такой htaccess, который обеспечит необходимый кэш

AddType application/x-javascript .gz
AddType application/x-javascript .js
RewriteRule ^(.*\.gz)$ $1 [L]
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteRule ^(.*\.js)$ $1.gz
AddEncoding gzip .gz
Header set ExpiresActive On
Header set ExpiresDefault "access plus 10 years"


Получается, что браузеры, поддерживающие сжатие, получат gz файл, а все остальные обычный js.
при использовании этой схемы браузер будет по нескольку раз загружать содержание одного и того же скрипта, используемого на нескольких страницах. Уж лучше тогда отдать всё сразу, зато на каждой следующей странице экономить один запрос.

кроме того, не все минимизаторы потенциально вредны: YUI compressor полностью безопасен
Даже если это так и gzip не кэшируется, это лучше если пользователь гуляет по сайту долго, а если это публичная часть и по статистике в среднем просматривается до 3 страниц, то математически лучше gzip. Тройку я взял из коэффициента архивации, но тут ещё такая особенность есть, что на разных страницах могут быть разные скрипты быть подключены.
не забывайте, что после минимизатора можно пройтись гзипом, и итоговый размер будет ещё меньше

вы предлагаете использовать только гзип, а я предлагаю минимизировать И использовать гзип

разные скрипты на разных страницах — это да, но за счет оверхеда http бывает быстрее один раз скачать 40 кб, чем 2 раза по 10 кб — и я не перепутал цифры
насчет YUI полностью поддерживаю, с gzip он еще и сжимает лучше, чем Packer
http://webo.in/articles/habrahabr/11-min…

Насчет того, что скрипты будут по несколько раз грузиться — тут компромисс нужен: либо быстрая загрузка всех страниц, либо минимизация трафика. В большинстве случаев на клиент отдается больше данных, но сайт "работает" быстрее при этом
ну у нас пока компромисс — скрипты грузятся двумя большими блоками, один из которых не на всех страницах нужен

ссылки - да, я не понимаю, почему тут какой-нибудь safehtml не используют
:) у вас все, как у людей, сделано хотя бы. Хотя я тут статью готовлю о вреде спрайтов и альтернативных методах — твое мнение будет интересно.
ага, обращайся : )
у спрайтов есть минусы, да
Sign up to leave a comment.

Articles