HTTP кэширование I небольшое исследование по теме

782
.
╭∩╮ (`-`) ╭∩╮
Пользователи мобильных устройств особенно ценят. когда сайт грузится быстро. нажимая кнопку "назад" страница не перегружается, ты быстро можешь попасть туда, откуда пришел.
Тут многое зависит от браузеров, одни кэшируют сами, не спрашивая никакой команды, другие ждут специальных HTTP заголовков с инструкциями.
Как быть?
Как сделать ПРАВИЛЬНО, чтоб все работало быстро и траффик экономился?
---
Вот по этому поводу, я сегодня провел небольшое исследование (спасибо камрадам с Газена, что толкнули на это), результатом которого стала небольшая, но полезная доработка кода нашего двига.
З.Ы.
Тут на сайте доработка уже установлена, поидее, если у кого кнопка "назад" перезагружала страницы, уже подобного не должно быть.
.
╭∩╮ (`-`) ╭∩╮
Ранее, в нашем двиге, в качестве HTTP заголовков, управляющих кэшированием, передавалась всякая ересь, на которую ругался валидатор:
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
header("Cache-Control: no-cache, must-revalidate");
header("Pragma: no-cache");
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . "GMT");

Если вникните в суть, то увидите, что эти заголовки не кэшируют, а теоретически совсем НАОБОРОТ, дают комманду НЕ КЭШИРОВАТЬ.

Но почему же тогда, когда эти заголовки были, то к примеру Мурзилка Фраерфокс исправно кэшировала страницы, и при нажатии кнопки "назад" не перегружала их.
А когда я код убрал, перестала кэшировать?
---
Вот по этому поводу я и провел исследование, результаты которого выложил на Газене, и сейчас сюда скопирую.
З.Ы.
Очень помогла данная статья: http://nomagic.ru/all.php?aid=58
.
╭∩╮ (`-`) ╭∩╮
Итого, тема затронута интересная, поэкспериментировал, нашел в чем причина, сейчас подробно опишу.
---
Для экспериментов, использовались браузеры Opera и Firefox последних версий.
Для подробного мониторинга всех HTTP запросов и заголовков, использовалась профессиональная программа - сниффер HTTP Analyzer V6.
---
Итак, для начала, была полностью подтверждена бредовость тех заголовков, о которых я писал вначале и которые выпилил из двига.
Но меня заинтересовал тот факт, что теоретически, те заголовки призваны бороться с кэшированием и давать браузеру инструкции по постоянному обновлению информации.
На практике же, получался совсем обратный эффект.
Опера - хуй ложила на все эти инструкции и кэширует, независимо от их наличия. или отсутствия.
Мурзилка Фраерфокс - наоборот, при наличии тех заголовков почему-то начинает кэшировать, а при отсутствии, каждый раз обновляет страницу, генерируя доп. траффик.
----
Начал выяснять подробно.
Для начала, нужно было выяснить, какая именно строка из тех 4-х влияет на кэширование.
Методом исключения, нашел искомую строку:
header("Cache-Control: no-cache, must-revalidate");

влияет именно она, другие хоть есть, хоть их нет, картина не меняется.

Позвольте, удивился я, ведь данная строка дает команду именно НЕ КЭШИРОВАТЬ! Что же тогда творится, почему обратный эффект?
Ответ есть в той статье, ссылку на которую я дал выше и которая очень помогла в моих исследованиях.
Это НЕПРАВИЛЬНАЯь инструкция. потому и ругался валидатор.
Если написать ту же строку, но правильно:
header("Cache-Control: no-store, no-cache,  must-revalidate");

тогда инструкция выполняется ПРАВИЛЬНО всеми браузерами, даже Опера начинает обновлять информацию.
---
Да, но мы же хотели наоборот, не обновлять, а кэшировать, чтоб не гонялся лишний траффик и сервер не заваливался лишними запросами.
Для этого есть правильный заголовок:
header("Cache-Control: public");

Все браузеры начинают корректно кэшировать информацию
Можно добавить еще одну строку, где для надежности можно указать время жизни страниц:
header("Cache-Control: public");
header("Expires: " . date("r",  time() + 30));

в моем примере, я указал 30 секунд
---
И вот теперь, все правильно и соответствует стандартам RFC
Спасибо камрадам, что затронули этот вопрос, иначе самому все было лень возиться с исследованиями.
.
╭∩╮ (`-`) ╭∩╮
Вот скриншот программы - анализатора траффика
Прикрепленные файлы:
.
Вечно молодой
хм... Взял на заметку спасибо за такую полезную информацию,я о кешировании до этого как то особенно и не задумывался)))
.
╭∩╮ (`-`) ╭∩╮
Makoto (16.05.2011/17:37)
хм... Взял на заметку спасибо за такую полезную информацию,я о кешировании до этого как то особенно и не задумывался)))
Оно очень экономит траффик для мобильных пользователей.
Да и нехило разгружает сам сервер.
.
Вечно молодой
AlkatraZ, То,что разгружает сервер это то и хорошо)) И вот вопрос конечно чуть не в тему,но очень уж интересно)) На сколько я знаю из мануалов и статей работа скрипта через бд на много быстрей чем через фс,а не давно прочитал,что мол разницы особой нет,и всё дело только в постепенном росте веса из за роста регистраций,то есть заполнение профайлами. И мол скорость обработки,что через бд,что через фс имеет не существенную разницу. Я так подумал,а если у меня в одной папке в фс 10000файлов,из которых постоянно ищются,и перезаписываются 1000файлов юзеров которые на сайте,это получается,что это вся папка перекапывается постоянно,и следовательно вызывает высокую нагрузку,вследствии чего и генерация начинает сильно хромать. Верно ли я думаю,что это бред по чати того,что фс и бд почти равносильны в обработке запросов к ним? Если да,то не мог бы ты посоветовать,что нибудь по ускорению обработки запросов к фс?
.
╭∩╮ (`-`) ╭∩╮
Вообще, большинство систем начинают ощутимо притормаживать, если в одной папке более 3000 - 5000 файлов. зависит от настроек операционной системы сервера (кэш файловой системы).
Поэтому, много файлов в одной папке - это зло.
Если без файлов не обойтись, это к примеру фотоальбомы юзеров, то нужно придумывать скрипт. который будет рассортировывать их по папкам (не более 5000 файлов в каждой).
---
Ну а если файлы - это сам двиг (написан на файлах), то для большого сайта это плохо. На больших объемах данных, база имеет радикальные преимущества.
.
большинство мобильных арбузов кэшируют по -своему. хидеры вообще лучше убрать.
.
╭∩╮ (`-`) ╭∩╮
Krite (16.05.2011/20:58)
большинство мобильных арбузов кэшируют по -своему. хидеры вообще лучше убрать.
Я вначале (в версии 4.2.0) так и сделал, но некоторые юзеры начали жаловаться, потому и вдарился в исследования.
Зато, сейчас хидеры правильные, по стандарту RFC и большинство браузеров обрабатывает их нормально.
Всего: 87