Как обновить css в кэше

Обновлено: 24.01.2025

Использование кэширования в браузере способствует улучшению скорости загрузки вашего сайта для постоянных посетителей. Однако, когда у вас на сайте новый контент, из-за кэширования пользователям будет показан устаревший контент.

Лучший способ избежать этой проблемы – реализовать так называемое «управление версиями» для содержимого сайта на WordPress. В результате пользователи всегда будут видеть последнюю версию, даже если их браузеры закэшировали контент вашего сайта. В сегодняшней статье мы подробно поговорим о кэшировании в браузере, управлении версиями, а также рассмотрим способы их реализации в WordPress.

Что такое управление версиями

Кэширование в браузере – это процесс, при котором браузер сохраняет файлы с вашего сайта на устройствах посетителей, что позволяет браузеру не загружать эти файлы при повторном посещении. Это простое решение, которое помогает значительно сократить время загрузки сайта.

При использовании кэширования в браузере, обычно устанавливаются даты истечения срока «жизни» для нужного содержимого. Например, для этих целей используется файл .htaccess, в котором указываются определенные периоды хранения файлов определенных типов. После истечения этого периода, браузеры пользователей будут проверять наличие новых версий этих файлов.

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

Управление версиями, также известное как «очистка кеша», решает эту проблему путем автоматического принудительного обновления кеша в случае изменения файла. Это простой обходной путь, который позволяет реализовать кэширование в браузере с большим сроком жизни, и не беспокоиться об отображении устаревшего контента. Однако для настройки этого пути требуется некоторая работа, что приводит нас к следующему разделу.

Управление версиями как способ обновления кэшированного содержимого в WordPress

Сейчас мы рассмотрим процесс установки версий файлов разных типов, что будет принудительно очищать кэш браузера у пользователей. Имейте в виду, что данные способы могут приводить к конфликтам, если вы используете в системе плагин кэширования!

Способ №1. Обновление версии дочерней темы

Если вы используете дочернюю тему (а вы должны использовать!), вы можете заставить WordPress загрузить новую версию таблицы стилей style.css с помощью файла functions.php. Для этого используется функция wp_enqueue_style . Кодекс WordPress предлагает использовать следующий формат:

Этот фрагмент кода делает свое дело. Тем не менее, он не включает функцию очистки кэша. Код ниже позволяет вам включить номер версии дочерней темы, что поможет при очистке кэша:

Этот код извлекает номер версии из файла style.css вашей дочерней темы. Обычно файл стилей темы style.css содержит в самом верху примерно такой фрагмент:

Код из файла функций «подтягивает» версию темы из строки Version в файле style.css . Все, что вам нужно сделать, это обновить номер в строке версии и это заставит WordPress загрузить последнюю версию файла стилей.

Способ №2. Переименование статических файлов для принудительного обновления кэша

Предыдущий метод заботится об обновлении вашей дочерней темы. Однако, браузер сохраняет в кеше и многие другие файлы. Например, ранее мы писали о способе настройки кеширования в браузере. Мы использовали фрагмент кода, с помощью которого делали настройки для кэширования картинок, файлов CSS, HTML и JavaScript:

Мы можем использовать файл .htaccess также и для реализации нового набора правил. Используйте следующий код и добавьте его перед тегом </IfModule> предыдущего фрагмента кода:

Этот код говорит WordPress, чтобы система проверяла в файлах перечисленных форматов, наличие номеров в их именах, например:

В этом примере мы внесли изменения в файл style.css и изменили его имя, чтобы обновить кэш файла. 102 в имени файла представляет собой номер версии style.css . WordPress по-прежнему распознает его как файл style.css вашей темы, но изменения, которые мы внесли в .htaccess, позволяют указать, что это новая версия.

После добавления этого кода в файл .htaccess вы сможете установить версии для всех типов файлов, которые вы включили. Например, если вы хотите загрузить новую версию логотипа своего сайта, вам просто нужно переименовать файл, например, в logo.102.jpg.

Заключительные мысли

Внедрение кэширования в браузере – отличный способ обеспечить посетителям вашего сайта быстрое время загрузки. Однако это также может привести к ситуациям, когда вы обновляете свой контент, но пользователи не видят изменений.

