Pull to refresh

Comments 68

спасибо, хороший перевод и рассуждения. Надо попробовать :)
"В первой строке мы сообщаем серверу, что файлы с расширением .gz нужно отдавать с gzip encoding-type, чтобы браузер понял, что перед ним архив, а текстовый файл."

Нигде в фразе не ошиблись? ,)

Спасибо за перевод. Полезно.
Если интересно, CakePHP умеет сжимать CSS'ки на уровне фреймворка.
было бы интересно узнать ситуацию сейчас, когда уже 30-40% ходят под IE7, а IE5 почти не используется.
Сдается мне, что совместное применение ETag + Expires если не решает проблему, то помогает в 99% случаев (учитывая данное положение вещей в мире браузеров, год назад оно было несколько другое :)
Я замечал другую проблему с ИЕ, причем даже седьмым. При подключении через прокси-сервер, он отказывался понимать сжатые файлы. Сейчас уже плохо помню почему, но, кажись, прокся резала какой-то заголовок.
да, есть прокси вроде UserGate, которые по умолчанию не поддерживают HTTP 1.1
А еще в настройках IE нужно поставить "использовать HTTP 1.1 через прокси". по-умолчанию там галка не стоит.

По поводу статьи: перевод хороший, да и сама статья вполне полезная.
еще лучше перед отдачей gzip сжимать css и js убирая лишние пустые строки, комментарии и т.п. и потом сливать их в два файла (css и js) и отдавать уже его, но это надо на уровне движка реализовывать
В таком случае, малейшее изменение в каком-нибудь небольшом файле приведёт к очередной загрузке всего большого склеенного файла. Что не всегда хорошо. Тем более, когда идёт постоянная разработка, либо очередное обновление.
Такой момент есть. Но опять же...
Обычно система фиксируется на какой-то стабильной версии и дальше уже идут "пакетные" обновления, которые зачастую выходят достаточно нечасто и изменения затрагивают большой процент файлов.

Если анализируя еще глубже, то при обосновании перехода на такую систему необходимо смотреть какие пользователи вас посещают, что это за проект и какие изменения там планируются, как налажена система тестирования и т.п. Нюансов конечно много
Например, у меня сейчас в разработке CMS с фронтэндом на JavaScript. Там идет постоянная загрузка довольно больших скриптов. А основной скрипт вообще весит под 600 Кб. С моим каналом на 256 Кб/с сжатие не помешает...
frontend 600kb только скрипты? смело. Понимаю если это на backend'е
А нормально. До оптимизации было >1Мб. После оптимизации и сжатия их стало 160Кб ;-)

Учитывая кеширование, в процессе работы грузится совсем мало. На некоторые ответы сервера думаю прикрутить архивирование "на лету" (но это уже совсем мелочи). Так что даже с диалапом нормально заработает. Зато красиво и удобно.
Я бы голову за такое отрывал, если честно.
Везде, где можно отказаться от ДжаваСкипта, от него лучше отказываться.
Ну не знаю... Нормальная технология, если разумно использовать. Как еще можно реализовать такое (см. рис.1)? Тут JavaScript вдоль и поперек. И работает без проблем во всех современных браузерах.

Одминко

Редактирование структуры сайта простым перетаскиванием элементов, диалоговые окна свойств страниц, создание страницы в 2 клика, удобное редактирование материалов, человечные валидаторы данных, подсветка синтаксиса в редакторе шаблонов (XSLT), стилей (CSS) и модулей сайта (Parser, php) и т.д.
UFO landed and left these words here
Видимо, затем, зачем и любое другое сжатие. Чтобы занимало меньше место и, соответственно, быстрее передавалось/ело меньше трафика.
я сначала применял технику описываемую автором статьи у себя в приложениях. поначалу прикольно, а потом понял, что неудобно совсем. если нужно поменять буковку в скрипте &mdash снова надо "гзипить".

