Комментарии
Задача: на сайте используется набор javascript-библиотек, которые сливаются php-скриптом в один файл с названием вида 78472581267468236825748923.js (где цифры - имплод номеров версий каждой отдельной библиотеки), а контент оптимизирован и (может быть) как-то упакован. Планируется, что сий файл будет сидеть в кеше (а по размеру он довольно большой) и когда версия хоть одной из библиотек изменится - изменится имя файла и он будет заново запрошен с сервера. Все счастливы, траффик сэкономлен, дети смеются, Санта Клаус раздаёт подарки, мир во всём мире.
Как же дело обстоит на самом деле? В один прекрасный момент вы замечаете, что траффик у вас совсем не убавился и посмотрев статистику обнаруживаете, что ваш файлик с красивым именем 78472581267468236825748923.js таскается с сервера при каждом запросе и ну никак не хочет залезать в кеш браузера.
Начинаем копать глубже и при сравнении хедеров нашего файла и обычного статичного js обнаруживаем, что у последнего в хедере присутствует параметр "Last-Modified: Wed, 10 Sep 2008 07:01:14 GMT", определяющий дату обновления файла. В нашем же файле параметр сий отсутствует и сервер каждый раз шлёт ответ клиенту "200 ОК" с полным контентом.
Гуглим. Пишем принудительную отправку этого параметра в хедере. Не шлётся и всё - хоть убейся.
На различных форумах в сети есть много логичных объяснений. Например, "хренли слать дату обновления скрипта, если контент динамический?" (действительно, возразить сложно).
Грешил сначала на апач (думал, он отправляемые мной хедеры парсит и пропускает только то, что ему угодно).
Попробовал активировать для моего файла xBitHack. Появились первые подвижки - в хедере возник "Last-Modified", однако, ссылался он на текущую дату/время и изменениям не поддавался.
Потом думал, что пхп не хочет мои хедеры отдавать. 10 раз проверил все возможные варианты синтаксиса, генерацию даты, генерацию хеш-ключа ETag - ноль реакции.
В конечном итоге была найдена информация, что апач будет отдавать Last-Modified только если у файла есть разрешение на execute для группы. Для chmod пришлось тоже писать скриптик, т.к. ходим к хостеру самбой.
И, о чудо, вдруг всё заработало! )))
Механизм определения обновления через хеш ETag описывать не буду - он будет в первой 10 выдачи в гугле по запросу "etag".
← Вернуться к журналу «Узелки на память...»
Так вот проблема-то как раз в том, что файло хоть и кладётся исправно в кеш, но оттуда не вынимается, а каждый раз заново реквестается с сервера ))
- как же так, у тебя же имя файла меняется при каждом изменении, если имя у файла не изменилось, то юзер больше его не качает, потому что он у него на месяц в кеше, а если изменился, то всё равно ему заново качать.
я как-то так эту логику вижу.
- Да, за ссылку спасибо.
- Дрон,
если бы у меня обновления были чётко через месяц, я бы не парился и прописал то же самое в хедере своих документов.
В моём случае документ может измениться через год, а может за сегодня 10 раз. В первом случае я 12 лишних раз файло перекачаю, во втором - получу изменения только через месяц.
- я тоже по самбе хожу, и "execute для группы" не требуется.
Для кеширования в .htaccess написано так:
ExpiresActive On
ExpiresByType image/png "access plus 1 month"
ExpiresByType image/gif "access plus 1 month"
и т.д.
более подробно про клиентскую оптимизацию можно почитать тут:
http://webo.in/
можно ещё файл переименовать из *.js в *.gz, а на клиенте распаковывать (mod_deflate), тоже трафик экономит.
- Куда сохранять? Кто будет сохранять?
А если изменения происходят 10 раз за сутки?
если этот js файл один для всех пользователей, почему бы его после сливания всех в один не сохранять просто?
ахуеть