1. Вступна частина
2. Як подивитися http заголовки в Chrome
3. Аналіз http-заголовків, що відповідають за кешування
4. Http-заголовки, що відповідають за клієнтське кешування
5. Status Code
6. Expires
7. Cache-Control
8. ETag і If-None-Match
9. Last-Modifed і If-Modified-Since
10. Які http заголовки повинні бути для правильного налаштування кешування
11. Які суті кешувати
12. Головна сторінка
13. Сторінка окремої публікації.
14. Проблема кешування html-файлів в WordPress
15. Файли ізобрежній, листи стилів (style.css), скрипти (scripts.js)
16. Що робити, якщо сутність змінилася, а термін придатності кешування не закінчився

зміст

1. Вступна частина .
2. Як подивитися http заголовки в Chrome .
3. Аналіз http-заголовків, що відповідають за кешування .
4. Http-заголовки, що відповідають за клієнтське кешування .
5. Які http заголовки повинні бути для правильного налаштування кешування .
6. Які суті кешувати .
7. Як налаштувати користувальницький кешування в WordPress .
8. Проблема кешування html-файлів в WordPress
9. Отримати плагін браузерного кешування html-сторінок для WordPress
10. Файли ізобрежній, листи стилів (style.css), скрипти (scripts.js)
11. Що робити, якщо сутність змінилася, а термін придатності кешування не закінчився .

Якщо подивитися на рекомендації Гугла по швидкості завантаження сторінки , Можна побачити вимоги до використання кеша браузера. Іноді вимога кешування знаходиться в червоній області, іноді в жовтій.

Крім збільшення швидкості завантаження сторінки у користувача, зниження навантаження на канал і сервер, кешування в браузері може впливати на індексацію пошуковими роботами. Принаймні так написано в інструкціях Яндекса і Гугла .

Яндекс: Слідкуйте за коректністю http-заголовків. Зокрема, важливо, зміст відповіді, який сервер віддає на запит «if-modified-since». Тема Last-Modified повинен віддавати коректну дату останньої зміни документа.

Як видно з цитати хелпа, Яндекс вимагає коректну дату в заголовку Last-Modified. А заголовок Last-Modified має пряме відношення до кешірірованію. Ще одне очко на користь необхідності розібратися з кешуванням.

Яндекс загрожує проблемами : Навіть якщо сервер не видає дату останньої модифікації документа (last-modified), ваш сайт буде проіндексований. Однак в цьому випадку слід враховувати наступне:

• в результатах пошуку не відображатиметься дата поруч зі сторінками вашого сайту;
• час сортування за датою сайт не буде видно більшості користувачів;
• робот не зможе отримати інформацію про те, чи оновилася сторінка сайту з моменту останнього індексування. А так як число сторінок, одержуваних роботом з сайту за один захід, обмежена, змінилися сторінки будуть переіндексувати рідше.

Гугл таких жахів в хелпе не пише. Просто інформує про можливість знизити навантаження і прискорити завантаження за рахунок кешування (це ми вже і так знаємо).

Гугл: Переконайтеся, що ваш веб-сервер підтримує HTTP-заголовок "If-Modified-Since". Цей заголовок дозволить веб-сервера повідомляти Google, чи змінився контент сайту з часу останнього сканування. Підтримка цієї функції скорочує витрати і навантаження на смугу пропускання.

Крім того, неправильні заголовки можуть привести до того, що користувач не побачить поновлення на вашому сайті.

Виходячи з усього вищесказаного, я думаю, має сенс детально розібратися в питанні кешування на стороні клієнта.

Хочу зауважити, що є два типи кешування: кешування на стороні клієнта і на стороні сервера. У даній статті мова йде про перший тип кешування. Однак, з метою зниження навантажень на сервер (якщо ви хочете залишитися на більш дешевому тарифі хостера при зростанні відвідуваності), необхідно застосовувати і серверне кешування сторінок. Я писав про свій досвід в зниженні навантажень завдяки установці MaxCache на WordPress .