мой совет &mdash пользуйтесь кешем!
грамотно настроив mod_expires (напр., хранить в кеше в течении года) и внедрив технику версий файлов в имени самого файла &mdash отпали вообще все проблемы. экономится трафик, время рендеринга &mdash пользователь доволен. если мне нужно поменять скрипт или стили, сохранив изменения, я повышаю версию. имена файлов выглядят так: "script_v1.0.5.js".
единственная проблема в таком подходе &mdash при смене имени файла, нужно найти и поменять его во всех местах, где он подключается. для простых проектов элементарно решается через "Find in Files..."
если 95%...99% пользователей приходят в первый раз, то... ну сами понимаете :)
товарищи, если я говорю, что нужно использовать кеш, то это не значит что не нужно ставить mod_gzip, который при первом посещении и выдаст клиенту сжатый файл.
автоматизированными средствами кто это сделать мешает? (find . -name *.css ...)
не мешает, а даже помогает.
в таком случае я не могу использовать кеш по полной программе, так как имя файла одно и тоже.
А это делается методами file.css.gz?20070820 и делается на уровне фреймворка.
я против таких методов, этот файл не попадёт в кеш.
мне даже процессорного времени жалко на генерацию разного URL ;-)
с чего это вдруг он не попадёт в кэш? и какой кэш имеется ввиде? серверный или клиентско-браузерный?
клиентско-браузерный. не буду спорить не зная хедеров, но в 99% случаев никто их и не настраивает.
фреймворк это делает сам?
иной раз даже надоедает ctrl+f5 жамкать, чтобы освежить после изменений на сервере
значит в хедерах прописано хорошо.
Firefox через WebDeveloper позволяет элементарно отключить кеш на время (самое первое меню, первая позиция). тоже самое можно проделать с IE и Opera через настройки.
ну ладно в файрфоксе, эт мы в курсе, но не одним же файрфоксом жив веб-девелопер, есть же ещё всяческие интырнет эксплореры, оперы, сафари, конкваеры, запаришься у них по меню лазать :) проще контрол придержать (правда в сафари эта комбинация не работает, достаточно F5)
хабралюди, занятые в вебе, пожалуйста, объясните мне, почему никто не пользуется промежуточным буфером с быстрым доступом, который хранит в себе ту информацию, которая с наибольшей вероятностью может быть запрошена и называется кеш?
в своих приложениях я всегда пользуюсь им, где только возможно.

я сейчас на собственной шкуре страдаю от этого.
в израиле у меня анлим 5 мбит/сек (напр, 1.5 мбит/сек стоит 25 долларов) и то, я матерюсь на страницы "без кеша", потому как я сам в этой теме, и мне просто не понятно: почему во всех распространённых браузерах есть такая функция, страницы реально открываются быстрее... и не использовать её?
я родился в небольшом городе в сибири, куда интернет ещё не дошёл, чтобы называть его доступным (по деньгам) рядовым жителям. сейчас на месяц приехал сюда... по модему соединение 19 кбит/с, GPRS — 56кбит/с оооочень редко. выделенку местную на месяц ставить не буду.

и я жду пока откроются одноклассники (потому, что только туда записались мои друзья), майл.ру (те же друзья хранят свои фотографии) и в том же духе другие популярные сайты... мне просто стыдно за девелоперов, в руках столько технологий, а для кого они?
А есть уверенность, что сжатие "на лету" небольшой библиотеки с учетом того, что для каждого пользователя оно будет производится один раз (потом берется из кэша) будет более ресурсоёмко, чем достаточно сложная mod_rewrite-обработка, особенно в .htaccess?
про .htaccess я писал немного: я против его использования. А любое сжатие на лету — это процессорное время. Я не понимаю, зачем его каждый раз тратить. Другой вопрос, когда у вас ненагруженный проект, всего один внешний JS-файл, например, и есть желание "покодить"... Иначе — только статика!
что страшного в mod_rewrite?
если можно с примерами и ссылками с тестированием
UFO landed and left these words here
UFO landed and left these words here
по-моему все проще :)
тк есть соощения о проблемах со сжатыми файлами на IE и проблемы с маковскими браузерами, то идея коотрой я пользуюсь - это при деплойменте пакую js\css не архиваторами а оптимизаторами кода. за исключением prototype.js + script.aculo.us которые были взяты из спец.архива, который был оптимизирован не мной :)

