Кеширование на сайте, работающего без перезагрузок

Здравствуйте! Хочу посоветоваться по поводу кеширования страниц сайта, работающего без перезагрузок. Используется Ajax, HistoryAPI, ЧПУ. К примеру, финальная ссылка к статье имеет вид: http://site.ru/articles/article_name.html. Первая же мысль, которая возникла - это кешировать каждую такую страницу в отдельный html-файл. Вроде бы ничего выдумывать не надо, т.к. правило mod_rewrite, перенаправляет все запросы на морду, если файлы или директории на сервере не найдены. А так как они присутствуют, то соответственно и подхватываться они будут автоматом. Будут, но только при прямом обращении к определенной статье, а не при переходе по внутренним ссылкам сайта. Кроме того, вид ссылки в осле отличается. Те, кто использовал HistoryAPI знает, что в URI присутствует хэш. http://site.ru/#/articles/article_name.html.
В общем, можно долго рассуждать что да как, обсуждать разные "НО", а как же все таки оптимальней всего кешировать в такой ситуации? И может на таком сайте вообще нет смысла в кешировании?

А какая разница? Обращение к серверу все равно идет по адресу без хеша.

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

-----
Чем больше узнаю, тем больше я не знаю.

Это уже вам судить: мы сайта не видели и его бэкенда.
К сути вопроса:
Если вы отдаете по ajaxy html, тогда может идти речь о кешировании HTML. Обычно же отдаются данные в json и страница загружается всего 1 раз, после чего подгружаются только новые данные. В данном случае, соответственно, кешировать нужно получаемый массив данных, который будет забираться статикой, минуя контроллер эти данные формирующий. Если в вашем случае дело обстоит иначе и вы отдаете ajaxom, к примеру, весь html страницы, то сохраняйте его целиком, а при получении ajax-запроса, или прямого запроса по URL (вашим history-api), проверяете контроллером есть-ли кэш. Если кэш есть - отдаете его. Если кеша нет - делаете выборку, формируете html и отправляете клиенту. Решение никак не отличается от обычных сайтов без ajax. Касательно history-api, мне не очень понятно, почему вы считаете что при его задействование урлы должны быть с #. Они могут быть любого какого хотите формата: site.ru/articles/article1

(Отредактировано автором: 08 Февраля, 2013 - 11:00:29)

Еще раз акцентирую внимание, что сайт работает без перезагрузок, на всех ссылках сайта весит preventDefault(), запросы отправляются в обработчик ajax-средствами, ответ - json
В осле - именно с хешем.
Кешировать малоизменяющиеся данные: статьи, посты блога, видеопрезентации и т.п. Кешировать собираюсь на строне сервера.
Как оказалось - отличается. Точнее, отличается не сам механизм создания кеша, а то в какой форме его создавать. Для обычного сайта, при запросе определенной страницы, мы бы проверили существование кеша, если надо - его актуальность (дата создания) и произвели те или иные действия. Теперь вернемся к моему вопросу.
Вариант номер раз: кешируем, к примеру, саму статью и в обработчике вытаскиваем или же её из БД (если кеша нет), или из кеша (если таковой рисутствует). В этом случае, возникает вопрос: а зачем тогда нам хэш, если выполнить один запрос к БД это вообще не проблема, а вся оболочка (довольно тяжёлая), так или иначен будет проходить все круги шаблонизации и подгружаться естественным образом.
Вариант второй: как я описал в начале, кешируем всю страницу полностью с каждой статьей в отдельный файл. Вариант был бы хороший, если бы не проблема с ослом, а именно, всё тем же хешем в URL. Поясню, что происходит в этом случае. Юзер набирает в нормальном браузере ручками адрес: http://site.ru/articles/statja.html, по такому адресу у нас есть реальный файл (та самая закешированная статья) и она же выводится на экран пользователя. Тут всё гуд. Теперь, те же действия в осле: точно так же набран адрес, но в браузере ссылка автоматически преобразуется в URL вида http://site.ru/#/articles/statja.html. Естественно, что по такому адресу файла не существует и происходит обычная подгрузка статьи из БД в обход кеша.
Для того, чтоб посмотреть это своими глазами, вот реальная ссылка на тестовом сервере. http://anna[dot]webkey[dot]net[dot]ua/articles/uspeh[dot]html . Попробуйте запустить ее в любом нормальном браузере, а потом в осле. Если подгрузиться закешированная страница, то вы увидите под названием статьи Закешированная страница!!!, если из БД, то этой надписи не будет.

(Отредактировано автором: 08 Февраля, 2013 - 11:24:11)

все что после решетки в адресе - на сервер никогда не попадает!!! если у вас ссылка вида
http://site[dot]ru/#/articles/article_name[dot]html
то аяксом запрос идет, например, на
http://site[dot]ru/articles/article_name[dot]html
По другому никак. Хеш адресной строки обрабатывается в браузере яваскриптом.


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

-----
Чем больше узнаю, тем больше я не знаю.

Ну почему: создавать кэши при формировании и/или изменении страницы и отдавать вообще одну статику если это оправдано для страницы

(Отредактировано автором: 08 Февраля, 2013 - 12:02:32)

Всё это я прекрасно знаю. Тем более, весь механизм работы сайта, как это не покажется странным, мне знаком на все 100%, т.к. я его и писал абсолютно с нуля, и принципиально ни в одном проекте не использую никакие CMS Не о том речь зашла. Главное, что я для себя уяснил - это то, что от полного кеширования страницы, наверно придется отказаться и вы сами подтвердили мои домыслы. Кстати, в полёте мысли, я как-то пропустил в вашем первом сообщении упоминание о LocalStorage. А ведь это вариант. Правда не очень удобный в плане управления кеш-данными, но всё же... надо будет обдумать эту тему. Спс.