Кэшируем свой сайт
Наверняка, передвигаясь по Интернету вы замечали, что одни сайты работают быстрее других. В некоторых случаях это не очень заметно и критично, в других - просто кошмарно - мне как-то попался сайт, на котором каждая страница грузилась минуты по три (специально замерил!), причем он отнюдь не был чем-то гигантским... С другой стороны браузера - у веб-мастеров - тоже возникают кучи проблем: серверу постоянно не хватает ресурсов, посетители жалуются на недогруженные страницы, трафик тратится непонятно на что... Разумеется, не существует единого универсального рецепта, позволяющего решить все эти проблемы, но существуют некие механизмы, позволяющие более или менее снизить их остроту. И одним из таких механизмов является кэширование.
Кэш находится посередине между посетителем сайта и вашим сервером и при грамотной настройке позволяет с одной стороны снизить нагрузку на сервер, т.к. будет отдавать файлы вместо него, а с другой - ускорить получение файлов посетителем, т.к. как правило, находится значительно ближе к нему физически. Под настройкой здесь подразумевается не настройка кэширующего прокси (который, в большинстве случаев к вам не имеет никакого отношения), а настройка веб-сервера.
В принципе, существует два вида кэша: первый - это кэширующие прокси-сервера, расположенные "по дороге" между посетителем и вашим сервером, а второй - это кэш браузера, который находится непосредственно на компьютере пользователя. С точки зрения веб-мастера разница между ними не очень большая, поэтому в этой заметке я буду просто говорить про кэширование.
Когда посетитель запрашивает какой-то документ, то сначала опрашивается кэш и, если прокси-сервер находит у себя копию запрошенного документа, то он решает, отдавать ли ее или запросить новую версию у вашего сервера. Если документ на прокси не обнаружен, то прокси-сервер забирает документ с вашего сервера, передает посетителю, а копию помещает в свое хранилище. И при следующем запросе отдаст (возможно, другому) посетителю уже локальную копию.
У кэширования есть свои недостатки - сложности с подсчетом статистики и показом рекламы, возможность получения посетителем устаревших страниц и т.п. Поэтому, довольно часто встречаются ситуации, когда веб-мастер либо всячески запрещает кэширование своих страниц, либо просто не обращает на кэширование внимания. И тот и другой вариант достаточно плох - в первом случае повышается нагрузка на сервер и увеличивается время получения страниц посетителем, а во втором для кэширования страниц будут использоваться настройки по умолчанию, установленные на прокси-сервере, что может оказаться еще хуже. Поэтому стоит по возможности контролировать что именно и как кэшируется, тем более, что прокси работают независимо от вас и что-то все-равно кэшироваться будет.
Для того, чтобы указать что именно можно или нельзя кэшировать используются заголовки http протокола и meta-теги в заголовке документа (не надо их путать!). meta-теги, в основном, проверяются браузером и помогают ему решить можно ли кэшировать полученный документ. http заголовки, в основном, служат для управления прокси-серверами. Я не зря написал "в основном" - дело в том, что как и в большинстве других компьютерных областей, в кэшировании во-первых нет жестких правил (недаром, все документы, регламентирующие работу Интернета называются rfc: request for comment), а есть только рекомендации, во-вторых очень многое зависит от администратора прокси-сервера, который может либо сознательно, для каких-то своих целей, либо по ошибке настроить свой прокси каким-то "хитрым" способом, в-третьих, не исключены ошибки реализации самих прокси-серверов и т.п. Так что, настраивая свой сервер на оптимальную работу с различными кэшами, вам придется задействовать сразу несколько механизмов управления, но при этом результат не будет гарантирован. Хотя в, пожалуй, 95% случаев все будет работать именно так, как вы задумали.
Первое правило. На любом, даже самом динамическом сайте всегда есть статичные файлы. Это, например, таблицы стилей, картинки навигации, логотип, страница "о компании" и т.д. и т.п. Есть полный смысл постараться загнать все это дело в кэш - от этого все только выиграют. Поэтому стоит во-первых на всех страницах использовать одну и ту же копию картинки, а во-вторых, указывать один и тот же адрес. В частности, если ваш сайт имеет несколько адресов (например, http://mycompany.ru и http://www.mycompany.ru), то есть смысл на страницах прописывать, скажем, 
На первый взгляд, экономия не очень значительная, но для популярных сайтов она оказывается вполне заметной.
meta-теги оказывают влияние на кэширование ваших страниц в браузере посетителя. В большинстве браузеров пользователь может указать как часто должна проверяться "свежесть" страниц - один раз для сессии (пока браузер не будет закрыт) или пока не истечет "время жизни" документа, или еще как-то. Браузеры являются особенно активными в отношении кэширования (что не удивительно и правильно), поэтому чаще всего здесь возникает задача запретить (или ограничить) кэширование каких-то отдельных документов. Наиболее полезными здесь оказываются теги expires и pragma no cache. Например, для регулярно обновляемой страницы новостей можно указать, скажем,
, установив дату на минут 5-10 вперед. Если же требуется кэширование совсем запретить, то стоит прописать что, по идее, должно сработать. Можно также expires установить на какую-то дату в прошлом, но ноль является более правильным решением.
http заголовки являются наиболее мощным, но и несколько более сложным в использовании инструментом.
В отношении кэширования наиболее важным является, пожалуй, expires, который как и в meta-теге указывает, когда скэшированная копия устареет. Если значение заголовка expires отличается от требуемого формата (дата по Гринвичу), то большинство прокси будут считать, что документ устарел и кэшировать его не станут. Часто для этих же целей expires устанавливается на дату в прошлом. Это не противоречит rfc2616 [ http://www.w3.org/protocols/rfc2616/rfc2616.html ], но некоторые прокси-сервера считают такой ответ неправильным, отбрасывают заголовок и применяют к документу правила кэширования по умолчанию. Поэтому, если вы не хотите, чтобы документ кэшировался, то лучше установить expires в ноль, или, скажем, на одну секунду вперед.
В http 1.1 [ http://www.w3.org/protocols/rfc2616/rfc2616.html ] появились специальные заголовки cache-control, которые позволяют более тщательно работать к кэшированием. Там есть довольно много вариантов, из которых я бы посоветовал обратить внимание на max-age, который позволяет указать количество секунд в течение которого результат считается "свежим" (очень полезно для динамических сайтов, на которых информация меняется не все время, а, скажем, раз в несколько минут); no-cache, который приказывает прокси-серверу перед тем, как отдать клиенту скэшированный документ запросить подтверждение его "свежести" у вашего сервера (это позволяет одновременно гарантировать, что результаты актуальны и пользоваться преимуществами кэширования); must-revalidate, который приказывает прокси-серверу слушаться ваших указаний насчет "свежести" документа, а не использовать свои предположения и алгоритмы.
Одним из наиболее популярных заголовков является last-modified, указывающий на время последнего изменения документа. Если этот заголовок был указан, когда документ кэшировался, то прокси, обращаясь к вашему серверу может указать в запросе "if-modified-since", и в том случае, если документ не изменился, вашему серверу достаточно отправить код 304, не пересылая сам документ.
В http 1.1 [ http://www.w3.org/protocols/rfc2616/rfc2616.html ] появился еще один полезный заголовок - etag. Он представляет из себя уникальный идентификатор документа, который генерируется вашим сервером и автоматичски изменяется при изменении документа. Таким образом значительно облегчается проверка документа на "свежесть" - достаточно просто сравнить etag'и на сервере и на прокси.
За выдачу http заголовков для статичных файлов отвечает сервер, поэтому стоит почитать его документацию и посмотреть что именно он будет говорить о разных типах файлов. В частности, для "Русского Апача" я бы посоветовал обратить внимание на директиву препроцессора epoch_expires (используется при компиляции сервера), а также на директивы charsetoverrideexpires, charsetdisableforcedexpires и cachenegotiateddocs в файле конфигурации. А заодно обратить внимание на mod_expires [ http://httpd.apache.org/docs/mod/mod_expires.html ] и mod_headers [ http://httpd.apache.org/docs/mod/mod_headers.html ].
Для того, чтобы проверить насколько хорошо ваш сайт может кэшироваться, попробуйте воспользоваться, например, он-лайновым сервисом cacheability [ http://www.web-caching.com/cacheability.html ].
Web Дизайнер (designer)