Самый простой способ решить эту проблему – использовать управление версиями для содержимого кеша, который использует браузер пользователя. Сегодня мы рассмотрели 2 способа, которые позволяют этого достичь:

Способ №1. Обновление версии дочерней темы
Способ №2. Переименование статических файлов для принудительного обновления кэша

Если у вас остались вопросы по данной теме, смело задавайте их в разделе комментариев ниже.

Я заметил, что некоторые браузеры (в частности, Firefox и Opera) очень усердно используют кэшированные копии файлов .css и .js даже между сеансами браузера. Это приводит к проблеме при обновлении одного из этих файлов, но браузер пользователя продолжает использовать кэшированную копию.

Вопрос в том, что является самым элегантным способом заставить браузер пользователя перезагрузить файл, когда он изменился?

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

Обновить :

После некоторого обсуждения здесь я нашел предложение Джона Милликина и da5id полезным. Оказывается, есть термин для этого: автоматическое управление версиями .

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

Другая идея, предложенная SCdF , заключается в добавлении в файл фиктивной строки запроса. (Некоторый код Python для автоматического использования метки времени в качестве фиктивной строки запроса был представлен пи .). Тем не менее, существует некоторое обсуждение относительно того, будет ли браузер кэшировать файл со строкой запроса. (Помните, мы хотим, чтобы браузер кэшировал файл и использовал его при будущих посещениях. Мы хотим, чтобы он снова извлекал файл только после его изменения.)

Поскольку не ясно, что происходит с фиктивной строкой запроса, я не принимаю этот ответ.

У меня есть это в моей .htaccess, и никогда никаких проблем с кэшированных файлов: ExpiresActive On ExpiresDefault "modification" . Я действительно ценю способ, которым этот вопрос был задан и был обновлен с тех пор. Это полностью описало то, что я должен ожидать в ответах. Я собираюсь следовать этому подходу в моих вопросах отныне. Ура!

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

Обновление 2: Включение комментариев Ника Джонсона о том, что оригинальное .htaccess регулярное выражение может вызвать проблемы с такими файлами, как json-1.3.js . Решение состоит в том, чтобы переписать только если в конце есть ровно 10 цифр. (Поскольку 10 цифр охватывают все метки времени с 9.09.2001 по 20.11.22.)

Сначала мы используем следующее правило перезаписи в .htaccess:

Теперь мы напишем следующую функцию PHP:

Теперь, куда бы вы ни включили свой CSS, измените его следующим образом:

Таким образом, вам больше никогда не придется изменять тег ссылки, и пользователь всегда увидит последнюю версию CSS. Браузер сможет кэшировать файл CSS, но когда вы вносите какие-либо изменения в свой CSS, браузер увидит это как новый URL, поэтому он не будет использовать кэшированную копию.

Это также может работать с изображениями, значками и JavaScript. В основном все, что не генерируется динамически.

Мой собственный статический контент-сервер делает то же самое, за исключением того, что я использую параметр для управления версиями (base.css? V = 1221534296) вместо изменения имени файла (base.1221534296.css). Я подозреваю, что ваш путь может быть немного более эффективным, хотя. Очень круто. @Kip: очень удобное решение. Переписывание URL, очевидно, может предложить гораздо больше, чем просто красивые ссылки. Я вижу проблему в том, что она обращается к файловой системе много раз - точно - количество ссылок * количество запросов / сек . что может быть или не быть проблемой для вас. @AlixAxel: Нет, браузеры будут повторно извлекать его при изменении параметра, но некоторые публичные прокси не будут кэшировать файлы с параметрами url, поэтому лучше всего указывать версию в пути. И издержки на mod_rewrite незначительны по сравнению с любыми другими узкими местами производительности в WPO Первая file_exists проверка действительно необходима? filemtime вернет false в случае неудачи, так почему бы просто не присвоить значение filemtime переменной и проверить, является ли оно false перед переименованием файла? Это сократило бы одну ненужную файловую операцию, которая действительно сложилась бы.

Простая клиентская техника

В общем, кеширование - это хорошо. Итак, есть несколько методов, в зависимости от того, решаете ли вы проблему самостоятельно при разработке веб-сайта или пытаетесь контролировать кеш в производственной среде.

