Трохи про кешуванні
Веб-майстри часто стикаються з кешуванням: браузери і проксі-сервера, намагаючись прискорити роботу сайту, намагаються зберегти у себе максимально велику кількість документів в кеші. Якщо ви відкриваєте сторінку сайту в браузері, потім ще одну, і після цього повертаєтеся на першу, з великої часткою ймовірності браузер візьме її з вашого диска (а то і з оперативної пам'яті), куди він зберіг сторінку при першому відвідуванні.
Зрозуміло, ця операція, як правило, виконується набагато швидше, ніж отримання того ж документа з мережі. Адже для відображення сторінки потрібно не тільки отримати HTML код, але і викачати з мережі всі супутні документи: CSS-файли, картинки, скрипти, оформлені у вигляді окремих файлів, і т.д. Якщо ви подивіться в папки кешу на вашому диску (для IE ця папка зазвичай знаходиться тут: «C: \ Documents and Settings \ ім'я користувача \ Local Settings \ Temporary Internet Files», для Firefox: «C: \ Documents and Settings \ ім'я користувача \ Local Settings \ Application Data \ Mozilla \ Firefox \ Profiles \ _случайная_строка_. default \ Cache »), то ви помітите, скільки файлів було збережено вашим браузером.
Звичайно ж, кеш здорово прискорює роботу, але з іншого боку, кеш може зіграти і негативну роль.
Наприклад, якщо буде кешуватися сторінка чату, то користувачі просто не побачать нові повідомлення. Веб-майстри часто вважають кеш злом, і борються з цим злом в міру своїх сил.
Проблема з кешуванням в Microsoft Internet Explorer
або установки заголовка Expires на минулу дату в вашому скрипті, який генерує вміст XML. У PHP це буде так:
перевіряємо кешування
Рекомендуємо прочитати Як додати новий сайт на FastVPS
Легко побачити, що в наведеному прикладі ми намагаємося заборонити кешування за рецептом Вікіпедії, і просто виводимо поточний час.
Відмінно! Тепер клацніть по своєму файлу test-1.php і запам'ятайте час (для прикладу я розмістив вікно браузера поруч з годинником Windows):
Чудово! Тепер натисніть в браузері кнопки «Назад» і потім «Вперед»:
Упc! Час не змінюється. А що це означає? Та тільки те, що браузер бере сторінку з кешу. А як же наш енциклопедичний код? Так він не працює!
Звернемося до першоджерел
У чому ж проблема? Проблема в неправильному використанні заголовків відповіді. У специфікації RFC2616 кешуванню присвячений цілий розділ. Але, на жаль, веб-майстри не часто читають специфікації. Отже, що ж позначають ті заголовки, які ми тільки що передали? Давайте їх подивимося. Це дуже зручно робити за допомогою доповнення до браузеру Firefox Web Developer Toolbar. Information. View Response Headers (для IE схожий інструмент називається DevToolbar):
Отже, ми передали такі заголовки:
Тобто, «дай документ, якщо він змінився з вказаної дати», і сервер повинен відповісти або 200 ( «Ось документ, він змінився!» Або 304 «Змін не було». Але щоб це працювало, ваш сервер ПОВИНЕН передавати заголовок Last- Modified, і не просто передавати, а передавати ПРАВИЛЬНУ ДАТУ зміни документа. Але ми самі, своїми руками, і недолугим енциклопедичним кодом повністю зруйнували останні надії на це! тобто, мало того, що ми кеш не заборонили, ми ще і пошуковикам (а точніше, СОБІ) грунтовно нагадили! Адже ви передали ПОТОЧНУ дату, як дату оследнего зміни, пам'ятаєте?
Cache-Control: no-cache, must-revalidate - ось, вже ближче до теми. Саме цей заголовок управляє кешуванням, але не сам, а в сукупності з іншими. Зараз же ми просто передали наступну команду: «використовувати інформацію наступного запиту без повторної перевірки на вихідному сервері можна» (If the no-cache directive does not specify a field-name, then a cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server). В основному, в такому вигляді - це команда не для браузера, а для проксі-сервера.
Pragma: no-cache - застаріла конструкція. Це зі старої версії протоколу HTTP / 1.0. Практично всі браузери і проксі її ігнорують. Отже, ми бачимо, що жодна з наших рядків PHP коду реально кеш не заборониш. Що ж робити? А ось що:
заборона кешування
Перезберегти файл test-1.php з новим ім'ям test-2.php і змініть його наступним чином:
Тепер спробуйте знову відкрити нашу тестову папку // localhost / test-cache /. клацніть на ім'я test-2.php і тепер наживати кнопки «Назад», «Вперед». Час щоразу змінюється! І це говорить про те, що браузер не бере сторінку з кешу при переході вперед / назад, а заново запрошувати її з сервера. Що, власне, нам було і потрібно. Давайте подивимося заголовки відповіді:
Ось воно! Ми передаємо два заголовка:
Cache-Control: no-store - сторінка містить приватні дані, зберігати в кеші не можна! (The purpose of the no-store directive is to prevent the inadvertent release or retention of sensitive information (for example, on backup tapes))
І саме ці заголовки забороняють кешування в браузері. Але все ж більш правильно дописати в заголовок Cache-Control інструкції і для проксі-серверів (файл test-3.php):
Практичне заборона кешування
Відмінно! Тепер просто створіть у своїй папці файл .htaccess і впишіть в нього наступне:
Усе! Необхідні заголовки передаються автоматично, і спеціально з писати в PHP вже не потрібно - кеш вже вимкнений! У цьому легко переконається, якщо подивитися заголовки, що передаються при запиті БУДЬ файлу цієї папки:
дозвіл кешування
Але, не дивлячись на те, що переважна кількість веб-майстрів, вважають кеш вселенським злом, і намагаються заборонити його (і як ми побачили, дуже безуспішно), це не так! Заборонивши кешування, ви змушуєте браузер кожен раз заново завантажувати ваші сторінки з сервера, і якщо канал зв'язку у користувача слабкий, то це може привести до помітного уповільнення роботи з вашим сайтом. Я вже не кажу про те, що це призводить до зростання навантаження на ваш сервер! Якщо ваша сторінка або її частина формується запитами в БД, ви, до того ж, збільшуєте навантаження на сервер БД, що вкрай негативно може позначитися на продуктивності вашого сервера в цілому. Ви ж розумієте, про що я говорю, наприклад, подивіться на роботу Одноклассники.ру! Деякі веб-майстри ще й хваляться, виводячи таку «статистику» внизу сторінки: «Сторінка сформована за 0.9 сек, виконано 9 SQL запитів». Нічого, крім абсолютно безглуздої архітектури Веб-додатки, це не показує!
Так давайте ж навпаки постараємося розвантажити сервер, і прискорити роботу нашого користувача! І кеш в цій справі - один з потужних інструментів! Ну скажіть будь ласка, як часто змінюється ваша сторінка «Про компанії»? Або що трапиться, якщо користувач побачить вашу новина ( «ура! Ми переїхали на новий движок») годиною пізніше? Так навіщо ж забороняти кешування таких сторінок
Спробуйте перезберегти наш тестовий файл з ім'ям test-4.php і напишіть в нього такі рядки:
Дозвіл кешування вмісту папки
А можна і взагалі без PHP обійтися. Створіть в папці файл .htaccess і впишіть в нього наступне:
Можливість включення сторінок в кеш істотно поліпшить швидкість роботи веб-сервера і частково звільнить від численних повторних звернень до них. Дозвіл кешування на проксі-сервері вказується в заголовку header:
Директива ExpiresActive on включає кешування зображень, що дозволяє прискорити їх завантаження при повторному зверненні до сторінок сайту.
Директиви ExpiresByType image / jpeg "access plus 3 day" і ExpiresByType image / gif "access plus 3 day". в свою чергу, визначають формат зображень і термін, на який буде вироблено кешування. За замовчуванням, виконується кешування зображень формату .jpeg і .gif терміном на 1 день.
Результат, як говориться, видно неозброєним поглядом. Особливо це ефективно робити для графіки сайту, для сторінок, що містять рідко змінюваний контент або для часто відвідуваних сторінок, наприклад, для стартової.
Тільки рекомендація: спочатку повністю отладьте ваш сайт і тільки після цього включайте кешування! Інакше ви ризикуєте в пошуках помилок посивіти і повністю розчаруватися в веб-технологіях Успіхів вам і удачі з кешуванням!