Мне кажется странным, что iPhone кэширует страницы локально, и что вам нужно очистить кеш, чтобы получить свежий контент.
На самом деле должны быть некоторые заголовки кэша HTTP, которые сообщают об этом браузеру iPhone.
Не должно иметь значения, является ли браузер Safari на iOS, или Opera на Android, или Firefox на Windows, потому что все современные браузеры «должны» соответствовать HTTP 1.1 RFC , даже мобильные.
Конечно, они могут иметь некоторые различия для экономии полосы пропускания, заряда аккумулятора телефона и процессоров, но, безусловно, они должны позволять пользователям получать свежий контент с веб-сайта. Поэтому я согласен с вами, очистка посещенных страниц не является правильным способом ведения дел.
Я определенно думаю, что где-то есть проблема. Попробуйте вызвать API через браузер компьютера и проверить запросы с помощью firebug или встроенного средства отладки chrome, чтобы проверить заголовки ответа сервера и проверить, является ли поведение таким же.
Обычно я использую комбинацию валидаторов кешей max-age и if-Modified-Since.
Я установил максимальное значение для некоторых изображений на высокое значение (в моем случае 365 дней, что, скорее всего, не подходит для вас), для некоторых других - неделя, а также день css и javascript.
Кроме того, я использую if-Modified-Since, поэтому у меня хороший баланс между свежестью контента, нагрузкой на сервер и использованием полосы пропускания. ETAG - это в основном то же самое, что и if-Modified-Since, с той разницей, что вы можете установить его в качестве слабого валидатора кэша, и он действительно полезен, если часы сервера ненадежны. (см. ниже расширенный ответ для получения дополнительной информации и ссылок на документы)
Чтобы включить кэш, IIS7 упрощает работу с модулем IIS для кэширования выходных данных. Вот хороший документ об этом, о том, как его включить, и о разнице между ядром и кешем пользовательского режима.
Если вам не понадобится делать что-то особенное, я думаю, вам не нужно будет создавать код для него, а IIS позаботится обо всем. Если это не так, то вот еще одно хорошее руководство , которое поможет вам.
Если вы действительно хотите быстрый веб-сайт, я бы порекомендовал вам включить сжатие и добавить слой кэша между приложением и базой данных. Таким образом, вы не будете выполнять запросы к БД при каждом запросе.
Вот еще несколько хороших рекомендаций по производительности для любого веб-разработчика.
Расширенный ответ (может быть, даже слишком расширенный :))
Существуют разные способы кэширования контента на стороне клиента через HTTP 1.1.
Наиболее распространенные, или, по крайней мере, те, которые я использовал больше всего:
- Макс-возраст
- последнее изменение
- ETag
1) Заголовок максимального возраста отправляется с сервера в заголовках ответа HTTP и, в основном, сообщает браузеру клиента сохранять содержимое в своем кэше в течение периода времени, указанного в секундах.
Например, предположим, что сервер возвращает max-age = 60 в ответ на http-запрос GET-клиента logo.jpg. Затем браузер клиента сохраняет logo.jpg и в течение следующих 60 секунд он будет передавать изображение из своего собственного кэша.
Другими словами, в течение следующих 60 секунд не будет никаких HTTP-запросов для этого конкретного изображения.
Таким образом, при максимальном возрасте содержимое кэшируется на стороне клиента и не будет запрашиваться или повторно проверяться сервером в течение количества секунд, указанного в заголовке максимального возраста.
Однако, как правило, существует возможность принудительного повторного подтверждения / обновления, нажав CTRL-F5 в браузере Windows и CMD-R в браузерах Mac. На мобильных устройствах обычно функциональность находится в меню браузера и называется обновлением. Это соответствующий раздел RFC.
ПРОФИ
- нет TCP-соединений и HTTP-запросов к серверу, поэтому меньше нагрузки на стороне сервера (очень полезно, если в вашем приложении много пользователей)
- контент загружается локально, прямо из кеша браузера, поэтому нет задержки при загрузке контента
- пропускная способность не используется (полезно, если центр обработки данных взимает плату за входящую и исходящую пропускную способность)
CONS
- если у вас есть свежий контент на сервере, клиент не будет знать об этом до тех пор, пока не истечет срок действия кэша на стороне клиента или пользователь не обновит браузер.
2) Последний измененный заголовок HTTP-ответа на стороне сервера вместе с заголовком http-запроса на стороне клиента if-updated-Since является еще одним хорошим механизмом для ускорения работы сайтов и экономии денег. Это в основном работает таким образом.
Браузер впервые запрашивает контент на сервер с помощью запроса GET.
Сервер отвечает 200 и возвращает содержимое вместе с последним измененным заголовком.
Значение последнего измененного заголовка - это не что иное, как фактическая дата и время, когда содержимое было изменено в последний раз. (дата должна быть в UTC из-за часовых поясов)
На этом этапе все последующие HTTP-запросы на одно и то же содержимое, поступающие от клиента, будут иметь дополнительный заголовок: if-Modified-Since с датой и временем, полученными от сервера в качестве значения.
Когда сервер получит следующие запросы, он проверит значение заголовка if-Modified-Since и сравнит его с датой последнего изменения содержимого.
Если данные одинаковы и, следовательно, содержимое не изменилось, сервер ответит 304 и, в основном, без содержимого. (самая важная часть!)
Затем браузер знает, что он должен сохранять содержимое в кэше и загружать его из него, потому что он не изменился на стороне сервера.
Процесс будет продолжаться до тех пор, пока содержимое на сервере не изменится, и поэтому сервер предоставит новую дату последнего изменения и новый контент.
Это, как вы можете видеть, может сэкономить большую пропускную способность, особенно в случае изображений, JS или CSS, без потери свежести контента. Раздел 14.25 спецификации объясняет вещи намного лучше, чем я. :)
ПРОФИ
- Меньшая полоса пропускания задействована во всем процессе, потому что, если содержимое не изменилось, сервер отвечает только 304.
- Повторная проверка содержимого со стороны клиента, поэтому у клиента всегда будут последние свежие данные
CONS
- сервер должен обрабатывать TCP-соединения и HTTP-запросы и проверять дату и время последнего изменения файла / содержимого клиентского запроса.
3) ETAG - это процесс, аналогичный if-Modified-Since, с той разницей, что значение заголовка обычно является хешем содержимого на стороне сервера, а клиент по запросам http отправляет заголовок с именем если-ни матча.
Плюсы и минусы такие же, как в пункте 2.
Теперь вы можете задаться вопросом, в чем главное отличие пункта 2 от пункта 3.
Проблема с пунктом 2 на самом деле часы сервера. На самом деле могут возникнуть проблемы с возвратом даты последнего изменения с сервера, если у него проблемы с часами
Тема гораздо глубже, потому что лучшая практика - отправить слабого и сильного валидатора. См. раздел 13.3.4 для получения дополнительной информации.