Обычные посетители вашего сайта не будут иметь того опыта, который вы испытываете при разработке сайта. Так как среднестатистический посетитель посещает сайт реже (может быть, только несколько раз в месяц, если вы не являетесь сетью Google или hi5), тогда он с меньшей вероятностью будет хранить ваши файлы в кеше, и этого может быть достаточно. Если вы хотите принудительно ввести новую версию в браузер, вы всегда можете добавить строку запроса в запрос и увеличить номер версии при внесении серьезных изменений:

Это гарантирует, что каждый получит новый файл. Это работает, потому что браузер просматривает URL-адрес файла, чтобы определить, есть ли у него копия в кэше. Если ваш сервер не настроен на какие-либо действия со строкой запроса, он будет проигнорирован, но имя будет выглядеть как новый файл для браузера.

С другой стороны, если вы разрабатываете веб-сайт, вы не хотите менять номер версии каждый раз, когда сохраняете изменения в своей версии для разработки. Это было бы утомительно.

Поэтому, пока вы разрабатываете свой сайт, хорошим трюком будет автоматическая генерация параметра строки запроса:

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

Так что, хотите верьте, хотите нет, но на самом деле ваш сервер делает этот кеш браузера таким постоянным. Вы можете настроить параметры сервера и изменить заголовки EXPIRES, но небольшая техника, которую я написал выше, вероятно, намного проще для вас. Поскольку кэширование - это хорошо, обычно вы хотите установить эту дату далеко в будущее («Заголовок истекает в далеком будущем») и использовать метод, описанный выше, для принудительного изменения.

В предыдущих статьях мы сформировали форму поиска, предназначенную для ввода запросов. И теперь можно заняться размещением на сайте и результатов поиска.

Однако, прежде чем к этому перейти, необходимо решить вопрос обновления статических файлов в кэше браузера.

Дело в том, что отображать результаты Яндекс.Поиска можно только на сайте, размещенном в интернете. Использования для этих целей ранее рассматриваемого варианта "newsite.local", установленного на локальном веб-сервере, невозможно.

Это связано с тем, что Яндекс.Поиск после каждого выполнения запроса свои результаты выводит на определенную страницу реального сайта. В нашем случае была определена страница тестового сайта с адресом "https://avtobezugona.ru/poisk.html".

Поэтому для этих целей будем работать на действующем ресурсе avtobezugona.ru, полностью соответствующим создаваемому сайту "newsite.local", размещенному на локальном веб-сервере, с которым обычно мы проводимые различные мероприятия по его доработке.

А в связи с тем, что формирование внешнего вида страницы результатов поиска будет выполняться с помощью стилей CSS на реальном сайте, расположенных в отдельном файле "main.css", необходимо предусмотреть обновление кэша браузера (буфер памяти браузера с высокой скоростью обмена, используемый для временных файлов).

В противном случае, при отображении страниц возможно, что браузер не будет воспринимать изменения стилей CSS. В таких случаях при загрузке страниц будет использоваться последняя (до изменений) хранящаяся в его кэше версия файла "main.css".

И в этой статье мы рассмотрим некоторые способы обновления буфера браузера в случае изменения содержимого кэшируемых статических файлов. В данном случае, нас интересует "main.css" с выделенной таблицей стилей CSS. Хотя аналогичные преобразования для упрощения обновлений сайта полезно сделать и для других ресурсов, например, содержащих скрипты "JavaScript".

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

Здесь же будет решаться лишь конкретный вопрос - обновление кэша браузера при изменении статического файла "main.css". Для того, чтобы в следующей статье мы смогли перейти к размещению результатов Яндекс.Поиск, оформив соответствующую страницу под дизайн сайта с помощью стилей CSS.

Как известно для ускорения загрузки сайта используется кэширование статических редко изменяемых файлов. При котором браузер при первом открытии страницы сайта загружает определенные типы файлов в локальный кэш (буфер памяти с высокой скоростью обмена, используемый для временного хранения данных).

А далее при последующих загрузках такие данные используются браузером не с сервера, а из сохраненного ранее кэша. Что и приводит при повторных посещениях сайта к существенному уменьшению времени загрузки страниц.