и да, повторюсь - это все деплойменте, поэтому разработка идет без проблем, перед выкладыванием на production софт выкладыывается на pred-production, чтобы на всякий случай проверить качество сжатия методом научного тыка. но пока проблем не было :)
У меня около года используется подход почти 1 в 1 с тем, что описан автором. Вполне себе работает и не жужжит :)
За проверку поддержки клиентом encoding-а на уровне htaccess отдельный респект.
Ещё есть один минус — все сжатые файлы полученные с сервера так и хранятся в кеше в сжатом виде, и при каждом обращении к ресурсу распаковываются :)
Из за этого на быстрых каналах или медленных машинах тормоза распаковки, превышают тормоза загрузки. Актуально для систем с множеством 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
было бы неплохо добавить к статье модули апача, которые должны быть включены и использовать директивы IfModule для наглядности в примерах...
респект, для mod_rewrite добавил проверку, а как же конструкция Header set Content-Encoding: gzip? она же требует наличия включённого mod_header, который, кстати, по умолчанию выключен, как, впрочем, и mod_rewrite :)
кстати последний виндовый сафари уже нормально работает с gzip закодированными джаваскриптами
лишний раз сервер чтобы не нагружать. Сейчас как раз готовлю аналитический материал на тему серверных нагрузок при архивировании
Спасибо огромное за статью, почерпнул для себя полезного!

Ошибка: С такой конфигурацией вы можете загружать сжатые версии ваших файлов на сервер и Apache сможет отдавать их заместо обычных, если сможет это сделать, при этом вам не придется менять теги или любые вызовы в веб-приложениях.

за место на рынке плотят, уж не сочтите за грубость ;)
похоже, есть опечатка.
нужно
<IfModule mod_headers.c>
написал на php скрипт для архивации css и js, дайте кармы запостю :)
Спасибо за статью.
Особенно порадовали проверки на уровне 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]

Кто-то стыкнулся с подобным? ;)

флаг L указывает на то, что этот редирект последний. По логам точно описанное поведение зафиксировано?
Точно. Я бы просто так не сказал бы об этом. Клиенты жаловались на то, что у них не подгружались цссники, я полдня убил на поиск причины, думал рекурсия у меня где-то в коде, а потом понял, что таки нет.
хмм, т.е. файла prototype.nogzip.js тупо нет? может быть, его положить нужно? или файл есть, а рекурсия все равно срабатывает? Просто это редирект внутренний, в логах будет отображаться тот же файл prototype.js (разница в размере).

Сейчас вырубил сжатие в 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 и прочий зоопарк».
вполне возможно, что тут уже вмешались различия ОСей. Попробуйте выставить
RewriteEngine ON
RewriteCond %{REQUEST_FILENAME} !.nogzip
RewriteCond %{HTTP:Accept-encoding} !gzip
RewriteRule ^(.*)\.(css|js)$ $1.nogzip.$2 [QSA,L]


таким образом (по идее) редирект будет распространяться только на файлы, которые не содержат .nogzip в названии

Также возможно, что текущая конфигурация системы уже не чувствительна ко внутренним редиректам и перенаправляет их во внешние (это мне кажется более вероятным. чем различие по ОСям).
Там у нас Fedora.

Так или иначе — это помогло :)

Может стоит внести в статью, ведь может кто-то еще наткнется…?

Спасибо за помощь :)
это хорошо, что диагноз оказался правильным :)
В статью включу обязательно — просто сразу не подумал, что могут быть и такие случаи
Предугадать все — невозможно. Поэтому тут не то, чтобы «не подумал», а скорее — «кто ж его знал, что такое возможно» :)
да нет. Я-то знал, что такое возможно: сталкивался с неработоспособностью внутренних редиректов. Просто на новом проекте уже забыл о таком :)
Цссники не отдавались, сервер отдавал с 500 кодом, в логах в это же время для этого же айпи высвечивалась проблема с рекурсией (коннектился телнетом и пытался стянуть 1 файлик).
Only those users with full accounts are able to leave comments. Log in, please.