HTTP кеширане: как сайтът използва повторно вече получените данни

Полезно е да знаеш

Когато отворим уеб страница, браузърът получава документи, изображения и други ресурси. Част от тези отговори могат да бъдат запазени и използвани при следващо посещение. Това е основната идея на HTTP кеширането. Вместо един и същ файл да се прехвърля многократно, подходящото копие обслужва следващата заявка. Ползата е по-малко пренесени данни, а при определени сценарии и по-малко работа за сървъра. Кешът обаче има нужда от правила кога копието остава подходящо. [1]

Има съществена разлика между личния кеш на браузъра и споделения кеш пред сайта. Първият обслужва конкретния клиент. Вторият, например управляван кеш в CDN, може да връща запазен отговор на различни посетители. Това е удобно за общодостъпни изображения и еднакви страници, но изисква внимание при съдържание от потребителски профил. Един адрес не означава непременно един и същ отговор за всички хора. Самото наличие на бисквитка също не е достатъчно правило за поверителност. [1]

Заглавката Cache-Control описва важна част от поведението. Директивата max-age задава срок на свежест в секунди. При private отговорът е предназначен за личен кеш, а не за споделено съхранение. Особено лесно се бъркат no-cache и no-store: първата допуска запазване, но изисква проверка преди повторна употреба; втората забранява съхраняването на конкретния отговор. Следователно надписът no-cache не означава автоматично, че браузърът няма никакво запазено копие. [2]

Проверката може да бъде значително по-малка от повторното изтегляне. Сървърът изпраща ETag — идентификатор на версията на ресурса. При следваща условна заявка клиентът връща този идентификатор чрез If-None-Match. Ако представянето не е променено, сървърът може да отговори с 304 Not Modified без тяло. Клиентът тогава използва вече наличното съдържание. Ако версията е различна, трябва да получи новия ресурс. ETag не е задължително контролна сума; конкретният начин на генериране се определя от сървъра. [3]

Да разгледаме условен пример с общодостъпна илюстрация към статия. Ако тя не се променя, повторното изпращане на същите байтове при всяко отваряне няма редакторска стойност. Когато дизайнерът я замени обаче, старото копие вече може да показва грешна схема. Един практичен подход е новата версия да получи различен адрес, например име на файл с версия. Така старото и новото изображение се различават и за кеша, а документът може изрично да посочи желаното. [2]

За да разберем реалното поведение, трябва да различаваме три ситуации: използване на свежо локално копие, проверка на запазена версия и изтегляне на целия отговор. Те могат да изглеждат еднакво за читателя, но водят до различен мрежов трафик. Отговорът 304 все още означава комуникация със сървъра; той не е равнозначен на липса на заявка. Затова при оценяване на ускорението е полезно да се гледат както кодът на отговора, така и прехвърлените данни. [1, 3]