Необходимо отметить, что если даже соответствующие HTTP-заголовки, предназначенные для кэширования, в файле ".htaccess" не установлены, то все равно следует учесть этот механизм при работе сайта. Так как, по крайней мере один из модулей с настройками кэширования обычно стоит на сервере у провайдера по умолчанию.

Ниже показан скриншот ответа сервера, полученный с помощью сервиса Яндекс.Вебмастер по запросу к "main.css" сайта "avtobezugona.ru".

Рис.1 Ответ сервера на обращение к файлу main.css

Как видно, в нашем случае при отсутствии каких-либо настроек кэширования в ".htaccess", в ответе сервера мы имеем заголовки "Last-Modified", "Cache-Control" и "Expires". А значит браузерное кэширование включено, причем с временем жизни кэша в 604800 секунд, соответствующее одной недели.

Проверяем отображение страницы при изменении файла main.css до преобразований

Если же сейчас попытаться изменить файл "main.css", то может получиться так, что браузер будет отображать страницы не учитывая сделанные изменения в стилях CSS. Так как в таком случае будет использовать ранее его сохраненную версию в своем кэше.

Сейчас проверим, как будет вести себя браузер в нашем случае. Для этого сделаем некоторые изменения в "main.css", например, изменим цвет подзаголовков статей с темно-красного на зеленый, как показано в следующем фрагменте кода.

main h1, main h2

font-size : 1.1875em;

font-style : italic;

font-weight : bold;

Рис.2 Замена цвета подзаголовков статей в файле "main.css"

А затем откроем одну из страниц сайта и посмотрим, воспринял ли браузер такое изменение, или он при загрузке будет использовать ранее сохраненный ресурс "main.css".

Ниже показан результат отображения главной страницы сайта "avtobezugona.ru" в Яндекс браузере после выполненных изменений.

Рис.2 Результат отображения страницы при изменении файла "main.css" до преобразования

Как видно, цвет подзаголовков не изменился, что означает - браузер в данном случае при загрузке использует ранее сохраненную версию файла "main.css".

И понятно, что в таком состоянии сложно будет заниматься стилями CSS, так как просто невозможно будет оценить их изменения на отображаемых страницах сайта.

А для того, чтобы устранить этот недостаток, сделаем некоторые преобразования.

Суть способа автоматического обновления кэша браузера

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

При чем, это относится не только к файлам ".css", но и весьма полезно использовать такой метод и в отношении других ресурсов, скажем для ресурсов со скриптами "JavaScript". После чего можно будет не волноваться, что при очередном обновлении таблицы стилей CSS, либо JS-скриптов, у пользователей во внешнем виде страницы или в работе функционала может что-то исказиться.

Суть данных преобразований состоит в том, что в теге <link>, в котором подключается таблица стилей CSS к веб-странице (далее будем рассматривать преобразования только для файла CSS), в конце имени файла добавляется псевдопараметр, меняющийся при каждом изменении содержимого файла.

И таким образом, в случае измененного псевдопараметра браузер будет понимать, что необходимо загрузить новый файл и обновить его в своем кэше. При последующих же загрузках, если псевдопараметр не изменится, браузер при формировании страницы будет использовать последний сохраненный в своем буфере ресурс.

Если посмотреть в интернете, то можно увидеть, что при таком способе нередко предлагается изменять псевдопараметр, используя для этого отдельный файл, либо просто вручную меняя его в теге <link>.

Понятно, что это не совсем удобно. Поэтому мы поступим по другому - псевдопараметр будем менять автоматически, даже при незначительном изменении содержимого файла. И в его качестве будем использовать хеширование (преобразование массива данных в выходную строку фиксированной длины), либо время последнего изменения файла.

Выполняем преобразование имени файла main.css

Сначала рассмотрим вариант с расчетом хеш-суммы содержимого файла, например CRC16, CRC32, SHA-1, SHA-2 и т.п. Допустим, для определения контрольной суммы применим алгоритм MD5 - специальную PHP-функцию "md5_file(), возвращаемую хеш в виде 32-символьного шестнадцатеричного числа.

Исходя из этого составим PHP-скрипт для подсчета хеш-суммы "main.css". При этом разместим его в шаблоне главной страницы "index.php", где также находится тег <link>, предназначенный для подключения таблицы стилей CSS.

$xesh = md5_file ($url_css);

Рис.3 Скрипт для получения MD5-хеша файла "main.css"

