Комментарии 68
спасибо, хороший перевод и рассуждения. Надо попробовать :)
"В первой строке мы сообщаем серверу, что файлы с расширением .gz нужно отдавать с gzip encoding-type, чтобы браузер понял, что перед ним архив, а текстовый файл."
Нигде в фразе не ошиблись? ,)
Спасибо за перевод. Полезно.
Нигде в фразе не ошиблись? ,)
Спасибо за перевод. Полезно.
Если интересно, CakePHP умеет сжимать CSS'ки на уровне фреймворка.
Год назад поднимал этот вопрос, но отказался из за того, что якобы IE не кеширует gz файлы. Может я был не прав?
Кстати неплохого уменьшения размеров можно добиться оптимизацией:
CSS - http://handy-notes.blogspot.com/2007/08/…
JS - http://handy-notes.blogspot.com/2007/08/…
Кстати неплохого уменьшения размеров можно добиться оптимизацией:
CSS - http://handy-notes.blogspot.com/2007/08/…
JS - http://handy-notes.blogspot.com/2007/08/…
было бы интересно узнать ситуацию сейчас, когда уже 30-40% ходят под IE7, а IE5 почти не используется.
Сдается мне, что совместное применение ETag + Expires если не решает проблему, то помогает в 99% случаев (учитывая данное положение вещей в мире браузеров, год назад оно было несколько другое :)
Сдается мне, что совместное применение ETag + Expires если не решает проблему, то помогает в 99% случаев (учитывая данное положение вещей в мире браузеров, год назад оно было несколько другое :)
Я замечал другую проблему с ИЕ, причем даже седьмым. При подключении через прокси-сервер, он отказывался понимать сжатые файлы. Сейчас уже плохо помню почему, но, кажись, прокся резала какой-то заголовок.
еще лучше перед отдачей gzip сжимать css и js убирая лишние пустые строки, комментарии и т.п. и потом сливать их в два файла (css и js) и отдавать уже его, но это надо на уровне движка реализовывать
В таком случае, малейшее изменение в каком-нибудь небольшом файле приведёт к очередной загрузке всего большого склеенного файла. Что не всегда хорошо. Тем более, когда идёт постоянная разработка, либо очередное обновление.
Такой момент есть. Но опять же...
Обычно система фиксируется на какой-то стабильной версии и дальше уже идут "пакетные" обновления, которые зачастую выходят достаточно нечасто и изменения затрагивают большой процент файлов.
Если анализируя еще глубже, то при обосновании перехода на такую систему необходимо смотреть какие пользователи вас посещают, что это за проект и какие изменения там планируются, как налажена система тестирования и т.п. Нюансов конечно много
Обычно система фиксируется на какой-то стабильной версии и дальше уже идут "пакетные" обновления, которые зачастую выходят достаточно нечасто и изменения затрагивают большой процент файлов.
Если анализируя еще глубже, то при обосновании перехода на такую систему необходимо смотреть какие пользователи вас посещают, что это за проект и какие изменения там планируются, как налажена система тестирования и т.п. Нюансов конечно много
нашли на чём экономить
Например, у меня сейчас в разработке CMS с фронтэндом на JavaScript. Там идет постоянная загрузка довольно больших скриптов. А основной скрипт вообще весит под 600 Кб. С моим каналом на 256 Кб/с сжатие не помешает...
frontend 600kb только скрипты? смело. Понимаю если это на backend'е
А нормально. До оптимизации было >1Мб. После оптимизации и сжатия их стало 160Кб ;-)
Учитывая кеширование, в процессе работы грузится совсем мало. На некоторые ответы сервера думаю прикрутить архивирование "на лету" (но это уже совсем мелочи). Так что даже с диалапом нормально заработает. Зато красиво и удобно.
Учитывая кеширование, в процессе работы грузится совсем мало. На некоторые ответы сервера думаю прикрутить архивирование "на лету" (но это уже совсем мелочи). Так что даже с диалапом нормально заработает. Зато красиво и удобно.
Я бы голову за такое отрывал, если честно.
Везде, где можно отказаться от ДжаваСкипта, от него лучше отказываться.
Везде, где можно отказаться от ДжаваСкипта, от него лучше отказываться.
Ну не знаю... Нормальная технология, если разумно использовать. Как еще можно реализовать такое (см. рис.1)? Тут JavaScript вдоль и поперек. И работает без проблем во всех современных браузерах.
Редактирование структуры сайта простым перетаскиванием элементов, диалоговые окна свойств страниц, создание страницы в 2 клика, удобное редактирование материалов, человечные валидаторы данных, подсветка синтаксиса в редакторе шаблонов (XSLT), стилей (CSS) и модулей сайта (Parser, php) и т.д.
Редактирование структуры сайта простым перетаскиванием элементов, диалоговые окна свойств страниц, создание страницы в 2 клика, удобное редактирование материалов, человечные валидаторы данных, подсветка синтаксиса в редакторе шаблонов (XSLT), стилей (CSS) и модулей сайта (Parser, php) и т.д.
НЛО прилетело и опубликовало эту надпись здесь
я сначала применял технику описываемую автором статьи у себя в приложениях. поначалу прикольно, а потом понял, что неудобно совсем. если нужно поменять буковку в скрипте &mdash снова надо "гзипить".
мой совет &mdash пользуйтесь кешем!
грамотно настроив mod_expires (напр., хранить в кеше в течении года) и внедрив технику версий файлов в имени самого файла &mdash отпали вообще все проблемы. экономится трафик, время рендеринга &mdash пользователь доволен. если мне нужно поменять скрипт или стили, сохранив изменения, я повышаю версию. имена файлов выглядят так: "script_v1.0.5.js".
единственная проблема в таком подходе &mdash при смене имени файла, нужно найти и поменять его во всех местах, где он подключается. для простых проектов элементарно решается через "Find in Files..."
мой совет &mdash пользуйтесь кешем!
грамотно настроив mod_expires (напр., хранить в кеше в течении года) и внедрив технику версий файлов в имени самого файла &mdash отпали вообще все проблемы. экономится трафик, время рендеринга &mdash пользователь доволен. если мне нужно поменять скрипт или стили, сохранив изменения, я повышаю версию. имена файлов выглядят так: "script_v1.0.5.js".
единственная проблема в таком подходе &mdash при смене имени файла, нужно найти и поменять его во всех местах, где он подключается. для простых проектов элементарно решается через "Find in Files..."
если 95%...99% пользователей приходят в первый раз, то... ну сами понимаете :)
автоматизированными средствами кто это сделать мешает? (find . -name *.css ...)
не мешает, а даже помогает.
в таком случае я не могу использовать кеш по полной программе, так как имя файла одно и тоже.
в таком случае я не могу использовать кеш по полной программе, так как имя файла одно и тоже.
А это делается методами file.css.gz?20070820 и делается на уровне фреймворка.
я против таких методов, этот файл не попадёт в кеш.
мне даже процессорного времени жалко на генерацию разного URL ;-)
мне даже процессорного времени жалко на генерацию разного URL ;-)
с чего это вдруг он не попадёт в кэш? и какой кэш имеется ввиде? серверный или клиентско-браузерный?
клиентско-браузерный. не буду спорить не зная хедеров, но в 99% случаев никто их и не настраивает.
фреймворк это делает сам?
фреймворк это делает сам?
хабралюди, занятые в вебе, пожалуйста, объясните мне, почему никто не пользуется промежуточным буфером с быстрым доступом, который хранит в себе ту информацию, которая с наибольшей вероятностью может быть запрошена и называется кеш?
в своих приложениях я всегда пользуюсь им, где только возможно.
я сейчас на собственной шкуре страдаю от этого.
в израиле у меня анлим 5 мбит/сек (напр, 1.5 мбит/сек стоит 25 долларов) и то, я матерюсь на страницы "без кеша", потому как я сам в этой теме, и мне просто не понятно: почему во всех распространённых браузерах есть такая функция, страницы реально открываются быстрее... и не использовать её?
я родился в небольшом городе в сибири, куда интернет ещё не дошёл, чтобы называть его доступным (по деньгам) рядовым жителям. сейчас на месяц приехал сюда... по модему соединение 19 кбит/с, GPRS — 56кбит/с оооочень редко. выделенку местную на месяц ставить не буду.
и я жду пока откроются одноклассники (потому, что только туда записались мои друзья), майл.ру (те же друзья хранят свои фотографии) и в том же духе другие популярные сайты... мне просто стыдно за девелоперов, в руках столько технологий, а для кого они?
в своих приложениях я всегда пользуюсь им, где только возможно.
я сейчас на собственной шкуре страдаю от этого.
в израиле у меня анлим 5 мбит/сек (напр, 1.5 мбит/сек стоит 25 долларов) и то, я матерюсь на страницы "без кеша", потому как я сам в этой теме, и мне просто не понятно: почему во всех распространённых браузерах есть такая функция, страницы реально открываются быстрее... и не использовать её?
я родился в небольшом городе в сибири, куда интернет ещё не дошёл, чтобы называть его доступным (по деньгам) рядовым жителям. сейчас на месяц приехал сюда... по модему соединение 19 кбит/с, GPRS — 56кбит/с оооочень редко. выделенку местную на месяц ставить не буду.
и я жду пока откроются одноклассники (потому, что только туда записались мои друзья), майл.ру (те же друзья хранят свои фотографии) и в том же духе другие популярные сайты... мне просто стыдно за девелоперов, в руках столько технологий, а для кого они?
А есть уверенность, что сжатие "на лету" небольшой библиотеки с учетом того, что для каждого пользователя оно будет производится один раз (потом берется из кэша) будет более ресурсоёмко, чем достаточно сложная mod_rewrite-обработка, особенно в .htaccess?
про .htaccess я писал немного: я против его использования. А любое сжатие на лету это процессорное время. Я не понимаю, зачем его каждый раз тратить. Другой вопрос, когда у вас ненагруженный проект, всего один внешний JS-файл, например, и есть желание "покодить"... Иначе только статика!
что страшного в mod_rewrite?
если можно с примерами и ссылками с тестированием
если можно с примерами и ссылками с тестированием
Не mod_rewrite, а именно .htaccess: Apache: Основы производительности (см. второй пункт)
У меня вот тоже нет такой уверенности. Хотя если там скрипты по метру весят, может и будет толк, а так, AllowOverride сам по себе довольно ресурсоемок, а с ModRewrite и совсем плохо становится с ресурсами сервера.
НЛО прилетело и опубликовало эту надпись здесь
по-моему все проще :)
тк есть соощения о проблемах со сжатыми файлами на IE и проблемы с маковскими браузерами, то идея коотрой я пользуюсь - это при деплойменте пакую js\css не архиваторами а оптимизаторами кода. за исключением prototype.js + script.aculo.us которые были взяты из спец.архива, который был оптимизирован не мной :)
и да, повторюсь - это все деплойменте, поэтому разработка идет без проблем, перед выкладыванием на production софт выкладыывается на pred-production, чтобы на всякий случай проверить качество сжатия методом научного тыка. но пока проблем не было :)
тк есть соощения о проблемах со сжатыми файлами на IE и проблемы с маковскими браузерами, то идея коотрой я пользуюсь - это при деплойменте пакую js\css не архиваторами а оптимизаторами кода. за исключением prototype.js + script.aculo.us которые были взяты из спец.архива, который был оптимизирован не мной :)
и да, повторюсь - это все деплойменте, поэтому разработка идет без проблем, перед выкладыванием на production софт выкладыывается на pred-production, чтобы на всякий случай проверить качество сжатия методом научного тыка. но пока проблем не было :)
У меня около года используется подход почти 1 в 1 с тем, что описан автором. Вполне себе работает и не жужжит :)
Спасибо за хинт!
За проверку поддержки клиентом encoding-а на уровне htaccess отдельный респект.
Ещё есть один минус — все сжатые файлы полученные с сервера так и хранятся в кеше в сжатом виде, и при каждом обращении к ресурсу распаковываются :)
Из за этого на быстрых каналах или медленных машинах тормоза распаковки, превышают тормоза загрузки. Актуально для систем с множеством JS.
Из за этого на быстрых каналах или медленных машинах тормоза распаковки, превышают тормоза загрузки. Актуально для систем с множеством JS.
узким местечком между сервером и пользователем являются транспортные расходы на передачу данных => нужно js'ки объединять в один файл (можно еще и сжать целиком архив, либо по областям) и грузить его один раз. Тем самым скорость загрузки страниц заметно увеличиться. Минус в том, что обновлять тяжело.
Нашли о чем говорить ±10-20 КБ это не так много, а писать css на 1 МБ говорит о непрофессионализме человека в данной области.
Лучше бы сперва графику научились оптимизировать, которая куда важнее.
Лучше бы сперва графику научились оптимизировать, которая куда важнее.
Действительно, больше половины пользователей заходят на страницу только один раз, поэтому кэширования и т.п. не достаточно. По крайней мере нужно убирать лишние пробелы переводы строки т.п.
Так же по теме:
Оптимизация скорости загрузки страницы:
http://developer.yahoo.com/performance/
Зипование:
http://developer.yahoo.net/blog/archives/2007/07/high_performanc_3.html
Кэширование:
http://developer.yahoo.net/blog/archives/2007/05/high_performanc_2.html
Инструментарий для анализа скорости загрузки страниц:
* YSlow (http://developer.yahoo.com/yslow/) - Инструменты / FireBug / Inspect Element(cntrl+shift+c) / YSlow / Performance
* TamperData (https://addons.mozilla.org/ru/firefox/addon/966) - Инструменты / Перехват данных
* FireBug - (http://www.getfirebug.com/) - Инструменты / FireBug / Inspect Element(cntrl+shift+c) / net / all
* Web Developer (www.websiteoptimization.com) - Tools / ViewSpeedReport
* LoadTimeAnalizer
Так же по теме:
Оптимизация скорости загрузки страницы:
http://developer.yahoo.com/performance/
Зипование:
http://developer.yahoo.net/blog/archives/2007/07/high_performanc_3.html
Кэширование:
http://developer.yahoo.net/blog/archives/2007/05/high_performanc_2.html
Инструментарий для анализа скорости загрузки страниц:
* YSlow (http://developer.yahoo.com/yslow/) - Инструменты / FireBug / Inspect Element(cntrl+shift+c) / YSlow / Performance
* TamperData (https://addons.mozilla.org/ru/firefox/addon/966) - Инструменты / Перехват данных
* FireBug - (http://www.getfirebug.com/) - Инструменты / FireBug / Inspect Element(cntrl+shift+c) / net / all
* Web Developer (www.websiteoptimization.com) - Tools / ViewSpeedReport
* LoadTimeAnalizer
было бы неплохо добавить к статье модули апача, которые должны быть включены и использовать директивы IfModule для наглядности в примерах...
респект, для
mod_rewrite добавил проверку, а как же конструкция Header set Content-Encoding: gzip? она же требует наличия включённого mod_header, который, кстати, по умолчанию выключен, как, впрочем, и mod_rewrite :)кстати последний виндовый сафари уже нормально работает с gzip закодированными джаваскриптами
Зачем такие сложности? mod_deflate уже отменили?
Спасибо огромное за статью, почерпнул для себя полезного!
Ошибка: С такой конфигурацией вы можете загружать сжатые версии ваших файлов на сервер и Apache сможет отдавать их заместо обычных, если сможет это сделать, при этом вам не придется менять теги или любые вызовы в веб-приложениях.
за место на рынке плотят, уж не сочтите за грубость ;)
Ошибка: С такой конфигурацией вы можете загружать сжатые версии ваших файлов на сервер и Apache сможет отдавать их заместо обычных, если сможет это сделать, при этом вам не придется менять теги или любые вызовы в веб-приложениях.
за место на рынке плотят, уж не сочтите за грубость ;)
похоже, есть опечатка.
нужно
<IfModule mod_headers.c>
нужно
<IfModule mod_headers.c>
написал на php скрипт для архивации css и js, дайте кармы запостю :)
Спасибо за статью.
Особенно порадовали проверки на уровне htaccess, спасибо, как то раз натыкались на проблему не работы gzip'а на Маках предыдущего поколения, а в том проекте это было очень важно, пришлось отменять gzip вообще :(
Не обошлось правда без пары опечаток:
1) «Поожите его в ту же директорию на сервере, что и исходный файл.» — Л пропустили
2) «В первой строке мы сообщаем серверу, что файлы с расширением .gz нужно отдавать с gzip encoding-type, чтобы браузер понял, что перед ним архив, а текстовый файл.», наверно все таки а не текстовый файл
P.S. Отличные статьи, стараюсь регулярно отслеживать новые. Благодаря вашей «CSS Sprites: все, что вы знали, но боялись спросить» освоил CSS Sprites технологию, сейчас применяю и радуюсь, все гениальное просто :)
Особенно порадовали проверки на уровне htaccess, спасибо, как то раз натыкались на проблему не работы gzip'а на Маках предыдущего поколения, а в том проекте это было очень важно, пришлось отменять gzip вообще :(
Не обошлось правда без пары опечаток:
1) «Поожите его в ту же директорию на сервере, что и исходный файл.» — Л пропустили
2) «В первой строке мы сообщаем серверу, что файлы с расширением .gz нужно отдавать с gzip encoding-type, чтобы браузер понял, что перед ним архив, а текстовый файл.», наверно все таки а не текстовый файл
P.S. Отличные статьи, стараюсь регулярно отслеживать новые. Благодаря вашей «CSS Sprites: все, что вы знали, но боялись спросить» освоил CSS Sprites технологию, сейчас применяю и радуюсь, все гениальное просто :)
Упссс, а куда это из сообщения все допустимые теги повырезало? :(
У Хабра глюки?
У Хабра глюки?
Никто не стыкался после применения показанного метода с рекурсией веб-сервера?
У меня сервер, если браузер клиента не поддерживает загрузку gzip-архивов впадает в рекурсию и сначала пытается загрузить prototype.nogzip.js, потом prototype.nogzip.nogzip.js и т.д., пока не уровень рекурсии не достигается.
Проблема очевидно в строках:
RewriteRule ^(.*)\.(css|js)$ $1.nogzip.$2 [QSA,L]
Кто-то стыкнулся с подобным? ;)
У меня сервер, если браузер клиента не поддерживает загрузку gzip-архивов впадает в рекурсию и сначала пытается загрузить prototype.nogzip.js, потом prototype.nogzip.nogzip.js и т.д., пока не уровень рекурсии не достигается.
Проблема очевидно в строках:
RewriteRule ^(.*)\.(css|js)$ $1.nogzip.$2 [QSA,L]
Кто-то стыкнулся с подобным? ;)
флаг L указывает на то, что этот редирект последний. По логам точно описанное поведение зафиксировано?
Точно. Я бы просто так не сказал бы об этом. Клиенты жаловались на то, что у них не подгружались цссники, я полдня убил на поиск причины, думал рекурсия у меня где-то в коде, а потом понял, что таки нет.
хмм, т.е. файла prototype.nogzip.js тупо нет? может быть, его положить нужно? или файл есть, а рекурсия все равно срабатывает? Просто это редирект внутренний, в логах будет отображаться тот же файл prototype.js (разница в размере).
Сейчас вырубил сжатие в Firefox, проверил на webo.in — произошло именно так (файлы с nogzip присутствуют).
У меня в конфиге написано
Сейчас вырубил сжатие в Firefox, проверил на webo.in — произошло именно так (файлы с nogzip присутствуют).
У меня в конфиге написано
RewriteEngine ON
RewriteCond %{HTTP:Accept-encoding} !gzip [OR]
RewriteCond %{HTTP_USER_AGENT} Konqueror
RewriteRule ^(.*)\.(css|js|xml)$ $1.ngz.$2 [QSA,L]ngz — эквивалент nogzipНет, файл prototype.nogzip.js был и есть. Рекурсия срабатывала всеравно…
У меня в конфиге все то, что написано в статье под заглавием «Google Chrome и прочий зоопарк».
У меня в конфиге все то, что написано в статье под заглавием «Google Chrome и прочий зоопарк».
вполне возможно, что тут уже вмешались различия ОСей. Попробуйте выставить
таким образом (по идее) редирект будет распространяться только на файлы, которые не содержат .nogzip в названии
Также возможно, что текущая конфигурация системы уже не чувствительна ко внутренним редиректам и перенаправляет их во внешние (это мне кажется более вероятным. чем различие по ОСям).
RewriteEngine ON
RewriteCond %{REQUEST_FILENAME} !.nogzip
RewriteCond %{HTTP:Accept-encoding} !gzip
RewriteRule ^(.*)\.(css|js)$ $1.nogzip.$2 [QSA,L]таким образом (по идее) редирект будет распространяться только на файлы, которые не содержат .nogzip в названии
Также возможно, что текущая конфигурация системы уже не чувствительна ко внутренним редиректам и перенаправляет их во внешние (это мне кажется более вероятным. чем различие по ОСям).
Цссники не отдавались, сервер отдавал с 500 кодом, в логах в это же время для этого же айпи высвечивалась проблема с рекурсией (коннектился телнетом и пытался стянуть 1 файлик).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Практический CSS/JS: архивируем все!