Вступна частина

Отже, що ми знаємо про кешування на стороні клієнта, тобто в браузері користувача сайту. Виявляється, існує якісь http-заголовки, що віддаються сервером браузеру, які ми візуально на сайті не спостерігаємо, але вони повідомляють браузеру певну службову інформацію. Частина переданих заголовків відповідає за кешування. Наприклад, на вказаний в заголовках період, браузер збереже завантажену сторінку і до закінчення зазначеного терміну придатності буде відображати локально збережену копію.

Пару слів про те, яка ще інформація міститься в http-заголовки. У заголовках часто передається інформація про кодуванні сторінки , Яка виявляється пріоритетною над інформацією, вказаною в тезі meta розділу head. Ще в заголовках може міститися інформація про Pingback-ах, яку спамери використовують для своїх чорних справ, з цим можна боротися . Також в заголовках передається код відповіді сервера (404, 200, 301 ...).

У плані налаштувань кешування з усієї маси http-заголовків , Нас будуть цікавити чотири заголовка з групи відповіді сервера або Response Headers: Cache-Control, Expires, ETag, Last-Modifed і два заголовка з групи запиту браузера або Request Headers: If-Modified-Since, If-None-Match.

Як подивитися http заголовки в Chrome

Спочатку потрібно зрозуміти той факт, що заголовки для кожної сутності на сторінці будуть свої. Під сутністю я розумію наступне:

• сам html-код сторінки, відкритої в браузері;
• картинки, що використовуються на сторінці;
• інші підключаються в коді сторінки додаткові файли (style.css, scripts.js, бібліотека jquery ...).

Як я писав вище, без хитрощів http-заголовки не помітити. Для їх перегляду на аналізованої сторінці в Google Chrome потрібно відкрити інспектор коду і перейти на вкладку Network, після чого відновити сторінку. У інспектора коду буде спостерігатися процес завантаження сутностей. Клік по кожній з сутностей дозволить переглянути http-заголовки обраної суті.

У самому верху списку сутностей буде html-код завантаженої в браузері сторінки. Нижче ви можете спостерігати файли зображень, що використовуються в контенті Сторінка, листи стилів, файли скриптів і т.д.

Аналіз http-заголовків, що відповідають за кешування

Розглянемо http-заголовки завантаженої в браузері html-сторінки. Для цього потрібно клікнути по назві відповідної сутності в інспектора коду. Орієнтуючись на скріншот вище - потрібно клікнути по виділеному червоною рамкою назвою «rabochee-prostranstvo-9». Результат (на скріншоті нижче) відобразить всі http-заголовки для даної сутності (сутність в даному випадку - це html-сторінка, відкрита в браузері і тільки вона без додаткових файлів, які використовуються в її контенті).

Ви без праці відшукайте групи заголовків Response Headers і Request Headers.

Наше завдання проаналізувати заголовки відповідають за кешування html-сторінки на стороні користувача. Також звернемо увагу на заголовок Status Code розділу General.

Http-заголовки, що відповідають за клієнтське кешування

Розберемо кожен з http-заголовків, що мають відношення до клієнтського кешування.

Status Code

Відносно Status Code скажу зро.