Здесь в строке 2 переменной $url_css присваивается значение имени файла, к которому будет применена функция md5_file(). Причем используемое в значении переменной имя хоста определяется с помощью массива $_SERVER с индексом "SERVER_NAME". В результате чего получается абсолютный адрес файла "main.css". Но можно использовать и относительный адрес. Для данного файла он будет "styles/main.css".

А в 3-ей строке вычисляется сама хеш-сумма содержимого "main.css", которая обозначается переменной $xesh .

Далее через переменную $xesh добавим полученный результат MD5-хеша в тег <link> следующим образом:

Рис.4 Добавление псевдопараметра в тег <link>

И теперь в случае изменения содержимого файла "main.css" в соответствующем теге <link> будет заменяться псевдопараметр.

В результате чего, при первой загрузки страницы браузер будет использовать новую версию файла с обновлением своего кэша.

Другой вариант применения псевдопараметра, который мы здесь рассмотрим - это использование времени последнего изменения файла. Особенность его в том, что в отличие от предыдущего, при таком способе, практически, будет отсутствовать какая-либо дополнительно вносимая в работу скрипта задержка, связанная с выполнением этого фрагмента кода. По крайней мере ей можно пренебречь.

Обусловлено это тем, что при таком варианте не требуется производить какие-либо вычисления, а просто, с помощью специальной функции "filemtime() отслеживать время последнего изменения содержания файла. В таком случае предыдущий код можно представить несколько в ином виде.

$lasttime = filemtime ($filename);

Рис.5 Скрипт для получения времени последнего изменения файла "main.css"

Рис.6 Добавление псевдопараметра времени последнего изменения файла в тег <link>

Проверяем обновление кэша браузера измененного файла main.css после преобразований

Теперь, после выполненных преобразований тем, или иным способом (в данном случае воспользуемся первым вариантом), можно проверить, как будет отображаться страница при изменениях файла "main.css".

Для этого достаточно лишь обновить страницу, так как тестовая замена цвета подзаголовков в таблице стилей была сделана ранее во втором разделе статьи.

Рис.5 Результат отображения страницы при изменении файла "main.css" после преобразования

Как видно, результат налицо. Теперь браузер отобразил страницу в соответствии с последней версией "main.css", а именно изменил цвет подзаголовков с темно-красного на зеленый. При этом кэш браузера тоже обновился новым файлом.

Можем также посмотреть, как теперь будет выглядеть имя файла в теге <link>, в котором подключается таблица стилей CSS.

Для этого воспользуемся дополнительными инструментами браузера, в данном случае Яндекс браузера, и посмотрим на HTML-код отображаемой страницы.

Рис.6 HTML-код веб-страницы после преобразований

Видно, что теперь в соответствующем теге <link> добавился псевдопараметр с хеш-суммой, соответствующей содержимому последней версии файла "main.css".

Теперь, если отменить ранее сделанные изменения стилей CSS, то можно будет убедиться, что браузер вернет цвет подзаголовков в прежнее состояние. И при этом в кэше будет сохранена предыдущая версия "main.css", но уже с другим псевдопараметром.

Рис.7 Возвращение цвета подзаголовков в прежнее состояние

А кроме этого, посмотрим, какое теперь значение принял псевдопараметр в теге <link> после возвращения цвета в прежнее состояние.

Рис.8 HTML-код веб-страницы после замены цвета подзаголовков

Как видно, псевдопараметр изменил значение, соответствующее теперь хеш-сумме новой версии файла "main.css".

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

Если же таких изменений не будет, то в части использования кэша, браузер будет работать обычным образом, т.е использоваться ранее сохраненные ресурсы.

Таким образом мы подготовили сайт для размещения результатов Яндекс.Поиск и оформления соответствующей страницы по дизайн сайта. Что мы и сделаем в следующей статье.

Исходные файлы сайта

Исходные файлы сайта с обновлениями, которые были сделаны в данной статье, можно скачать из прилагаемых дополнительных материалов:

Файлы каталога www
Таблицы базы данных MySQL

Для скачивания исходных файлов необходимо авторизоваться под своим аккаунтом через соответствующую форму.

