кешируем свой сайт

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

Кеш находится посередине между посетителем сайта и вашим сервером, и при грамотной настройке позволяет, с одной стороны, снизить нагрузку на сервер, т.к. будет отдавать файлы вместо него, а с другой — ускорить получение файлов посетителем: ведь, как правило, кеш физически находится значительно ближе к посетителю. Под настройкой здесь подразумевается не настройка кеширующего прокси (который, в большинстве случаев, к вам не имеет никакого отношения), а настройка веб-сервера.

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

Когда посетитель запрашивает какой-то документ, то сначала опрашивается кеш, и если прокси-сервер находит у себя копию запрошенного документа, то он решает, отдавать ли ее или запросить новую версию у вашего сервера. Если документ не обнаружен, то прокси-сервер забирает документ с вашего сервера, передает посетителю, а копию помещает в свое хранилище. И при следующем запросе отдаст посетителю (возможно, другому) уже локальную копию.

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

Для того чтобы указать, что именно можно или нельзя кешировать, используются заголовки HTTP-протокола и META-теги в заголовке документа (не надо их путать!). META-теги, в основном, проверяются браузером и помогают ему решить, можно ли кешировать полученный документ. HTTP-заголовки, в основном, служат для управления прокси-серверами. Я не зря написал «в основном» — дело в том, что, как и в большинстве других компьютерных областей, в кешировании, во-первых, нет жестких правил (недаром, все документы, регламентирующие работу интернета, называются RFC: Request For Comment), а есть только рекомендации; во-вторых, очень многое зависит от администратора прокси-сервера, который может либо сознательно, для каких-то своих целей, либо по ошибке настроить свой прокси каким-то «хитрым» способом; в-третьих, не исключены ошибки реализации самих прокси-серверов и т.п. Так что, настраивая свой сервер на оптимальную работу с различными кешами, вам придется задействовать сразу несколько механизмов управления, но при этом нужный результат не будет гарантирован. Хотя, пожалуй, в 95% случаев все будет работать именно так, как вы задумали.

Первое правило. На любом, даже самом динамическом сайте всегда есть статичные файлы. Это, например, таблицы стилей, картинки навигации, логотип, страница «о компании» и т.д. и т.п. Есть смысл
постараться загнать все это дело в кеш — от этого все только выиграют. Поэтому стоит, во-первых, на всех страницах использовать одну и ту же копию картинки и указывать один и тот же адрес. В частности, если ваш сайт имеет несколько адресов (например, http://mycompany.ru и http://www.mycompany.ru), то есть смысл на страницах прописывать, скажем, <img src=»http://mycompany.ru/img/logo.gif»> На первый взгляд, экономия не очень значительная, но для популярных сайтов она оказывается вполне заметной.

META-теги оказывают влияние на кеширование ваших страниц в браузере посетителя. В большинстве браузеров пользователь может указать, как часто должна проверяться «свежесть» страниц: один раз для сессии (пока браузер не будет закрыт) или пока не истечет «время жизни» документа, или еще как-то. Браузеры особенно активно работают с кешированием (что не удивительно и правильно), поэтому чаще всего здесь возникает задача запретить (или ограничить) кеширование каких-то отдельных документов. Наиболее полезными здесь оказываются теги Expires и Pragma no cache. Например, для регулярно обновляемой страницы новостей можно указать, скажем, <meta http-equiv=»Expires» content=»Thu, 08 May 2003 08:37:25 GMT»>, установив дату минут на 5-10 вперед от времени запроса. Если же требуется совсем запретить кеширование, то стоит прописать:
<meta http-equiv=»Expires» content=»0″>
<meta http-equiv=»Pragma» content=»no-cache»>
Это, по идее, должно сработать. Также можно Expires установить на какую-то дату в прошлом, но ноль является более правильным решением.

HTTP-заголовки являются наиболее мощным, но и несколько более сложным в использовании инструментом.

В отношении кеширования наиболее важным является, пожалуй, Expires, который, как и в META-теге, указывает, когда кешированная копия устареет. Если значение заголовка Expires отличается от требуемого формата (дата по Гринвичу), то большинство прокси будут считать, что документ устарел, и кешировать его не станут. Часто для этих же целей Expires устанавливается на дату в прошлом. Это не противоречит RFC2616, но некоторые прокси-сервера считают такой ответ неправильным, отбрасывают заголовок и применяют к документу правила кеширования по умолчанию. Поэтому, если вы не хотите, чтобы документ кешировался, то лучше установить Expires в ноль, или, скажем, на одну секунду вперед.

В HTTP 1.1 появились специальные заголовки Cache-Control, которые позволяют более тщательно работать к кешированием. Там есть довольно много вариантов, из которых я бы посоветовал обратить внимание на тэги:
max-age, который позволяет указать количество секунд, в течение которого результат считается «свежим» (очень полезно для динамических сайтов, на которых информация меняется не все время, а, скажем, раз в несколько минут);
no-cache, который приказывает прокси-серверу перед тем, как отдать клиенту скешированный документ, запросить подтверждение его «свежести» у вашего сервера (это позволяет одновременно гарантировать, что результаты актуальны, и пользоваться преимуществами кеширования);
must-revalidate, который приказывает прокси-серверу слушаться ваших указаний насчет «свежести» документа, а не использовать свои предположения и алгоритмы.

Одним из наиболее популярных заголовков является Last-Modified, указывающий на время последнего изменения документа. Если этот заголовок был указан, когда документ кешировался, то прокси, обращаясь к вашему серверу, может указать в запросе «If-Modified-Since», и в том случае, если документ не изменился, вашему серверу достаточно отправить код 304, не пересылая сам документ.

В HTTP 1.1 появился еще один полезный заголовок — ETag. Он представляет собой уникальный идентификатор документа, который генерируется вашим сервером и автоматически меняется при изменении документа. Таким образом значительно облегчается проверка документа на «свежесть» — достаточно просто сравнить ETag’и на сервере и на прокси.

За выдачу HTTP-заголовков для статичных файлов отвечает сервер, поэтому стоит почитать его документацию и посмотреть, что именно он будет говорить о разных типах файлов. В частности, для «Русского Апача» я бы посоветовал обратить внимание на директиву препроцессора EPOCH_EXPIRES (используется при компиляции сервера), а также на директивы CharsetOverrideExpires, CharsetDisableForcedExpires и CacheNegotiatedDocs в файле конфигурации. А заодно и на mod_expires и mod_headers.

Для того чтобы проверить, насколько хорошо ваш сайт может кешироваться, попробуйте воспользоваться, например, он-

Алексей Волков