• Код 200 OK - сутність штатно благополучно віддається сервером і вантажиться користувачеві в повному обсязі.
• Код 304 Not Modified - з останнього відвідування користувачем сторінки сутність, збережена в кеш браузера, не змінилася; а значить немає сенсу займати канал, витрачати трафік і вантажити її знову, можна показати користувачеві збережену в кеші (на комп'ютері користувача) копію.
• Інформацію про значення інших кодів можна подивитися тут .

Тепер докладно знайомимося з заголовками, що відповідають за кешування в групі Response Headers і Request Headers. До Status Code будемо повертатися в процесі.

На аналізованої вами сутності необов'язково будуть присутні всі заголовки, описані нижче. І це нормально.

Expires

Даний заголовок в якості значення містить дату, до якої кеш вважається дійсним.

Дії браузера розгортаються в наступному дусі.

1. Користувач перший раз перейшов на сторінку. Поки немає ніякого кешування і браузеру в заголовку Status Code віддається значення 200 OK для сутності «html-сторінка» (якщо зі сторінкою все впорядке, зрозуміло). Html-файл завантажується з сервера.
2. Якщо при цьому в заголовках міститься Expires, то сутність буде збережена на комп'ютері користувача в кеші до дати, переданої в значенні цього заголовка.
3. При наступному зверненні користувача до сторінки браузер не буде запитувати сутність з сервера до закінчення терміну придатності кеша (зазначеного в значенні заголовка Expires). Сутність буде вантажиться з локальної копії.

Аналогічний алгоритм дій відбувається з усіма сутностями, використовуваними на аналізованої сторінці.

Cache-Control

Даний заголовок в якості значень може містити декілька інструкцій:

• max-age - кількість секунд протягом яких кеш вважається актуальним;
• no-cache - наявність інструкції повідомляє, що кешувати можна, але при кожному зверненні потрібно перевіряти зміни сутності, що зберігається на сервері, щодо кеша (про те, як здійснюється ця перевірка, піде мова нижче);
• no-store - взагалі забороняє зберігати сутність в кеш;
• private або public - перша інструкція забороняє, а друга дозволяє кешувати сторінку на проміжних пристроях (роутерах, наприклад);
• інші директиви в цій публікації розглядати не бачу сенсу.

Якщо порівняти завдання заголовка Expires і Cache-Control: max-age, то вони виявляться ідентичними.

Expires і Cache-Control: max-age потрібні для того, щоб вказати термін придатності кеша. На вказаний період часу браузер буде вантажити сутність з кеша не звертаючись до сервера і не перевіряючи зміни.

Гугл в однієї інструкції радить використовувати тільки Expires і саме його. Одночасно вказувати обидва заголовка Гугл вважає надмірним; при цьому прямо на сторінці інструкції присутні обидва заголовка (хоча це ні про що не говорить). В інший інструкції йдеться, що сучасним і повністю підтримуваним виявиться Cache-Control: max-age.

На більшості аналізованих мною сайтів я виявив обидва заголовка Expires і Cache-Control: max-age. На щастя, що міститься в них інформація не перечила друг-другу.

ETag і If-None-Match

У значенні заголовка ETag передається набір символів, що ідентифікує стан сутності. При будь-яких змінах по суті змінюється значення заголовка.

Як значення заголовка може бути передана або просто версія суті (цифра 1, 2, 3 ...) або хеш (набір символів, складений на основі контенту суті і унікальний для кожного його стану).

Поведінка браузера при отриманні мітки Etag

• Отримавши заголовок ETag браузер повинен зберегти його значення і, коли час кешування, вказане заголовками Expires і / або Cache-Control: max-age закінчиться, браузер відправить запит If-None-Match, в значенні якого буде міститися раніше збережена мітка ETag.
• Сервер порівняє актуального значення ETag суті і надісланий в заголовку If-None-Match.
• Якщо мітки однакові - зміни суті не відбувалося і її можна вантажити з кеша. При цьому актуальність кеша знову триватиме на період, зазначений у Expires і / або Cache-Control: max-age.
• Однакові мітки чи ні перевіряє сервер. Якщо мітки однакові - сервер відправляє заголовок Status Code зі значенням 304 Not Modified і браузер вантажить сторінку з кеша. Якщо мітки різні чи це перші відвідини суті - ми отримаємо код 200 OK, сутність в повному обсязі буде вантажиться з сервера.

Last-Modifed і If-Modified-Since

У значенні заголовка Last-Modifed зберігається дата останньої модифікації сутності.

Алгоритм дій відрізняється від вищеописаного варіанта з ETag тільки тим, що в разі отримання браузером заголовка Last-Modifed, він збереже дату, зазначену в Last-Modifed і буде перевіряти актуальність кеша відправляючи сервера заголовок If-Modified-Since зі збереженою датою.

Експерименти показали, що деякі сервери, в разі отримання від браузера заголовка If-Modified-Since, не віддають заголовок Last-Modifed, який, в принципі, був отриманий браузером при першому відвідуванні. У цьому є певна логіка.

По суті справи ETag і Last-Modifed виконують однакові функції: інформують про зміну суті з моменту останнього звернення.

Гугл радить використовувати один із заголовків (в цей раз, будь-який) і не вказувати обидва одночасно.

На початку статті я писав про бажання Яндекса бачити в http-заголовки Last-Modifed. В результаті вибір зробили за нас 🙂

Загадка для уважного читача. Так що використовувати щось? ETag або Last-Modifed ??? Є ті, кому не зрозуміло?

Які http заголовки повинні бути для правильного налаштування кешування

Підсумуємо. Грунтуючись на рекомендаціях Гугла і Яндекса, а також усього вищесказаного, робимо висновок.

1. Тема Expires або Cache-Control: max-age повинен бути у тій суті, яку ми збираємося кешувати.
2. Тема Last-Modifed також повинен бути у кешіруемой суті.
3. Сучасні реалії говорять про те, що Expires весь час йде в парі з Cache-Control: max-age. Головне, щоб вони один одному не суперечили.

Які суті кешувати

Які суті нам підвладні:

• html-код сторінки;
• картинки;
• наші файли скриптів;
• файл стилів.

Саме заголовкам html-файлу потрібно приділити особливу увагу, тому що їх ніхто не налаштовує, а думка Яндекса з цього приводу ви вже знаєте.

З приводу непідвласного нам не парімся:

• віджети коментарів, наприклад, той же disqus , Який використовується на цьому блозі;
• завантаження з серверів Гугла jQuery;
• ну і т.д.

В одній книзі по jQuery рекомендували цю саму бібліотеку jQuery вантажити з серверів Гугла, а не як за замовчуванням в WordPress зроблено: з надр самого движка. Якщо зараз подивитися на заголовки, непідвладні нам, що посилаються сервером Гугла при завантаженні jQuery (прямо на цій сторінці дивіться, цей сайт хоч і на WP, але я налаштував завантаження бібліотеки звідки треба), то ми побачимо, що кешіроуется вона на рік. І частка ймовірності, що користувач відвідав перед моїм чудовим ресурсом інший сайт, де теж використовується jQuery з сервера Гугла з кешуванням на рік, дуже висока. Відповідно, відвідувачеві не доведеться знову вантажити jQuery на моєму сайті, бібліотека є в його локальному кеші. Та-дааа!

Природно, ми будемо розглядати тільки ті сутності, які нам підвладні. Кешування всяких там коментарів Вконтакте, disqus і інших, підвантажуваних із зовні віджетів, налаштовуються їх авторами.

Головна сторінка

Йдеться про кешування браузером саме html-файлу головної сторінки.

Якщо на головній сторінці публікуються посилання на свіжі пости, то я не бачу сенсу вказувати хоч якийсь часовий проміжок, протягом якого браузеру не треба перевіряти актуальність кеша.

Для цього і призначений заголовок Cache-Control: no-cache, який дозволить зберегти сторінку в кеші, але при кожному зверненні буде перевірятися актуальність збереженої копії.

Можливо, буде також правильним все ж вказати для головної сторінки Cache-Control: max-age зі значенням в кілька годин. Тому як смикати кожного разу сервер перевіркою актуальності кеша не надто раціонально. Це привід для дискусії в коментарях, ласкаво прошу. Все питання в тому, на скільки сильно напружується сервер при перевірці актуальності кеша і як часто оновлюється контент вашої головної сторінки.

Абсолютно для всіх html-сторінок повинен бути вказаний заголовок Last-Modified.

Для головної сторінки датою для Last-Modified може служити, наприклад, дата додавання свіжого поста, який потрапив на головну. Тобто будь-яка зміна контенту головною повинно привести до встановлення свіжого значення Last-Modified.

Якщо головна сторінка статична, то дивіться мої міркування про кешування сторінках публікації.

Мої міркування по кешування рубрики повністю збігаються з міркування по динамічної головній сторінці.

Сторінка окремої публікації.

Ось тут можна використовувати Cache-Control: max-age. Думаю, доби кешування буде досить. Припустимо, контент публікації ви оновлюєте не часто, але стан посилань в сайдбарі на свіжі або популярні пости буде заморожено на термін придатності кеша.

Але не варто забувати про коментарі. Якщо ви використовуєте сторонній сервіс коментарів (disqus або cackle ), То він сам відповідає за кешування виведених коментарів і можна не паритися. А якщо коментарі стандартні, від движка, то потрібно враховувати частоту оновлення коментарів.

Проблема кешування html-файлів в WordPress

За замовчуванням WordPress НЕ кешує html-сторінки і не передає заголовок Last-Modified. А міркування, викладені вище, говорять про необхідність присутності Last-Modified на всіх сторінках для сутності «html-сторінка».

Ось як виглядають http-заголовки сторінки окремої публікації в WP за замовчуванням:

Last-Modified немає, Etag немає. Сторінку не потрапить в кеш.

Насправді, через таких заголовків, html-файл постійно вантажиться з сервера, кешування для нього не працює. На підтвердження цього ми бачимо код 200 OK при кожному оновленні сторінки.

Очевидно, для вирішення питання потрібно застосовувати плагін. Я проаналізував різноманітні плагіни браузерного кешування для WordPress. Але жоден з них не показав адекватної роботи. Швидко написати плагін для вирішення завдання у мене не вийшло, тому що є складність одночасної роботи з плагінами серверного кешування. Потрібно все уважно продумати і знайти рішення. Я залишу форму підписки нижче. Після того, як плагін буде готовий, я відправлю його на вказану адресу ел. пошти.

Файли ізобрежній, листи стилів (style.css), скрипти (scripts.js)

Ви без зусиль знайдете всі ці сутності в інспектора Google Chrome. Нормальні хостери автоматично встановили всі необхідні заголовки кешування для файлів зображень, скриптів і листів стилів. Однак, ступінь адекватності встановлених значень може різнитися.

На скільки часто ви міняєте зображення в постах, залишаючи при цьому ім'я файлу картинки незмінним? Думаю, картинки постів і зображення оформлення сторінки - це дуже стабільні суті. Їм можна давати тривалий термін для знаходження в кеші браузера без перевірок. Максимальний термін - рік, можливо це те, що потрібно.

Аналогічна ситуація з листами стилів і файлами скриптів. Змінюються вони не часто. Пару тижнів кешування без права перевірки?

Що робити, якщо сутність змінилася, а термін придатності кешування не закінчився

Припустимо, ви внесли зміни в лист стилів. Це буває часто. І, припустимо, ви хостів на Бегета. Це буває ще частіше.

Бегета так налаштував кешування, что поновлень аркуша стілів НЕ перевірятімуть тиждень (Cache-Control: max-age = 604800). Ви побачите зміни тільки якщо натиснете на кнопку «оновити» в браузері, звичайний перехід на сторінку викличе завантаження листа стилів з локального кеша. Виходить, відвідувач побачить ваші оновлення через тиждень.

Якщо задуматися, то проблема може бути не такою страшною. Я не думаю, то знайдеться багато відвідувачів, які ходять на ваш сайт кожен день. Але все ж. Щоб змусити постійних відвідувачів оновити кеш листа стилів до закінчення його терміну дії досить просто змінити ім'я файлу. Новий файл = новий кеш.

Був просто style.css, а стане style.css? V = 1. Кожне оновлення листа стилів і ми міняємо цифру. В результаті користувач бачить завжди свіже оформлення.

Автор статті: Андрій Морковин.