От автора: в первую очередь производительность браузера повышается за счет кэширования CSS. Проверьте, что ваш сервер отправляет заголовки, которые говорят браузеру хранить CSS файлы определенное время. Это наилучший подход, которым пользуются на большинстве, если не на всех сайтах.

Кэширование очень тесно связано с браузером, и в итоге легче его отключить. Задайте в настройках браузера хранить кэш CSS один год (что не редкость). И вдруг вам понадобилось изменить стили. В таком случае вам нужно подумать, как очистить кэш и заставить браузер перезагрузить CSS. Ниже представлены несколько вариантов по решению этой задачи.

Просто посмотрим на то, как выглядят заголовки для кэширования CSS файлов:

Нам нужны Cache-Control и Expires. Я не эксперт в области конфигурации серверов, обычно я смотрю в H5BP конфиги. Но в нашем случае есть классический способ через Apache/HTAccess:

Практический курс по верстке адаптивного сайта с нуля!

Изучите курс и узнайте, как верстать современные сайты на HTML5 и CSS3

ExpiresByType application / javascript "access plus 1 year"

Запросы

Сейчас браузеры видят URL с какими-либо запросами, как отдельные файлы и просто обновляют их на свежие копии. Большинство CDN поддерживают такую функцию и рекомендуют ее.

Что-то не так? Измените на это:

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

< link rel = "stylesheet" href = "global.css?v= <?php echo $cssVersion ; ?> " >

Скорее всего, вы даже могли бы использовать семантическое версионирование, а также можно задать константы.

Изменение имени файла

Запросы не всегда срабатывают. Некоторые браузеры не различают разные строки запросов, как разные файлы. А некоторое ПО (Squid) вообще не кэширует файлы по строковым запросам. Steve Souders в своей статье рассказывает, почему не стоит использовать строковые запросы. Похожая техника применяется с изменением имени файла. Как в HTML ниже:

Необходимо программно изменить имя файла, а не просто вбить готовое. Таким образом, файл на самом деле не существует вообще, вам придется написать пару строк кода, чтобы попасть к нужному файлу. Совсем недавно Jeremy Keith открыл эту технику.

Сервер будет игнорировать цифры в именах файлов CSS и JavaScript, однако браузер все же будет считать названия файлами и будет пытаться обновить код. Jeremy Keith пользуется Twig и применяет следующий шаблон:

Уверен, что вы можете представить похожий код на любом backend языке (типа ASP). Можно потренироваться с написанием данного скрипта для обновления переменной.

Отключение кэширование основано на обновлении даты

Во время поиска в интернете по поводу отключения кэширования вы наткнетесь на кучу советов, вам будут рекомендовать использовать сервер для проверки последнего обновления кэшированного файла и создать «номер» отключения кэша (номер означает что угодно, что вы можете изменить для обновления кэша).

return $ path [ 'dirname' ] . '/' . str_replace ( '.' , $ ver , $ path [ 'basename' ] ) ; < link href = " <? phpautoversion ( '/path/to/theme.css' ) ; ?> " rel = "stylesheet" >

Вообще, я не слишком в этом хорош. Мне кажется, что каждый раз спрашивать сервер при просмотре страницы будет крайне опасно. Раньше я вообще искал фото на сервере по его размерам! Будьте осторожны, в общем.

ETag’и

Возможно ETag’и покажутся хорошей идеей, так как большинство из них это информация о том, имеются ли уже у браузера копии файлов. Но большинство советчиков в интернете говорят: «отключайте ETag заголовки». Yahoo говорит:

«Вся проблема с ETag’ами в том, что они создаются с помощью атрибутов, которые делают их уникальными для каждого сервера. ETag’и не совпадут, если браузер получил компонент от одного сервера, и тот пытается проверить компонент на другом сервере. Общая проблема сайтов, построенных на кластерных серверах.»

Другая проблема в том, что они просто не эффективны при кэшировании. Для проверки ETag’ов все еще нужно делать сетевые запросы. Это не просто загрузка файлов, которая уменьшает производительность, а также различные задержки на стороне сервера при обработке запросов.

Практический курс по верстке адаптивного сайта с нуля!

Изучите курс и узнайте, как верстать современные сайты на HTML5 и CSS3

И снова я не эксперт в этой тематике, но рекомендуется отключить их в Apache:

Читайте также: