Страница:
Для небольших наборов CSS и JavaScript такой подход может замедлить обработку первого запроса (в сравнении с «монолитным» подходом), но если сохранять количество компонентов на относительно низком уровне, то возможно и ускорение работы, поскольку в расчете на одну страницу приходится загружать меньше данных.
Accept-Encoding: gzip,deflate
Видя такой заголовок, сервер сжимает отсылаемое содержимое методами gzip или deflate с тем, чтобы клиент распаковал его на месте. Это загружает процессор как на клиенте, так и на сервере, однако уменьшает объем передаваемых данных. Это нормально. Однако вот как работает mod_gzip: он сжимает данные во временный файл на диске, а после отсылки данных удаляет этот файл. На больших системах вы очень быстро столкнетесь с ограничениями скорости ввода/вывода. Этого можно избежать, используя вместо mod_gzip mod_deflate (только в Apache 2), поскольку последний сжимает данные в оперативной памяти. Пользователи первой версии Apache могут создать RAM-диск и хранить временные файлы mod_gzip там — это не так быстро, как работа напрямую с оперативкой, но намного шустрее, чем писать все на жесткий диск.
Но даже без этого мы можем полностью избежать вышеописанных проблем, используя предварительное сжатие нужных статических ресурсов и последующую отправку их клиенту с помощью mod_gzip. Если добавить предварительное сжатие в сборку билда, то сам процесс пройдет для нас совершенно незаметно. Файлов, требующих упаковки, обычно не так уж много — мы не сжимаем изображения (поскольку это вряд ли приведет хоть к какой-то экономии — изображения и так уже достаточно сжаты), так что нам остается упаковать JavaScript, CSS и прочий статический контент. Но мы должны указать mod_gzip, где искать файлы для предварительной компрессии:
mod_gzip_can_negotiate Yes
mod_gzip_static_suffix .gz
AddEncoding gzip .gz
В последних версиях mod_gzip (от 1.3.26.1a и выше) для автоматической предварительной упаковки файлов в конфигурационных опциях достаточно добавить одну строчку. Нужно лишь удостовериться, что в Apache установлены корректные разрешения на создание и перезапись упакованных файлов.
mod_gzip_update_static Yes
Но не все так просто. Текущие версии Netscape 4 (точнее, 4.06—4.08) в заголовке утверждают, что понимают содержимое, сжатое с помощью gzip, однако, на самом деле, не умеют распаковывать эти архивы. Прочие версии Netscape 4 тоже испытывают разнообразные трудности с загрузкой сжатых скриптов и стилей. А значит, мы должны отсекать этих агентов на стороне сервера и подставлять им неупакованный контент. Это довольно просто. Куда интереснее проблемы, возникающие у Internet Explorer (версии с 4 по 6).
Загружая сжатый с помощью gzip JavaScript, Internet Explorer порой некорректно распаковывает его или прерывает распаковку в процессе, отдавая клиенту половину файла. Если для вас критична работоспособность JavaScript, вы должны избегать отсылки сжатых скриптов по запросу IE. Даже в тех случаях, когда IE способен загрузить сжатый JavaScript, он зачастую не кэширует его, независимо от указаний, записанных в тегах (актуально для некоторых версий IE 5.x).
Поскольку сжатие с помощью gzip иногда выходит себе дороже, мы можем обратиться к другим способам упаковки контента, не предполагающих смену формата. Сейчас доступно множество скриптов, сжимающих JavaScript, большая часть которых использует для уменьшения исходного кода наборы правил на основе регулярных выражений. С их помощью мы действительно можем сделать код меньше, удалив комментарии, лишние пробелы, сократив имена переменных и убрав необязательные синтаксические конструкции.
К сожалению, подавляющее большинство этих скриптов либо не слишком эффективны, либо в определенных случаях разрушают код (а иногда — и то и другое вместе). Без подробного грамматического разбора упаковщику трудно отличить комментарий от похожей конструкции, размещенной в закавыченной строке. Кроме того, с помощью регулярных выражений не так-то просто оценить, какая из переменных имеет ограниченный контекст, так что некоторые техники сокращения имен переменных могут разрушить сам код.
Этих проблем можно избежать, сжимая код с помощью Dojo Compressor (alex.dojotoolkit.org/shrinksafe), использующий Rhino (мозилловский JavaScript-движок, написанный на Java) для построения дерева, которое оптимизируется перед работой с файлами. С работой Dojo Compressor справляется неплохо, ресурсов отнимает немного. Расширив наш процесс сборки билда с помощью этого инструмента, мы можем забыть об экономии, писать пространные комментарии, вставлять сколько угодно пробелов и т. д. На рабочем коде это нисколько не отразится.
По сравнению с JavaScript CSS упаковывать легко. Поскольку в стилях практически не используются закавыченные строки (как правило, это пути или названия шрифтов), мы можем справиться с пробелами с помощью регулярных выражений. Если же у нас закавыченные строчки все же есть, мы почти всегда можем свести последовательности пробелов к одному пробелу (маловероятно, что последовательности, состоящие из нескольких пробелов, встретятся нам в указаниях путей или названиях шрифтов). Для этого нам вполне хватит простенького скрипта на Perl:
#!/usr/bin/perl
my $data = ‘’;
open F, $ARGV[0] or die «Can’t open source file: $!»;
$data .= $_ while <F>;
$data =~ s!/*(.*?)*/!!g; # remove comments
$data =~ s!s+! !g; # collapse space
$data =~ s!} !}n!g; # add line breaks
$data =~ s!n$!!; # remove last break
$data =~ s! { ! {!g; # trim inside brackets
$data =~ s!; }!}!g; # trim inside brackets
print $data;
«Скормим» этому скрипту все имеющиеся у нас CSS по очереди:
perl compress.pl site.source.css > site.compress.css
С помощью такой несложной оптимизации мы можем уменьшить объем передаваемых данных на 50 процентов (во многом это зависит от вашего стиля кодирования — выигрыш может быть и гораздо меньше), а значит, увеличить скорость работы конечного пользователя. Но в идеале нам хотелось бы, чтобы пользователи вообще не запрашивали файлы до тех пор, пока это не станет совершенно необходимо. И для этого нам придется заняться HTTP-кэшированием.
Вы посылаете заголовки, запрещающие кэширование динамических страниц, чтобы не позволить браузеру кэшировать страницы, которые постоянно изменяются. В PHP это делается с помощью одной строчки:
header(«Cache-Control: private»);
Слишком просто, чтобы быть правдой? Ну, в общем-то, да — некоторые агенты порой игнорируют этот заголовок. Чтобы по-настоящему запретить браузеру кэшировать документ, следует быть немного более убедительным:
# ‘Expires’ in the past
header(«Expires: Mon, 26 Jul 1997 05:00:00 GMT»);
# Always modified
header(«Last-Modified: „.gmdate(„D, d M Y H:i:s“).“ GMT»);
# HTTP/1.1
header(«Cache-Control: no-store, no-cache, must-revalidate»);
header(«Cache-Control: post-check=0, pre-check=0», false);
# HTTP/1.0
header(«Pragma: no-cache»);
Это годится для контента, который мы не хотим кэшировать, но если контент не меняется при каждом запросе, нам нужно добиться от браузера обратного поведения. Для этого в заголовке запроса используется конструкция If-Modified-Since. Получив такой запрос, Apache (или любой другой веб-сервер) может выдать код 304 (Not Modified), тем самым сообщая браузеру, что у того в кэше уже находится актуальная версия документа. Благодаря этому механизму, нам не приходится пересылать файл заново, однако лишний запрос обрабатывать все же пришлось. Гм.
Использование entity tags похоже на работу с конструкцией if-modified-since. Apache на запрос к статическому ресурсу может отдавать заголовок Etag, содержащий контрольную сумму, сгенерированную из размера файла, времени последнего изменения и номера индексного дескриптора. Браузер может запросить заголовок файла, чтобы проверить e-tag документа перед загрузкой. Очевидно, что использование e-tag сопряжено с теми же накладными расходами, что и механизм if-modified-since, — клиент все еще вынужден делать лишний HTTP-запрос, чтобы определить валидность локальной копии.
Кроме того, нужно соблюдать осторожность с if-modified-since и e-tags, если выдача контента идет с нескольких серверов. В системе из двух хорошо сбалансированных серверов любой документ может быть запрошен одним и тем же агентом с любого из двух серверов — или с каждого (не одновременно). Это нормально. Для этого мы и выравнивали нагрузку. Однако если серверы генерируют разные e-tags или разные даты изменения документов, браузер не сможет нормально поддерживать актуальный кэш. По умолчанию e-tag генерируются с использованием индексных дескрипторов, которые на разных серверах разные. Это можно запретить с помощью следующей опции в настройках Apache:
FileETag MTime Size
Теперь Apache для генерации e-tag будет использовать только время последнего изменения и размер файла. Это, к сожалению, приводит нас к другой проблеме использования e-tag, которая тоже актуальна для if-modified-since (хоть и в меньшей степени). Поскольку e-tag зависит от времени последнего изменения, нам необходимо следить за синхронизацией. Если мы распределяем файлы по разным веб-серверам, всегда остается шанс, что на один из серверов файл попадет на секунду или две позже, чем на другой. В этом случае e-tag, сгенерированные серверами, будут отличаться. Мы можем изменить настройки так, чтобы генерировать e-tag только на основании размера файла, но это означает, что файл не обновится в браузере, если мы изменим его содержимое, а размер останется неизменным. Тоже не идеально.
Или все же слегка иначе? Ведь перед отправкой любых JavaScript— или CSS-файлов клиент запрашивает страницу, которая на них ссылается с помощью тегов <script> и <link>. И мы можем использовать реакцию сервера для информирования клиентов о любых изменениях, произошедших с этими ресурсами. Звучит немного загадочно, поэтому скажу прямо: если мы будем изменять названия JavaScript— и CSS-файлов при каждом изменении их содержания, то сможем разрешить клиенту хранить их в кэше вечно (ведь содержимое файла по отдельно взятому адресу не меняется).
Если мы уверены в том, что конкретный ресурс никогда не изменится, то можем отправить несколько по-настоящему агрессивных заголовков. В PHP нам потребуется всего пара строк:
header(«Expires: „.gmdate(„D, d M Y H:i:s“, time()+315360000).“ GMT»);
header(«Cache-Control: max-age=315360000»);
Так мы говорим браузеру, что содержимое файла останется неизменным в течение десяти лет (т.е. плюс-минус 315 360 000 секунд), поэтому, единожды загрузив файл, браузер может следующие десять лет использовать локальную копию. Конечно, необязательно использовать для отправки JavaScript и CSS именно PHP. Мы перейдем к этому через несколько минут.
На наше счастье, компьютеры с такими задачами — тупым повторением одних и тех же операций при совпадении определенных условий — справляются отменно.
Чтобы сделать этот процесс максимально безболезненным, следует для начала уяснить, что нам вообще не нужно переименовывать файлы. Между реальным расположением файла на диске и URL, с которого он доставляется пользователю, нет ничего общего. Так что в случае Apache мы можем использовать mod_rewrite, создав простое правило для редиректа определенных URL к нужным файлам:
RewriteEngine on
RewriteRule ^/(.*.)v[0-9.]+.(css|js|gif|png|jpg)$ /$1$2 [L]
Это правило обрабатывает все URL с указанными расширениями, которые также содержат суффикс версии. В процессе обработки правило переписывает URL так, чтобы он указывал на путь к нужному файлу (исключая при этом суффикс). Например:
foo.v2.gif foo.gif
/css/main.v1.27.css css/main.css
/javascript/md5.v6.js /javascript/md5.js
Когда это правило работает, мы можем менять URL (добавляя к нему суффикс версии), не меняя расположения файла на диске. Обнаружив, что URL изменился, браузер считает, что ему нужно обратиться к новому ресурсу.
Вы можете поинтересоваться, почему мы просто-напросто не использовали динамические ссылки (например, /css/main.css?v=4)? Дело в том, что, согласно спецификации HTTP, пользовательские агенты вообще не должны кэшировать такие URL. И хотя IE и Firefox это игнорируют, Opera и Safari точно следуют букве — поэтому, чтобы гарантировать корректную работу всех браузеров при кэшировании наших ресурсов, мы избегаем использовать динамические ссылки.
Теперь, когда мы научились менять URL без перемещения файла, было бы неплохо автоматизировать обновление URL. В небольшой рабочей среде (или в среде разработки, для тех, кому приходится иметь дело с большими рабочими средами) это довольно легко осуществить с помощью функций шаблона. Следующий пример сделан на основе Smarty, но может быть реализован и на основе других подобных движков:
<link l:href="{version src=’/css/group.css’}" rel="stylesheet" type="text/css" />
function smarty_version($args){
$stat = stat($GLOBALS[‘config’][‘site_root’].$args[‘src’]);
$version = $stat[‘mtime’];
echo preg_replace(‘!.([a-z]+?)$!’, «.v$version.$1», $args[‘src’]);
<link l:href="/css/group.v1234567890.css" rel="stylesheet" type="text/css" />
Для каждого залинкованного ресурса мы определяем местоположение файла на диске, проверяем его mtime (дату последнего изменения) и вставляем эту информацию в URL в виде номера версии. Это прекрасно работает на сайтах с низким трафиком (где метод stat, возвращающий информацию о файлах и каталогах, обходится довольно дешево) и в среде разработчика, однако плохо масштабируется на большие сайты, поскольку каждый вызов stat означает обращение к диску на чтение.
Решить эту проблему нетрудно. В больших системах у нас изначально есть номер версии для каждого ресурса в виде номера, присвоенного системой контроля версий (вы же используете систему контроля версий, правда?). На этапе финального построения нашего сайта требуется лишь проверить номера версий всех нужных файлов и записать их в статический конфигурационный файл.
$GLOBALS[‘config’][‘resource_versions’] = array(
‘foo.gif’ => ‘2.1’,
‘/css/main.css’ => ‘1.27’,
‘/javascript/md5.js’ => ‘6.1.4’,
Затем мы меняем нашу функцию в шаблоне, чтобы она могла использовать эти номера версий при реальной работе.
function smarty_version($args){
if ($GLOBALS[‘config’][‘is_dev_site’]){
$stat = stat($GLOBALS[‘config’][‘site_root’].$args[‘src’]);
$version = $stat[‘mtime’];
$version = $GLOBALS[‘config’][‘resource_versions’][$args[‘src’]];
echo preg_replace(‘!.([a-z]+?)$!’, «.v$version.$1», $args[‘src’]);
Таким образом, нам не нужно переименовывать файлы или даже запоминать, когда мы изменяли их содержимое, — URL автоматически будут изменяться каждый раз, когда мы перерабатываем сайт. В общем, почти приехали.
Использовать для нашей цели PHP нетрудно. Мы просто должны изменить правила rewrite для статических файлов, чтобы они проходили через PHP-скрипт, и написать сам скрипт, который будет выдавать нужные заголовки, перед тем как передать эти файлы по запросу.
RewriteRule ^/(.*.)v[0-9.]+.(css|js|gif|png|jpg)$ /redir.php?path=$1$2 [L]
header(«Expires: „.gmdate(„D, d M Y H:i:s“, time()+315360000).“ GMT»);
header(«Cache-Control: max-age=315360000»);
# ignore paths with a ‘..’
if (preg_match(‘!..!’, $_GET[path])){ go_404(); }
# make sure our path starts with a known directory
if (!preg_match(‘!^(javascript|css|images)!’, $_GET[path])){ go_404(); }
# does the file exist?
if (!file_exists($_GET[path])){ go_404(); }
# output a mediatype header
$ext = array_pop(explode(‘.’, $_GET[path]));
switch ($ext){
case ‘css’:
header(«Content-type: text/css»);
case ‘js’ :
header(«Content-type: text/javascript»);
case ‘gif’:
header(«Content-type: image/gif»);
case ‘jpg’:
header(«Content-type: image/jpeg»);
case ‘png’:
header(«Content-type: image/png»);
header(«Content-type: text/plain»);
# echo the file’s contents
echo implode(‘’, file($_GET[path]));
function go_404(){
header(«HTTP/1.0 404 File not found»);
Несмотря на то что такой подход работает, это не лучшее решение. PHP в сравнении с Apache требует больше памяти и времени на исполнение. Кроме того, нам необходимо соблюдать осторожность из-за возможных эксплойтов. Дабы избежать всей этой головной боли, мы можем попытаться использовать Apache напрямую. Директива RewriteRule позволяет нам устанавливать значения переменных окружения при срабатывании директивы, тогда как директива Header добавляет заголовки лишь в том случае, когда присвоенно значение заданной переменной. Комбинируя две эти директивы, мы легко можем составить нужную цепочку инструкций:
RewriteEngine on
RewriteRule ^/(.*.)v[0-9.]+.(css|js|gif|png|jpg)$ /$1$2 [L,E=VERSIONED_FILE:1]
Header add «Expires» «Mon, 28 Jul 2014 23:30:00 GMT» env=VERSIONED_FILE
Header add «Cache-Control» «max-age=315360000» env=VERSIONED_FILE
Из-за порядка исполнения Apache, мы должны добавить строчку Re-writeRule в главный конфигурационный файл (httpd.conf), а не в .htaccess, иначе строчки Header будут исполнены первыми, перед установкой переменной окружения. Сами строчки Header могут быть размещены и в главном конфигурационном файле, и в .htaccess — их местоположение ни на что не влияет.
Сокращенный перевод.
© 2006 Carson Systems, Vitamin
Оригинал: www.thinkvitamin.com/features/webapps/serving-javascript-fast
РЫНКИ: Ну и как тебя называть?
Сжатие
Когда речь заходит о сжатии, многие немедленно вспоминают mod_gzip. Однако с ним нужно соблюдать осторожность — mod_gzip, в общем-то, является злом или, по меньшей мере, причиной кошмарного расходования ресурсов. Основная идея сжатия проста. Браузеры, запрашивая ресурсы, указывают в заголовке, в каком виде они могут принять содержимое страницы. Это может выглядеть, например, так:Accept-Encoding: gzip,deflate
Видя такой заголовок, сервер сжимает отсылаемое содержимое методами gzip или deflate с тем, чтобы клиент распаковал его на месте. Это загружает процессор как на клиенте, так и на сервере, однако уменьшает объем передаваемых данных. Это нормально. Однако вот как работает mod_gzip: он сжимает данные во временный файл на диске, а после отсылки данных удаляет этот файл. На больших системах вы очень быстро столкнетесь с ограничениями скорости ввода/вывода. Этого можно избежать, используя вместо mod_gzip mod_deflate (только в Apache 2), поскольку последний сжимает данные в оперативной памяти. Пользователи первой версии Apache могут создать RAM-диск и хранить временные файлы mod_gzip там — это не так быстро, как работа напрямую с оперативкой, но намного шустрее, чем писать все на жесткий диск.
Но даже без этого мы можем полностью избежать вышеописанных проблем, используя предварительное сжатие нужных статических ресурсов и последующую отправку их клиенту с помощью mod_gzip. Если добавить предварительное сжатие в сборку билда, то сам процесс пройдет для нас совершенно незаметно. Файлов, требующих упаковки, обычно не так уж много — мы не сжимаем изображения (поскольку это вряд ли приведет хоть к какой-то экономии — изображения и так уже достаточно сжаты), так что нам остается упаковать JavaScript, CSS и прочий статический контент. Но мы должны указать mod_gzip, где искать файлы для предварительной компрессии:
mod_gzip_can_negotiate Yes
mod_gzip_static_suffix .gz
AddEncoding gzip .gz
В последних версиях mod_gzip (от 1.3.26.1a и выше) для автоматической предварительной упаковки файлов в конфигурационных опциях достаточно добавить одну строчку. Нужно лишь удостовериться, что в Apache установлены корректные разрешения на создание и перезапись упакованных файлов.
mod_gzip_update_static Yes
Но не все так просто. Текущие версии Netscape 4 (точнее, 4.06—4.08) в заголовке утверждают, что понимают содержимое, сжатое с помощью gzip, однако, на самом деле, не умеют распаковывать эти архивы. Прочие версии Netscape 4 тоже испытывают разнообразные трудности с загрузкой сжатых скриптов и стилей. А значит, мы должны отсекать этих агентов на стороне сервера и подставлять им неупакованный контент. Это довольно просто. Куда интереснее проблемы, возникающие у Internet Explorer (версии с 4 по 6).
Загружая сжатый с помощью gzip JavaScript, Internet Explorer порой некорректно распаковывает его или прерывает распаковку в процессе, отдавая клиенту половину файла. Если для вас критична работоспособность JavaScript, вы должны избегать отсылки сжатых скриптов по запросу IE. Даже в тех случаях, когда IE способен загрузить сжатый JavaScript, он зачастую не кэширует его, независимо от указаний, записанных в тегах (актуально для некоторых версий IE 5.x).
Поскольку сжатие с помощью gzip иногда выходит себе дороже, мы можем обратиться к другим способам упаковки контента, не предполагающих смену формата. Сейчас доступно множество скриптов, сжимающих JavaScript, большая часть которых использует для уменьшения исходного кода наборы правил на основе регулярных выражений. С их помощью мы действительно можем сделать код меньше, удалив комментарии, лишние пробелы, сократив имена переменных и убрав необязательные синтаксические конструкции.
К сожалению, подавляющее большинство этих скриптов либо не слишком эффективны, либо в определенных случаях разрушают код (а иногда — и то и другое вместе). Без подробного грамматического разбора упаковщику трудно отличить комментарий от похожей конструкции, размещенной в закавыченной строке. Кроме того, с помощью регулярных выражений не так-то просто оценить, какая из переменных имеет ограниченный контекст, так что некоторые техники сокращения имен переменных могут разрушить сам код.
Этих проблем можно избежать, сжимая код с помощью Dojo Compressor (alex.dojotoolkit.org/shrinksafe), использующий Rhino (мозилловский JavaScript-движок, написанный на Java) для построения дерева, которое оптимизируется перед работой с файлами. С работой Dojo Compressor справляется неплохо, ресурсов отнимает немного. Расширив наш процесс сборки билда с помощью этого инструмента, мы можем забыть об экономии, писать пространные комментарии, вставлять сколько угодно пробелов и т. д. На рабочем коде это нисколько не отразится.
По сравнению с JavaScript CSS упаковывать легко. Поскольку в стилях практически не используются закавыченные строки (как правило, это пути или названия шрифтов), мы можем справиться с пробелами с помощью регулярных выражений. Если же у нас закавыченные строчки все же есть, мы почти всегда можем свести последовательности пробелов к одному пробелу (маловероятно, что последовательности, состоящие из нескольких пробелов, встретятся нам в указаниях путей или названиях шрифтов). Для этого нам вполне хватит простенького скрипта на Perl:
#!/usr/bin/perl
my $data = ‘’;
open F, $ARGV[0] or die «Can’t open source file: $!»;
$data .= $_ while <F>;
$data =~ s!/*(.*?)*/!!g; # remove comments
$data =~ s!s+! !g; # collapse space
$data =~ s!} !}n!g; # add line breaks
$data =~ s!n$!!; # remove last break
$data =~ s! { ! {!g; # trim inside brackets
$data =~ s!; }!}!g; # trim inside brackets
print $data;
«Скормим» этому скрипту все имеющиеся у нас CSS по очереди:
perl compress.pl site.source.css > site.compress.css
С помощью такой несложной оптимизации мы можем уменьшить объем передаваемых данных на 50 процентов (во многом это зависит от вашего стиля кодирования — выигрыш может быть и гораздо меньше), а значит, увеличить скорость работы конечного пользователя. Но в идеале нам хотелось бы, чтобы пользователи вообще не запрашивали файлы до тех пор, пока это не станет совершенно необходимо. И для этого нам придется заняться HTTP-кэшированием.
Твой друг кэш
Когда пользовательский агент запрашивает данные с сервера первый раз, он кэширует ответ, чтобы избегать повторных запросов в будущем. Как долго будет храниться этот кэш, зависит от двух факторов — настроек агента и соответствующих заголовков с сервера. Опции настройки агентов имеют незначительные различия, однако большинство из них сохраняет кэш по меньшей мере до окончания сессии, если им прямо не указано обратное.Вы посылаете заголовки, запрещающие кэширование динамических страниц, чтобы не позволить браузеру кэшировать страницы, которые постоянно изменяются. В PHP это делается с помощью одной строчки:
header(«Cache-Control: private»);
Слишком просто, чтобы быть правдой? Ну, в общем-то, да — некоторые агенты порой игнорируют этот заголовок. Чтобы по-настоящему запретить браузеру кэшировать документ, следует быть немного более убедительным:
# ‘Expires’ in the past
header(«Expires: Mon, 26 Jul 1997 05:00:00 GMT»);
# Always modified
header(«Last-Modified: „.gmdate(„D, d M Y H:i:s“).“ GMT»);
# HTTP/1.1
header(«Cache-Control: no-store, no-cache, must-revalidate»);
header(«Cache-Control: post-check=0, pre-check=0», false);
# HTTP/1.0
header(«Pragma: no-cache»);
Это годится для контента, который мы не хотим кэшировать, но если контент не меняется при каждом запросе, нам нужно добиться от браузера обратного поведения. Для этого в заголовке запроса используется конструкция If-Modified-Since. Получив такой запрос, Apache (или любой другой веб-сервер) может выдать код 304 (Not Modified), тем самым сообщая браузеру, что у того в кэше уже находится актуальная версия документа. Благодаря этому механизму, нам не приходится пересылать файл заново, однако лишний запрос обрабатывать все же пришлось. Гм.
Использование entity tags похоже на работу с конструкцией if-modified-since. Apache на запрос к статическому ресурсу может отдавать заголовок Etag, содержащий контрольную сумму, сгенерированную из размера файла, времени последнего изменения и номера индексного дескриптора. Браузер может запросить заголовок файла, чтобы проверить e-tag документа перед загрузкой. Очевидно, что использование e-tag сопряжено с теми же накладными расходами, что и механизм if-modified-since, — клиент все еще вынужден делать лишний HTTP-запрос, чтобы определить валидность локальной копии.
Кроме того, нужно соблюдать осторожность с if-modified-since и e-tags, если выдача контента идет с нескольких серверов. В системе из двух хорошо сбалансированных серверов любой документ может быть запрошен одним и тем же агентом с любого из двух серверов — или с каждого (не одновременно). Это нормально. Для этого мы и выравнивали нагрузку. Однако если серверы генерируют разные e-tags или разные даты изменения документов, браузер не сможет нормально поддерживать актуальный кэш. По умолчанию e-tag генерируются с использованием индексных дескрипторов, которые на разных серверах разные. Это можно запретить с помощью следующей опции в настройках Apache:
FileETag MTime Size
Теперь Apache для генерации e-tag будет использовать только время последнего изменения и размер файла. Это, к сожалению, приводит нас к другой проблеме использования e-tag, которая тоже актуальна для if-modified-since (хоть и в меньшей степени). Поскольку e-tag зависит от времени последнего изменения, нам необходимо следить за синхронизацией. Если мы распределяем файлы по разным веб-серверам, всегда остается шанс, что на один из серверов файл попадет на секунду или две позже, чем на другой. В этом случае e-tag, сгенерированные серверами, будут отличаться. Мы можем изменить настройки так, чтобы генерировать e-tag только на основании размера файла, но это означает, что файл не обновится в браузере, если мы изменим его содержимое, а размер останется неизменным. Тоже не идеально.
Твой лучший друг кэш
Дело в том, что мы подходим к проблеме не с той стороны. Все возможные стратегии кэширования отталкиваются от того, что клиент спрашивает сервер, насколько актуальна копия, хранимая в кэше. Если бы сервер сам, без запроса, сообщал клиенту об изменениях файлов, то клиент в любой момент времени знал бы, что кэшированная копия валидна. Но веб устроен иначе — клиент запрашивает сервер, и никак иначе.Или все же слегка иначе? Ведь перед отправкой любых JavaScript— или CSS-файлов клиент запрашивает страницу, которая на них ссылается с помощью тегов <script> и <link>. И мы можем использовать реакцию сервера для информирования клиентов о любых изменениях, произошедших с этими ресурсами. Звучит немного загадочно, поэтому скажу прямо: если мы будем изменять названия JavaScript— и CSS-файлов при каждом изменении их содержания, то сможем разрешить клиенту хранить их в кэше вечно (ведь содержимое файла по отдельно взятому адресу не меняется).
Если мы уверены в том, что конкретный ресурс никогда не изменится, то можем отправить несколько по-настоящему агрессивных заголовков. В PHP нам потребуется всего пара строк:
header(«Expires: „.gmdate(„D, d M Y H:i:s“, time()+315360000).“ GMT»);
header(«Cache-Control: max-age=315360000»);
Так мы говорим браузеру, что содержимое файла останется неизменным в течение десяти лет (т.е. плюс-минус 315 360 000 секунд), поэтому, единожды загрузив файл, браузер может следующие десять лет использовать локальную копию. Конечно, необязательно использовать для отправки JavaScript и CSS именно PHP. Мы перейдем к этому через несколько минут.
Ошибка на ошибке
Ручное изменение названий файлов при изменении их содержимого — опасное занятие. Что произойдет, если вы переименуете файл, но забудете переименовать шаблоны, указывающие на него? Что произойдет, если вы поменяете не все шаблоны, а только часть? Что случится, если вы измените шаблоны, но сам файл не переименуете? И наиболее вероятный вариант: что произойдет, если вы измените содержимое, но забудете переименовать файл или изменить ссылки на него? В лучшем случае, пользователи будут работать на старой версии сайта. В худшем — сайт перестанет работать совсем. В общем, ручное изменение названий — дурацкая идея.На наше счастье, компьютеры с такими задачами — тупым повторением одних и тех же операций при совпадении определенных условий — справляются отменно.
Чтобы сделать этот процесс максимально безболезненным, следует для начала уяснить, что нам вообще не нужно переименовывать файлы. Между реальным расположением файла на диске и URL, с которого он доставляется пользователю, нет ничего общего. Так что в случае Apache мы можем использовать mod_rewrite, создав простое правило для редиректа определенных URL к нужным файлам:
RewriteEngine on
RewriteRule ^/(.*.)v[0-9.]+.(css|js|gif|png|jpg)$ /$1$2 [L]
Это правило обрабатывает все URL с указанными расширениями, которые также содержат суффикс версии. В процессе обработки правило переписывает URL так, чтобы он указывал на путь к нужному файлу (исключая при этом суффикс). Например:
foo.v2.gif foo.gif
/css/main.v1.27.css css/main.css
/javascript/md5.v6.js /javascript/md5.js
Когда это правило работает, мы можем менять URL (добавляя к нему суффикс версии), не меняя расположения файла на диске. Обнаружив, что URL изменился, браузер считает, что ему нужно обратиться к новому ресурсу.
Вы можете поинтересоваться, почему мы просто-напросто не использовали динамические ссылки (например, /css/main.css?v=4)? Дело в том, что, согласно спецификации HTTP, пользовательские агенты вообще не должны кэшировать такие URL. И хотя IE и Firefox это игнорируют, Opera и Safari точно следуют букве — поэтому, чтобы гарантировать корректную работу всех браузеров при кэшировании наших ресурсов, мы избегаем использовать динамические ссылки.
Теперь, когда мы научились менять URL без перемещения файла, было бы неплохо автоматизировать обновление URL. В небольшой рабочей среде (или в среде разработки, для тех, кому приходится иметь дело с большими рабочими средами) это довольно легко осуществить с помощью функций шаблона. Следующий пример сделан на основе Smarty, но может быть реализован и на основе других подобных движков:
<link l:href="{version src=’/css/group.css’}" rel="stylesheet" type="text/css" />
function smarty_version($args){
$stat = stat($GLOBALS[‘config’][‘site_root’].$args[‘src’]);
$version = $stat[‘mtime’];
echo preg_replace(‘!.([a-z]+?)$!’, «.v$version.$1», $args[‘src’]);
<link l:href="/css/group.v1234567890.css" rel="stylesheet" type="text/css" />
Для каждого залинкованного ресурса мы определяем местоположение файла на диске, проверяем его mtime (дату последнего изменения) и вставляем эту информацию в URL в виде номера версии. Это прекрасно работает на сайтах с низким трафиком (где метод stat, возвращающий информацию о файлах и каталогах, обходится довольно дешево) и в среде разработчика, однако плохо масштабируется на большие сайты, поскольку каждый вызов stat означает обращение к диску на чтение.
Решить эту проблему нетрудно. В больших системах у нас изначально есть номер версии для каждого ресурса в виде номера, присвоенного системой контроля версий (вы же используете систему контроля версий, правда?). На этапе финального построения нашего сайта требуется лишь проверить номера версий всех нужных файлов и записать их в статический конфигурационный файл.
$GLOBALS[‘config’][‘resource_versions’] = array(
‘foo.gif’ => ‘2.1’,
‘/css/main.css’ => ‘1.27’,
‘/javascript/md5.js’ => ‘6.1.4’,
Затем мы меняем нашу функцию в шаблоне, чтобы она могла использовать эти номера версий при реальной работе.
function smarty_version($args){
if ($GLOBALS[‘config’][‘is_dev_site’]){
$stat = stat($GLOBALS[‘config’][‘site_root’].$args[‘src’]);
$version = $stat[‘mtime’];
$version = $GLOBALS[‘config’][‘resource_versions’][$args[‘src’]];
echo preg_replace(‘!.([a-z]+?)$!’, «.v$version.$1», $args[‘src’]);
Таким образом, нам не нужно переименовывать файлы или даже запоминать, когда мы изменяли их содержимое, — URL автоматически будут изменяться каждый раз, когда мы перерабатываем сайт. В общем, почти приехали.
Собираем все вместе
В разговоре об отправке заголовков, обеспечивающих долговременное хранение статических ресурсов в кэше, мы отметили, что если отдача контента реализована не на PHP, то простого способа добавления таких заголовков не существует. Чтобы справиться с этой проблемой, мы можем либо все же использовать PHP, либо переложить задачу модификации заголовков на Apache.Использовать для нашей цели PHP нетрудно. Мы просто должны изменить правила rewrite для статических файлов, чтобы они проходили через PHP-скрипт, и написать сам скрипт, который будет выдавать нужные заголовки, перед тем как передать эти файлы по запросу.
RewriteRule ^/(.*.)v[0-9.]+.(css|js|gif|png|jpg)$ /redir.php?path=$1$2 [L]
header(«Expires: „.gmdate(„D, d M Y H:i:s“, time()+315360000).“ GMT»);
header(«Cache-Control: max-age=315360000»);
# ignore paths with a ‘..’
if (preg_match(‘!..!’, $_GET[path])){ go_404(); }
# make sure our path starts with a known directory
if (!preg_match(‘!^(javascript|css|images)!’, $_GET[path])){ go_404(); }
# does the file exist?
if (!file_exists($_GET[path])){ go_404(); }
# output a mediatype header
$ext = array_pop(explode(‘.’, $_GET[path]));
switch ($ext){
case ‘css’:
header(«Content-type: text/css»);
case ‘js’ :
header(«Content-type: text/javascript»);
case ‘gif’:
header(«Content-type: image/gif»);
case ‘jpg’:
header(«Content-type: image/jpeg»);
case ‘png’:
header(«Content-type: image/png»);
header(«Content-type: text/plain»);
# echo the file’s contents
echo implode(‘’, file($_GET[path]));
function go_404(){
header(«HTTP/1.0 404 File not found»);
Несмотря на то что такой подход работает, это не лучшее решение. PHP в сравнении с Apache требует больше памяти и времени на исполнение. Кроме того, нам необходимо соблюдать осторожность из-за возможных эксплойтов. Дабы избежать всей этой головной боли, мы можем попытаться использовать Apache напрямую. Директива RewriteRule позволяет нам устанавливать значения переменных окружения при срабатывании директивы, тогда как директива Header добавляет заголовки лишь в том случае, когда присвоенно значение заданной переменной. Комбинируя две эти директивы, мы легко можем составить нужную цепочку инструкций:
RewriteEngine on
RewriteRule ^/(.*.)v[0-9.]+.(css|js|gif|png|jpg)$ /$1$2 [L,E=VERSIONED_FILE:1]
Header add «Expires» «Mon, 28 Jul 2014 23:30:00 GMT» env=VERSIONED_FILE
Header add «Cache-Control» «max-age=315360000» env=VERSIONED_FILE
Из-за порядка исполнения Apache, мы должны добавить строчку Re-writeRule в главный конфигурационный файл (httpd.conf), а не в .htaccess, иначе строчки Header будут исполнены первыми, перед установкой переменной окружения. Сами строчки Header могут быть размещены и в главном конфигурационном файле, и в .htaccess — их местоположение ни на что не влияет.
Сокращенный перевод.
© 2006 Carson Systems, Vitamin
Оригинал: www.thinkvitamin.com/features/webapps/serving-javascript-fast
РЫНКИ: Ну и как тебя называть?
Автор: Виктор Шепелев
Unix отсутствует. Просто не существует в природе. То есть нет такой конкретной вещи, в которую можно ткнуть пальцем и сказать: «Вот это — Unix». А все остальное тогда будет никакой не Unix. Собственно говоря, удивительный термин *nix (и даже — *n?x, как дань Linux) — результат вот этого несуществования единственно правильного Unix’а.
Именно поэтому исследовательское подразделение AT&T, Bell Labs, с тех пор прибыли само по себе не приносило: все создаваемые компьютерные технологии свободно лицензировались всем желающим. Если бы не это, еще неизвестно, как сложилась бы судьба созданной в Bell Labs операционной системы Unix. Многие из лицензиатов (в основном, конечно же, университеты) создавали слегка или сильно модифицированные версии для собственных нужд. Одной из этих версий, созданной в университете Беркли, Калифорния ничем не примечательным аспирантом Биллом Джоем, была уготована долгая и извилистая судьба.
В начале 1980-х годов в результате очередного антимонопольного судебного процесса AT&T была разделена на несколько подразделений, в результате чего у корпорации оказались развязаны руки (в смысле получения прибыли от торговли компьютерами). И вновь — тяжело предположить, как бы сложилась судьба Unix без этого события: с одной стороны, агрессивный маркетинг AT&T способствовал быстрому и эффективному распространению ОС; с другой — новая стратегия лицензирования (без исходного кода) положила начало разделению разработки Unix на несколько разных независимых веток и многолетнему противостоянию этих веток (так называемые unix wars).
Одной из «веток» стал разработанный в Беркли «берклиевский набор софта» (Berkeley Software Distribution, BSD), по прежнему распространявшийся свободно и с исходниками. Возможно, именно этот факт повлиял на DARPA[На всякий случай: DARPA — Defense Advanced Research Projects Agency (Агентство перспективных исследований при Министерстве обороны США) — так или иначе поддерживало огромную часть исследований, которые сформировали образ современных IT] при выборе — кому бы дать денег для разработки протокола TCP/IP. Дали. Разработали (4.2BSD, август 1983 года). Этот фактор (совместно со многими другими) повлиял на огромную популярность и быстрое распространение BSD. Ну а Билл Джой, с которого начиналась эта версия Unix, тем временем создал собственную фирму под названием «Солнышко».
Оригинальная Unix System V от AT&T, созданная в Беркли BSD, Sun OS от Sun Microsystem и еще несколько дистрибутивов, основанных на System V и BSD, вступили в сложное взаимодействие, включавшее и конкуренцию, и заимствование полезных фич, и юридические споры — в общем, было весело. Однако все это привело к размытию образа Unix и потере ориентиров в стиле «лебедь, рак и щука». Попытки исправить ситуацию привели к очередному пату: AT&T и Sun скоординировались и создали System V version 4, а многие независимые производители, которым не понравился этот альянс гигантов, объединились в Open Software Foundation[Не путать с Free Software Foundation — ничего общего!] и попытались создать «свой» Unix по имени OSF/1 (в общем, это была неудачная попытка)[Вообще говоря, у них там все еще сложнее получилось: сначала группа независимых поставщиков Unix создала группу по его стандартизации X/Open, в ответ на это объединились AT&T и Sun; а уже это привело к появлению Open Software Foundation].
Этот жизнерадостный период (конец 80-х — начало 90-х), называемый Unix wars, имел много интересных последствий: считается, что пока юниксопроизводители воевали друг с другом, Windows захватил десктопы, а внезапно появившийся Linux — сердца простых юниксоидов, которым скандалы производителей были до фени. Впрочем, в данном контексте нам будут намного интереснее другие последствия противостояния.
В 1985 году за дело взялась серьезная организация IEEE, которая ведает большой частью американских и международных стандартов. При участии многих выдающихся профессионалов к 1990 году появился стандарт POSIX (о происхождении аббревиатуры — см. эпиграф; официальная расшифровка — Portable Operating System Interface[X в аббревиатуре — что-то вроде «привет юниксоидам»]).
Основная цель POSIX — обеспечить переносимость (Portable) программ между различными операционными системами, соответствующими стандарту. Причем переносимость обеспечивается на уровне исходного кода — то есть предполагается, что программа попадает на целевую систему в виде исходников, и если программа и ОС POSIX-совместимы, то первая без проблем скомпилируется и заработает на второй.
Соответственно своей цели (обеспечить переносимость прикладных программ), POSIX не предъявляет никаких требований к архитектуре операционной системы. POSIX определяет только взаимодействие между программой и ОС в стиле «системный вызов по имени А с параметром Б должен выполнить В и вернуть результат Г или ошибку Д». Это означает, что «POSIX-совместимая операционная система» не является синонимом «Unix». Например, в исходный код Linux (чтобы там ни думала себе SCO) не входит ни единой строчки из изначального AT&T Unix. Тем не менее программы, работающие в System V или BSD, без проблем запустятся в Linux. Торвальдс достиг этого результата действиями «в лоб»: взял стандарт POSIX и реализовал его. Получилось[Когда Oracle портировала свою БД (уже работавшую на Sun Solaris, наследнике Sun OS) на Linux, кто-то задал оракловским инженерам вопрос типа «и что, трудно было?» Ответ был характерен: «мы запускали make» (в смысле — собрали программу из исходников, и все заработало)].
Я вам больше скажу — Windows NT совместима с одной из частей POSIX (1003.1b, real-time extensions, описывающей переключение процессов, синхронизацию потоков и т. п.). И если скачать с сайта Microsoft набор утилит Services for Unix (SFU) — брюки превращаются… во вполне POSIX-соместимую систему (то есть теоретически любая Unix-программа на Windows+SFU должна собраться и запуститься без проблем). И еще более того — поддержка SFU корпорацией Microsoft как отдельного продукта практически прекращена — потому что он теперь будет входить в стандартную поставку Windows. Такие форточки.
Unix отсутствует. Просто не существует в природе. То есть нет такой конкретной вещи, в которую можно ткнуть пальцем и сказать: «Вот это — Unix». А все остальное тогда будет никакой не Unix. Собственно говоря, удивительный термин *nix (и даже — *n?x, как дань Linux) — результат вот этого несуществования единственно правильного Unix’а.
Как это вышло
Причиной такого положения дел стал антимонопольный комитет США. Не стоит сразу представлять себе судебный процесс «Консервативная монополия Unix мешает развитию новой перспективной ОС Windows». Антимонопольный процесс против American Telephone and Telegraph (AT&T) в 1949 году помешал распространению влияния телекоммуникационного гиганта на новорожденные отрасли: AT&T было запрещено заниматься продажей каких бы то ни было компьютерных решений, и рекомендовалось ограничиться телефоном и телеграфом.Именно поэтому исследовательское подразделение AT&T, Bell Labs, с тех пор прибыли само по себе не приносило: все создаваемые компьютерные технологии свободно лицензировались всем желающим. Если бы не это, еще неизвестно, как сложилась бы судьба созданной в Bell Labs операционной системы Unix. Многие из лицензиатов (в основном, конечно же, университеты) создавали слегка или сильно модифицированные версии для собственных нужд. Одной из этих версий, созданной в университете Беркли, Калифорния ничем не примечательным аспирантом Биллом Джоем, была уготована долгая и извилистая судьба.
В начале 1980-х годов в результате очередного антимонопольного судебного процесса AT&T была разделена на несколько подразделений, в результате чего у корпорации оказались развязаны руки (в смысле получения прибыли от торговли компьютерами). И вновь — тяжело предположить, как бы сложилась судьба Unix без этого события: с одной стороны, агрессивный маркетинг AT&T способствовал быстрому и эффективному распространению ОС; с другой — новая стратегия лицензирования (без исходного кода) положила начало разделению разработки Unix на несколько разных независимых веток и многолетнему противостоянию этих веток (так называемые unix wars).
Одной из «веток» стал разработанный в Беркли «берклиевский набор софта» (Berkeley Software Distribution, BSD), по прежнему распространявшийся свободно и с исходниками. Возможно, именно этот факт повлиял на DARPA[На всякий случай: DARPA — Defense Advanced Research Projects Agency (Агентство перспективных исследований при Министерстве обороны США) — так или иначе поддерживало огромную часть исследований, которые сформировали образ современных IT] при выборе — кому бы дать денег для разработки протокола TCP/IP. Дали. Разработали (4.2BSD, август 1983 года). Этот фактор (совместно со многими другими) повлиял на огромную популярность и быстрое распространение BSD. Ну а Билл Джой, с которого начиналась эта версия Unix, тем временем создал собственную фирму под названием «Солнышко».
Оригинальная Unix System V от AT&T, созданная в Беркли BSD, Sun OS от Sun Microsystem и еще несколько дистрибутивов, основанных на System V и BSD, вступили в сложное взаимодействие, включавшее и конкуренцию, и заимствование полезных фич, и юридические споры — в общем, было весело. Однако все это привело к размытию образа Unix и потере ориентиров в стиле «лебедь, рак и щука». Попытки исправить ситуацию привели к очередному пату: AT&T и Sun скоординировались и создали System V version 4, а многие независимые производители, которым не понравился этот альянс гигантов, объединились в Open Software Foundation[Не путать с Free Software Foundation — ничего общего!] и попытались создать «свой» Unix по имени OSF/1 (в общем, это была неудачная попытка)[Вообще говоря, у них там все еще сложнее получилось: сначала группа независимых поставщиков Unix создала группу по его стандартизации X/Open, в ответ на это объединились AT&T и Sun; а уже это привело к появлению Open Software Foundation].
Этот жизнерадостный период (конец 80-х — начало 90-х), называемый Unix wars, имел много интересных последствий: считается, что пока юниксопроизводители воевали друг с другом, Windows захватил десктопы, а внезапно появившийся Linux — сердца простых юниксоидов, которым скандалы производителей были до фени. Впрочем, в данном контексте нам будут намного интереснее другие последствия противостояния.
Что из этого вышло
А последствия были такие: программистам стало очень печально жить. Как водится, в результате маркетинговых войн (когда каждый стремится сотворить систему круче чем у прочих) совместимость различных клонов Unix пошла на убыль. То есть программа, написанная под какую-нибудь Sun OS, совершенно не обязательно станет работать под какой-нибудь другой BSDI (хотя, по идее, и то и другое — Unix). Менеджерам-маркетологам этот вопрос был, в общем, без разницы («а так даже лучше — чего это наши программы будут работать под ОС конкурента?»), но, к счастью, культура Unix всегда определялась скорее программистами и продвинутыми пользователями, нежели менеджерами.В 1985 году за дело взялась серьезная организация IEEE, которая ведает большой частью американских и международных стандартов. При участии многих выдающихся профессионалов к 1990 году появился стандарт POSIX (о происхождении аббревиатуры — см. эпиграф; официальная расшифровка — Portable Operating System Interface[X в аббревиатуре — что-то вроде «привет юниксоидам»]).
Основная цель POSIX — обеспечить переносимость (Portable) программ между различными операционными системами, соответствующими стандарту. Причем переносимость обеспечивается на уровне исходного кода — то есть предполагается, что программа попадает на целевую систему в виде исходников, и если программа и ОС POSIX-совместимы, то первая без проблем скомпилируется и заработает на второй.
Соответственно своей цели (обеспечить переносимость прикладных программ), POSIX не предъявляет никаких требований к архитектуре операционной системы. POSIX определяет только взаимодействие между программой и ОС в стиле «системный вызов по имени А с параметром Б должен выполнить В и вернуть результат Г или ошибку Д». Это означает, что «POSIX-совместимая операционная система» не является синонимом «Unix». Например, в исходный код Linux (чтобы там ни думала себе SCO) не входит ни единой строчки из изначального AT&T Unix. Тем не менее программы, работающие в System V или BSD, без проблем запустятся в Linux. Торвальдс достиг этого результата действиями «в лоб»: взял стандарт POSIX и реализовал его. Получилось[Когда Oracle портировала свою БД (уже работавшую на Sun Solaris, наследнике Sun OS) на Linux, кто-то задал оракловским инженерам вопрос типа «и что, трудно было?» Ответ был характерен: «мы запускали make» (в смысле — собрали программу из исходников, и все заработало)].
Я вам больше скажу — Windows NT совместима с одной из частей POSIX (1003.1b, real-time extensions, описывающей переключение процессов, синхронизацию потоков и т. п.). И если скачать с сайта Microsoft набор утилит Services for Unix (SFU) — брюки превращаются… во вполне POSIX-соместимую систему (то есть теоретически любая Unix-программа на Windows+SFU должна собраться и запуститься без проблем). И еще более того — поддержка SFU корпорацией Microsoft как отдельного продукта практически прекращена — потому что он теперь будет входить в стандартную поставку Windows. Такие форточки.