Кеширование изображений с других сайтов


Содержание

Кэш браузера

Что такое кэш браузера?

  • htaccess кэширование сохраняет содержимое веб-страницы на локальном компьютере, когда пользователь посещает ее;
  • Использование кэша браузера – веб-мастер дает указания браузерам, как следует рассматривать ресурсы.

Когда браузер отображает веб-страницу, он должен загрузить логотип, CSS файл и другие ресурсы:

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

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

Как включить кэширование в браузере

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

Изменение заголовков запроса

Для большинства людей единственный способ кэширования сайта htaccess заключается в том, чтобы добавить код в файл .htaccess на веб-сервере.

Файл .htaccess контролирует многие важные настройки для вашего сайта.

Кэширование браузера через файл .htaccess

Приведенный ниже код указывает браузеру, что именно кэшировать и как долго это « запоминать «. Его следует добавить в начало файла .htaccess :

Сохраните файл .htaccess , а затем обновите веб-страницу.

Как установить время кэширования для различных типов файлов

В приведенном выше коде заданы промежутки времени. Например, 1 year ( 1 год ) или 1 month ( 1 месяц ). Они связаны с типами файлов. Приведенный выше код устанавливает, что .jpg файлы ( изображения ) следует кэшировать в течение года.

Если бы вы хотели изменить это, чтобы и JPG изображения кэшировались в течение месяца, то вы бы просто заменили « 1 год » на « 1 месяц «. Указанные выше значения кэширования через htaccess оптимальны для большинства веб-страниц.

Метод альтернативного кэширования для .htaccess

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

Возможно, что метод Expires не сработает на вашем сервере, в этом случае вы возможно захотите попробовать использовать Cache-Control .

Cache-Control

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

Пример использования в файле .htaccess :

Приведенный выше код устанавливает заголовок Cache-Control в зависимости от типа файла.

Как работает Cache-Control

Рассмотрим упомянутую выше строку кода кэширования в браузере htaccess :

Данная строка — просто примечание. Файл .htaccess игнорирует строки, начинающиеся с символа # . Это примечание рекомендуется, так как у вас может быть несколько различных наборов данных в качестве решения для кэширования файлов:

Упомянутая выше строка говорит, что, « если файл будет одним из этих типов, то мы сделаем что-то с ним… »

Самое важное в этой строке то, что в ней перечислены различные типы файлов ( CSS , JS , JPEG , PNG и т.д. ) и что инструкции кэширования следует применять к этим типам файлов. Например, если вы не хотите, чтобы JPG файлы кэшировались в течение указанного периода времени, можете удалить « JPG «. Если вы хотите добавить HTML , то нужно в этой строке указать « HTML «:

В упомянутой выше строке установлены фактические заголовки и значения:

  • Часть « Header set Cache-Control » — устанавливает заголовок;
  • Переменная « max-age=2592000 » – указывает, сколько времени займет процесс кэширования ( в секундах ). В этом случае мы осуществляем кэширование в течение одного месяца ( 2592000 ) секунд;
  • Часть « public » сообщает о том, что это общедоступно.

Эта строка кэширования через htaccess закрывает оператор и заканчивает блок кода.

Общая проблема кэширования

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

Цифровой отпечаток URL

Получение нового (некэшируемого) файлового ресурса возможно при наличии уникального имени. Например, если файл CSS назван «main.css», то вместо этого мы могли бы назвать его «main_1.css». В следующий раз, когда мы поменяем его имя, мы можем назвать файл «main_2.css». Это полезно для файлов, которые периодически изменяются.

Методы кэширования

При кэшировании файлов htaccess необходимо указать один заголовок из пары Expires или Cache-Control max-age, а также один из заголовков Last-Modified или ETag для всех кэшируемых ресурсов. Использовать и Expires, и Cache-Control: max-age излишне, как и Last-Modified и ETag одновременно.

Данная публикация представляет собой перевод статьи « Leverage browser caching » , подготовленной дружной командой проекта Интернет-технологии.ру

Кэширование изображений WordPress в один клик

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

Масштабное ускорение

В предыдущей статье по ускорению веб-страниц при помощи PageSpeed Insights от Google, мне удалось значительно превзойти предыдущие показатели. Параметры для компьютеров поднялись с 62 до 73 баллов, а для мобильных устройств с 74 до 78 баллов. Эти параметры выдает PageSpeed на основе настроек моего сервера. Вы можете заметить, что до сих пор не включено кэширование браузера. Если его задействовать, то я сразу войду в зеленую зону с параметрами за 85 пунктов и выше.

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

Локальное ускорение

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

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

Кэширование изображений с «Photon»

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

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

Как работает система

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

Сравниваем изображения до и после

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

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

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

Преимущество

Вся прелесть в том, что вам не нужно ничего настраивать, указывать какие-то параметры и делать многое другое. Просто выбрали модуль «Photon» и активировали, дальше предоставьте системе сделать все за вас. Можете забыть о медленной загрузки и не оптимизированных картинках на своем блоге.

На этом у меня все, надеюсь вы уловили суть, и статья была для вас полезной. Делитесь своим мнением в комментариях, осуществляете ли вы на своих сайтах кэширование изображений. Буду признателен за рекомендацию данной статьи в социальных сетях. Желаю вам, моментальной загрузки всех страниц ваших сайтов, пока!

Немного об Авторе Денис Чернятинский

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

Как уменьшить вес сайта и ускорить загрузку страниц с помощью gzip, brotli, минификации и других способов

В статье:

Зачем уменьшать размер HTML-страницы

С каждым годом вес HTML-страниц в среднем увеличивается. По данным MachMetrics, средний размер веб-страницы в 2020 году — 2МБ, это в три раза больше, чем три года назад. Это происходит, потому что на сайты добавляют более качественные и тяжелые изображения и видео, CSS или JS-файлы.

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

Пользователи не будут ждать долгой загрузки, максимум, который они ждут — 2-3 секунды на десктопе или 3-4 на мобильном устройстве. Если сайт так и не загрузился, пользователь закроет страницу — для поисковиков это будет значить, что сайт не удовлетворяет задачи пользователей. Поисковики стимулируют веб-мастеров ускорять и облегчать сайты. Обновление Google Speed Update занижает позиции очень медленных сайтов, к тому же Google переводит сайты в Mobile-first index — это значит, что mobile-friendly сайты получат преимущество, десктопная выдача будет строиться на основе мобильной, где особенно важен вес страницы.

Иногда незначительные задержки скорости не критичны, если посетители целенаправленно хотят получить услуги, товары или информацию с конкретного сайта. К примеру, по данным инструмента Google PageSpeed Insights, у сайта amazon.com довольно низкая скорость загрузки с мобильных устройств, но Amazon востребован: пользователи готовы ждать, чтобы делать выгодные заказы.

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

Измерить скорость загрузки своего сайта и сравнить с конкурентными можно с помощью инструментов Google PageSpeed Insights или Проверка скорости сайта от PR-CY.

Фрагмент результатов проверки

Если хотите ускорить загрузку страницы, то рекомендуем уменьшить ее размер.

Как уменьшить размер HTML

Для уменьшения размера HTML-страницы нужно сжать код и облегчить элементы:

  1. Избавиться от переадресации с целевой страницы. Google пишет о том, что перенаправления типа example.com → www.example.com → m.example.com или example.com → m.example.com/home для мобильных пользователей замедляют загрузку страницы.
  2. Оформить HTML-элементы с помощью CSS, это ускорит загрузку и упростит работу с повторяющимися на страницах элементами.
  3. Сжать все текстовые файлы HTML, XML, CSS, Javascript, сжать HTML-код страниц.
  4. Использовать минификацию — удалить ненужные данные, которые увеличивают объем кода.
  5. Сжать все графические файлы, оптимизировать изображения — фотографии и графику.
  6. Использовать кэш браузера — кэшировать данные в браузере пользователя.
  7. Оптимизировать нефункциональные анимационные детали, отказаться от flash — такие элементы вредят безопасности сайта и могут не поддерживаться у пользователей.
  8. Оптимизировать количество рекламных блоков на странице.

Использовать сжатие gzip или brotli

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

Самый популярный алгоритм сейчас — gzip, он появился одним из первых. Gzip поддерживают все серверы и распространенные браузеры. После работы над gzip инженеры сосредоточились на алгоритме, который сжимал бы еще сильнее, и разработали brotli — у него больше степеней сжатия по сравнению с gzip, но на высоких уровнях сжатия его скорость чуть меньше.

Сжатие данных алгоритмами состоит из этапов:

  1. Клиент совершает запрос и оповещает сервер, какие данные может принять.
  2. Сервер обрабатывает запрос и определяет, какую версию отправить.
  3. Сервер отправляет файл клиенту.
  4. Клиент распаковывает и считывает информацию.

На втором этапе браузер сообщает серверу, какие методы сжатия поддерживает — посылает заголовки Accept-Encoding с кодом, где указаны алгоритмы сжатия, например, «accept-encoding: gzip, deflate, br». Сервер выбирает форматы из доступных: если клиент поддерживает brotli, то сервер ищет суффикс «.br» в заголовке и отправляет клиенту нужный файл. Если его нет, будет использовать другой алгоритм. Если клиент не поддерживает сжатие вообще, сервер отправит несжатую версию.

Какой алгоритм сжатия выбрать: gzip или brotli?

Многие веб-мастера используют оба способа, поскольку brotli позволяет сжимать сильнее, но gzip поддерживают больше браузеров, поэтому он будет использоваться чаще.

Как использовать сжатие gzip

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

Степень сжатия можно настраивать, gzip поддерживает уровень сжатия от 1 до 9. Обычно рекомендуют степень 4-7 в зависимости от ресурсов процессора, оптимальное значение 5. Подберите подходящую степень сжатия под свои ресурсы, чтобы процессор справлялся, иначе сжимать информацию будет бесполезно, если нагрузка на процессор сильно вырастет. Экономить ресурсы поможет использование заранее сжатых файлов, они имеют формат gzip с дополнительным расширением .gz. На такие файлы можно применять максимальную степень сжатия, дальше сервер будет использовать ее вместо обычной.

Сжатие gzip для Nginx

В новых версиях Nginx gzip сжатие включено по умолчанию, но если такого нет, его можно настроить. Чтобы запустить сжатие gzip для сервера Nginx, нужно включить сжатие в модуле /etc/nginx/nginx.conf:

Директива «gzip_disable «msie6»» отключает сжатие для эксплорера 5.5 и 6, «gzip_proxied any» позволяет сжимать данные для proxy-серверов.

Уровень сжатия указывают в директиве «gzip_comp_level 6».

Директива «gzip_types text/css text/javascript application/javascript» указывает типы файлов для сжатия на сервере. Перечислите те, которые вам нужны. Cжатие text/html подразумевается и не может быть отключено, если вы не установили gzip off, а text/css и application/x-javascript включает сжатие gzip для файлов CSS и javascript соответственно.


Сжатие gzip можно включать и выключать для каждого «сервера» Nginx — более мелкой структуры, и для конкретного location — еще меньшей, зачастую располагающейся внутри него.

Gzip-сжатие файлов SVG для Nginx

Сжатие gzip будет работать для SVG, если формат векторной графики SVG есть в файле, который обычно располагается по пути «/etc/nginx/mime.types». Добавьте строку изображения «image/svg+xml svg svgz»

В файле конфигурации Nginx найдите «gzip types» и добавьте «image/svg+xml» к концу строки. Получившаяся строка может выглядеть так:

Сжатие gzip для Apache

Сервер Apache для работы со сжатыми ресурсами использует модуль mod_deflate или mod_gzip.

Если вы используете mod_gzip, в в файл .htaccess добавьте строки:

Если используете mod_deflate, для отгрузки сжатых файлов добавьте строки в файл .htaccess:

Есть еще такой вариант перечисления типов файлов для сжатия в одной строке:

В строке DeflateCompressionLevel 7 указывают степень сжатия. Сжатие будет работать после сохранения.

Gzip-сжатие файлов SVG для Apache

Векторную графику формата SVG можно сжать с помощью gzip. В файле .htaccess. должна быть строка «# Compress HTML, CSS, JavaScript, Text, XML and fonts», добавьте в .htaccess строчку кода:

После вставки и сохранения функция должна работать. Следите, чтобы код в файле не повторялся.

Как использовать сжатие brotli

Brotli поддерживают браузеры Chrome, Firefox и Edge 15 для SSL-соединений. В заголовках должен быть «Accept-Encoding: br». В brotli есть собственный словарь из более сотни тысяч фраз, который используется для сжатия данных. Он же встроен в браузеры, которые поддерживают алгоритм, поэтому словарь не передается в архиве, и архив весит меньше.

Алгоритм сжатия brotli сжимает файлы сильнее, чем gzip. Максимальная степень сжатия у gzip — 9, а у brotli 11, степень 11 brotli дает файл на 25% меньше, чем сжатый 9 степенью gzip.

Некоторые веб-мастера считают, что brotli нет смысла использовать для динамических страниц, поскольку он медленнее gzip. Такое ощущение складывается, если сравнивать параметры по умолчанию: у команды brotli стоит максимальный 11 уровень сжатия, для него нужно больше времени, поэтому процесс сжатия получается медленнее.

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

Сжатие brotli для Nginx

Сервер Nginx использует brotli при включенном модуле «brotli_static» в конфигурации «brotli_static on». Тогда сервер получит от браузера заголовок, проверит, есть ли в нем файл с расширением «.br» и отдаст нужный файл как архив, сжатый в brotli.

Brotli-архивы нужно установить из репозитория или собрать утилиты:

Для сжатия «на лету» можно установить дополнительный модуль nginx brotli. Модуль Nginx для сжатия brotli «на лету» на Github.

Сжатие brotli для Apache

Сжатие brotli поддерживает Apache версии 2.4.26 и выше.

Как проверить сжатие данных

Алгоритм сжатия данных будет работать сразу после установки кодов. Проверить корректность работы можно несколькими способами.

Для проверки работы gzip есть Check GZIP compressed.

Фрагмент результатов проверки тестом

Google PageSpeed Insights оценит скорость загрузки и покажет список файлов, для которых не работает сжатие.

Фрагмент результатов проверки инструментом

Инструмент «Проверка скорости сайта» от PR-CY оценит скорость и покажет страницы, на которых не работает сжатие.

Фрагмент результатов проверки инструментом

Использовать минификацию HTML, CSS и JS

Еще один способ уменьшить код — сократить его. В коде часто остаются комментарии, ненужные фрагменты, разрывы строк, разделители блоков и лишние пробелы, библиотеки JavaScript, которые не используют. Ненужные символы можно удалить, для этого проводят минификацию CSS, JS, HTML-файлов.

Минификация помогает уменьшить размер фрагментов кода JS, она не влияет на сам файл, но оптимизирует его и уменьшает размер, за счет чего повышается скорость загрузки. Файлы, прошедшие минификацию, получают расширение «.min». После минификации в CSS, HTML, JS-файле не будет разделителей, переносов, лишних пробелов, поэтому его будет сложнее читать.

Илон Маск рекомендует:  Что такое код getdefaultplatte

Бесплатные инструменты для минификации CSS, JS, HTML-файлов

Собрали несколько бесплатных онлайн-инструментов для сокращения кода.

  • minifycode.com
    Простой бесплатный онлайн- инструмент для минификации кода HTML, CSS и JavaScript файлов в отдельных полях.
  • willpeavy.com/minifier
    Другой простой инструмент для минификации HTML, CSS или JS в один клик без дополнительных настроек.
  • mailfit.com/compressor
    Инструмент в два клика сжимает код JS, HTML и CSS, нужно только вставить код в поле и выбрать формат.
  • htmlcompressor.com
    Инструмент позволяет выбрать уровень минификации HTML и встроенного в него кода CSS и JS, отметить расширенные настройки.
  • jscompress.com
    Инструмент для сокращения файлов JS. Можно загружать файл и минифицировать несколько одновременно.
  • askapache.com/online-tools/compress-css
    Инструмент для быстрой минификации CSS без настроек — загружаете код и получаете результат.
  • csscompressor.com
    Инструмент дает установить одну из четырех степеней минификации CSS и размер итогового файла.

Использовать кэш браузера для ускорения

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

Google рекомендует настроить сервер так, чтобы он возвращал ответ с HTTP-заголовком Cache-Control, например:

Директива «max-age» указывает, как долго браузер должен кэшировать ресурс в секундах. Значение 31536000 соответствует году: 60 секунд * 60 минут * 24 часа * 365 дней = 31536000 секунд.

Google советует применять «no-cache» для объектов, которые могут обновляться: тогда браузер по-прежнему будет кэшировать ресурс со значением «no-cache», но сначала проверит актуальность на сервере.

Кэширование для Nginx

Для сервера Nginx подходит модуль expires в файле конфигурации. Нужно перечислить форматы файлов для кэширования и указать время хранения кэша:

Время можно указать в любом формате: секунды — s, часы — h, дни — d и месяцы — m, обозначение «max» указывает на кэширование навсегда.

Вместо времени хранения файла можно указать дату следующего обновления файла в кэше:

Строка log_not_found off нужна для снижения нагрузки на сервер, она отключает ведение лога сообщений с ошибкой 404 для перечисленных файлов.

Кэширование для Apache

Метод Cache-Control

Метод позволяет указать для кэширования файлы конкретных форматов. В файле .htaccess в конструкции FilesMatch нужно указать расширения файлов для кэширования и время сохранения файла в кэше в секундах:

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

Кэширование по времени

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

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

После сохранения нужно обновить страницу.

Проверить кэширование в Google Chrome можно с помощью веб-инспектора Chrome DevTools. Столбец Size в Chrome DevTools поможет убедиться, что ресурс в кэше:

Столбец Size в Chrome DevTool. Источник — Google

Вкладка Headers покажет, как установлен Cache-Control:

Проверка заголовка Cache-Control. Источник — Google

Сжать фотографии, иллюстрации и другую графику

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

Как оптимизировать картинки для сайта:

  1. Подберите разрешение.
    Незачем загружать изображение в большом разрешении, если оно будет отображаться в маленьком без увеличения по клику.
  2. Подберите формат.
    JPEG подходит для фотографий, PNG для дизайнерской графики, SVG для вектора. Google также индексирует формат WebP, который весит меньше, но не все браузеры его поддерживают. Яндекс не индексирует SVG и изображения в скриптах.
  3. Уменьшайте количество цветов.
    Изображения, где нет сложных градиентов, требуют меньшего количества цветов. Можно оптимизировать картинку без потери качества, выбрав палитру меньше, тогда изображение будет хранить меньшее количество битов на пиксель. Слева направо: 32 бита (16M цветов), 7 бит (128 цветов), 5 бит (32 цвета)
  • Пропишите параметры в CSS.
    Укажите размеры в коде или в редакторе изображений CMS. Для разных экранов и дисплеев с матрицей Retina нужны дополнительные варианты изображения разных размеров, чтобы браузер загружал нужное для устройства.
  • Используйте шрифты.
    Если вы еще используете графику вместо шрифтов для текста, замените надписи на шрифты, это удобнее и меньше весит. Такой текст можно скопировать, поменять, масштабировать в любой момент.
  • Удалите лишние изображения.
    Неинформативные картинки, иллюстрации ради разбивки текста и непонятные схемы лучше заменить на качественные изображения, которые помогут понять тему материала, или вообще удалить, чтобы они не прибавляли вес странице.
  • Минифицируйте.
    Удаляйте XML-разметку с лишними метаданными, она появляется при работе с картинками в некоторых графических приложениях. EXIF — информацию о геоданных, дате съемки, фотокамере тоже можно удалить.
  • Используйте алгоритмы сжатия.
    Настройте на сервере gzip-сжатие для SVG-графики.
  • Инструменты и сервисы для оптимизации изображений на сайте:

    • CompressJPEG
      Сервис для сжатия JPEG и PNG без потерь качества.
    • PunyPNG
      Инструмент сжимает PNG, JPEG и GIF.
    • TinyPNG
      Инструмент для оптимизации изображений в PNG и JPEG.
    • Jpegtran
      Инструмент для оптимизации JPEG-изображений.
    • Optipng
      Инструмент для оптимизации PNG без потерь.
    • Pngquant
      Инструмент сжимает PNG-изображения.

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

    Оптимизация изображений на крупных проектах

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

    На сайте, как правило, мы используем несколько размеров картинок: определенный размер в каталог, определенный размер на страницу товара, определенный размер при увеличенном просмотре картинки товара и так далее. И какая бы картинка не попадала на сайт, пусть даже 10Мб, мы всегда показываем ее на сайте в нужном размере, чтобы сделать страницу легкой и быстрой для пользователя.

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

    Но при росте одного из проектов мы столкнулись со следующими проблемами:

    • При резком росте количества картинок уходит слишком много времени на их ресайз;
    • При большой посещаемости сайта PHP даже из кэша довольно долго отдает картинки;
    • В случае, если миниатюры создаются при загрузке изображений на сервер и сразу кладутся в кэш, то при появлении новых размеров картинок приходится заново ресайзить все изображения, что может затянуться на сутки, а то и более. Бизнес столько ждать не может;
    • Мы храним все размеры картинок для всех товаров, даже для тех, на которые, возможно, никто никогда и не зайдет или товар уже давно не в наличии. В итоге, неиспользуемые картинки продолжают храниться на диске, раздувая его объемы. Да, можно периодически удалять давно неиспользуемые картинки, но при больших объемах данных эта процедура может затянуться.

    Ниже рассказываем о том, как мы решили эти проблемы. Заодно попутно удовлетворили google page speed test, который постоянно просит уменьшить размер картинок.

    Выбор архитектуры

    Сперва выбираем архитектуру, с помощью будем ресайзить и отдавать картинки.

    Мы сравнили несколько способов и провели нагрузочное тестирование. С помощью утилиты wrk организовали нагрузку на сервер, который отдаёт картинки, в течении 10 секунд с 15 параллельными подключениями.

    1. Самый популярный способ. Ресайзим картинки на PHP, PHP проверяет есть ли картинки в кэше и, если есть, отдает, если нет — ресайзит на лету.

    В итоге 106 ответов в секунду, каждый из которых в среднем отдавался через 140 мс.

    2. Пробуем ресайзить картинки в реальном времени с помощью одной из библиотек NodeJS.

    Количество запросов и время отклика улучшилось почти в 3 раза: 283 ответа в секунду и каждый ответ в среднем 52мс.

    3. К ресайзу картинок на NodeJS добавляем кэширование силами nginx. Т.е. nginx кладет к себе в кэш картинку и при последующем обращении отдает ее из кэша, не дергая NodeJS

    Приведем результаты к сравнительной таблице:

    Оптимальный вариант очевиден, выбираем последний способ.
    php + cache на php nodejs в реальном времени nodejs + кэш на nginx
    Среднее время ответа 140мс 52мс 7мс
    Запросов в секунду 107 283 117000
    Передано данных в секунду 22Кб 4.4Мб 1.6Гб


    Описание технической стороны реализации

    Nginx обрабатывает все запросы к картинкам. В случае, если на сервере уже есть миниатюра — отдаем из кэша nginx, если нет — запрос проксируется на nodejs. В настройках nginx это выглядит следующим образом:

    Т.е. все запросы к картинкам по адресу /images/products/71481/211/0.jpg будут обрабатываться нашим механизмом. Где:

    • 71481 — Номер товара, чтобы nodejs понимал из какой директории брать оригинальное изображение.
    • — Название оригинальной картинки, которую нам необходимо отресайзить, которая находится в директории товара 71481.
    • 211 — Название конфигурации параметров для ресайза картинок, которые мы храним в nodejs, к примеру в настройке 211 мы храним, что должна быть картинка 211 на 170 с качеством в 95%. Так, при появлении новых размеров картинок на сайте, мы просто добавляем новые, например small, large, 611×211, 611, как вам угодно, и всего лишь меняем путь к картинке. Это так же нас защищает, чтобы злоумышленники не создали кучу миниатюр, которые сайт на самом деле не использует, тем самым загрузив сервер.

    В настройках nginx установлен максимальный размер кэша в 50Гб и срок хранения 30 дней. Часть, которая отвечает за ресайз картинок, реализованная на NodeJS мы выложили на github: https://github.com/websecret/imgproxy.

    Отметим, что сервер всегда отдает 200 ответ и указывает время истечения кэша, expires. Таким образом, при загрузке страницы, браузер клиента вообще не обращается к серверу для загрузки картинки, а сразу берет ее из кэша браузера. Ранее, в случае 304 ответа — этот ответа отдавался сервером, тем самым немного увеличивая время загрузки.

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

    Мы будем использоваться https://github.com/lovell/sharp, так как она показала лучшие результаты тестов по скорости обработки картинок и конечному соотношению.

    Для сравнения приводим пример двух картинок, которые ресайзились раньше с помощью Imagick, а теперь с помощью https://github.com/lovell/sharp.

    Imagick Sharp
    Размер 20Кб Размер 8Кб
    Размер 20Кб Размер 8Кб

    Да, при использовании библиотеки Sharp мы уменьшили качество картинок со 100% до 95%, но для картинок такого размера разница не видна, а по размеру картинка разница очень существенная. В итоге размеры картинок уменьшились более, чем в два раза.

    Для оценки результатов, как наши преобразования повлияли для посетителя сайта, сравним в консоли браузера (сперва старый способ, затем — наш новый новый механизм):

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

    Таким образом мы решили следующие проблемы и добились следующих результатов:

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

    Надеюсь наш материал кому-то поможет решить схожие проблемы. Будем рады вопросам и предложениям.

    Google pagespeed Insights, как включить кэш браузера внешних файлов

    Всем привет! Сегодня я хочу рассказать, как сделать кэш внешних элементов в Google PageSpeed Insights, для увеличения скорости вашего сайта. Суть будет заключаться в том, чтоб скачать js и другие подгружаемые файлы с внешних ресурсов к себе на сайт.

    Как включить кэширование файлов в браузере

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

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

    С тем, что такое кэш мы разобрались. Теперь, давайте проверим наш сайт в сервисе PageSpeed и убедимся, что google рекомендует нам использовать кэш браузера. Вот выдержка из сообщения google PageSpeed Insights.

    Используйте кэш браузера

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

    Вставив этот код в файл htacces, вы можете перепроверить свой сайт в сервисе google PageSpeed
    Insights. Если в разделе «используйте кэш браузера» всё отлично, значит, у вас там будут
    только ссылки на внешние ресурсы, такие как аналитика, Яндекс метрика, социальные
    кнопки и прочее.
    Лично, я параллельно с этим кодом использую возможности своего хостинга для кэширования файлов на стороне пользователя. Это выглядит следующим образом.

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

    Как включить кэш внешних файлов в Google PageSpeed Insights

    Если вы выполнили рекомендации для кэширования файлов у себя на блоге. Вы должны, в инструменте Google PageSpeed Insights, увидеть только ссылки на внешние ресурсы. У вас должно быть, что-то схожее. Как видно из скриншота, Google PageSpeed Insights ругается на внешние ресурсы, такие как Яндекс метрика, google аналитика и другие. Сейчас я вам расскажу, как исправить эту ошибку и сделать ссылки на внешние ресурсы внутренними и кэшируемыми на стороне вашего сервера.

    Используем кэш браузера для внешних ресурсов

    Так, как файлы внешних ресурсов не принадлежат нашему сайту их необходимо в первую очередь скачать. Для того чтоб скачать внешний файлы со сторонних ресурсов, мы должны создать файл kesh_js.php со следующим кодом. Советую, пользоваться блокнотом Notepad++ для быстрого и корректного добавления кода в файл.

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

    downloadJs ( ‘ сюда вставьте ссылку из PageSpeed / metrika.js ‘ , realpath ( «./papka_js« ) . ‘/ metrika.js — сюда вставьте конечный файл’ ) ;

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

    После, того, как добавили код в файл kesh_js.php, вы можете назвать его иначе. Его необходимо залить в корень нашего сайта. Также в корне сайта, необходимо создать папку papka_js, либо под другим именем с правами доступа 777/755. Для того чтоб выставить права доступа папке, советую использовать Fillizille.

    Для этого просто открываем программу fillizilla. Далее, выбираем папку и выставляем права доступа, обязательно 777, после чего меняем обратно на 755. Это также можно сделать в панели управления вашего хостинга, если нет желания использовать эту программу. Я покажу, скриншот выставления прав доступа в программе Fillizilla. После чего открываем раздел «права доступа к файлу» и вводим наше значение 777/755.

    Дальше, нам необходимо запустить наш файл для скачивания внешних скриптов и изображений в папку papka_js. Для этого, просто введите в адресную строчку https://адрес вашего сайта/kesh_js.php. Примерно, через 5-10 минут, можете проверить содержимое папки, если оно пустое, значит, вы сделали что-то не так. Ищите ошибку. В папке papka_js, должны быть скрипты, необходимые для кэширования на стороне браузера, через наш сайт. Вот, как это выглядит у меня.

    Как включить планировщик заданий для сайта (cron)

    Следующим шагом, нам нужно включить планировщик заданий для нашего сайта, чтоб наш скрипт https://адрес вашего сайта/kesh_js.php запускался, ежедневно. Благодаря, этому на нашем сайте, будет всегда актуальная версия файлов с внешних ресурсов. Даже, если разработчики внесут изменения в свой код, мы всегда будем иметь рабочую версию на сайте, благодаря планировщику заданий.

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

    запуск задания через GET. При необходимости запуска cron-задания с учётом контекста движка:

    где site.ru — имя вашего домена, а script.php — имя файла с заданием;

    запуск задания через WGET. Альтернативный вариант запуска cron-задания с учётом контекста движка:

    где site.ru — имя вашего домена, а script.php –— имя файла с заданием;

    В нашем случае, мы должны прописать:

    Либо выбрать альтернативный вариант, я лично остановился на первом.

    С тем, что прописывать мы разобрались, теперь открываем наш хостинг и переходим в панель управления им. Я использую, панель управления ISPmanager, если у вас другая ищите вкладку планировщик задания, либо cron.

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

    Далее, нам нужно выбрать вкладку «планировщик», либо cron.

    Теперь, открываем вкладку «создать».

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

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

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

    P. S. Не забываем сменить URL, возможно синтаксис команды у вас будет другой. Проверьте примеры cron команд в справке вашего хостинга или утоните в тех.поддержке.

    Теперь, нам остается изменить вызов наших js и других внешних файлов на внутренние с нашего сайта.

    Меняем путь внешнего ресурса на свой, для увеличения скорости pagespeed Insights

    После, всех действий сделанных выше, нам остаётся найти вызов внешних файлов и заменить их ссылки на свои внутренние.

    Для этого мы опять открываем инструмент PageSpeed и копируем внешнюю ссылку, типа https://mc.yandex.ru/metrika/watch.js, ищем, где она у нас выводится, и заменяем его на путь внутри сайта, например https:// ваш сайт.ru /js/watch.js.

    После чего чистим кэш браузера. Для Google Chrome, используем сочетание клавиш ctrl+shift+delete и проверяем работу сайта. Также, рекомендую ещё раз прогнать ваш сайт через инструмент PageSpeed Insights.

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

    Всё о кешировании сайта: nginx, memcached, expires, etag, плагины

    Что такое кеширование

    Кеширование (caching) — это технология или процесс создания копии данных на быстродоступных носителях информации (кеш, cash). Проще говоря и применяя к реалиям сайтостроения, это может быть создание статической html-копии страницы или её части, которая генерируется с помощью PHP-скриптов (или иных других, как-то Perl, ASP.net), смотря на каком языке написан CMS сайта) и сохраняется на диске, в оперативной памяти или даже частично в браузере (рассмотрим подробнее ниже). Когда произойдёт запрос страницы от клиента (браузера), вместо того, чтобы заново собирать её скриптами, браузер получит её готовую копию, что намного экономнее по затратам ресурсов хостинга, и быстрее, так как передать готовую страницу занимает меньше времени (порой значительно меньше), чем её создание заново.

    Зачем использовать кеширование на сайте

    • Для снижения нагрузки на хостинг
    • Для быстрой отдачи содержимого сайта браузеру

    Оба аргумента, думаю, в комментариях не нуждаются.

    Недостатки и отрицательный эффект от кеширования сайта

    Как ни странно, у кеширования сайта есть и свои минусы. В первую очередь это касается сайтов, содержание которых динамично изменяется при взаимодействии с ним. Зачастую, это сайты, которые выдают содержимое или его часть с помощью AJAX. В общем-то, кеширование AJAX тоже возможно и даже нужно, но это тема для отдельного разговора и не касается традиционно используемых технологий, о которых пойдёт речь далее.
    Также, проблемы могут возникнуть у зарегистрированных пользователей, для которых постоянный кеш может стать проблемой при взаимодействии с элементами сайта. Тут, как правило, кеш отключается, либо используется объектное кеширование отдельных элементов сайта: виджетов, меню и тому подобных.

    Как настроить кеширование у себя на сайте

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

    Кеширование на стороне сервера

    Кеширование с помощью NGINX

    На хостинге используется NGINX. Как правило, в качестве вебсервера работает связка NGINX + Apache. На мой взгляд, это наиболее удачный вариант для большинства сайтов и веб-проектов. NGINX используется как принимающий основную нагрузку кеширующий сервер, работающий во фротнэнде, Apache же работает с динамикой, собирая из скриптов html-страницу выдачи. Задачей NGINX является проверить, находится ли в кеше копия требуемой страницы (при работе в связке с Varnish или Memcached) либо её статичных элементов (стилей, скриптов, изображений, аудио- и видеофайлов и других медиа), их актуальность, и, если всё в порядке, отдать результат браузеру.

    Илон Маск рекомендует:  Что такое код clock

    Если вы не используете NGINX, категорически рекомендую использовать его, он серьёзно повышает производительность сервера.

    Кеширование с помощью htaccess (Apache)

    Если у вас есть доступ только к .htaccess , и рабочий сервер только Apache, то вы можете использовать такие приёмы, как сжатие gzip и выставление HTTP заголовков Expires , чтобы использовать браузерный кеш.

    Включаем сжатие gzip для соответствующих MIME-типов файлов

    Включаем заголовки Expires для статичных файлов сроком на 1 год (365 дней)

    Кеширование с помощью Memcached

    Суть работы Memcached — сохранять данные в оперативную память и отдавать браузеру оттуда уже скомпилированную готовую страницу или её фрагменты. В принципе, туда можно сохранять всё, что угодно: результат «тяжёлых» запросов к базе данных, временно необходимые объекты и тому подобное. Так выходит намного быстрее, нежели чем читать даже статические html-файлы c hdd-диска, не говоря уже про постоянную генерацию страниц при каждом запросе к ним. Как установить и настроить Memcached

    Кеширование с помощью акселератора php

    Если движок сайта написан на PHP, то при каждой загрузке любой страницы сайта происходит исполнение скриптов php: интерпретатор кода читает скрипты, написанные программистом, генерирует из них байткод, понятный машине, исполняет его и выдаёт результат. Акселератор PHP позволяет исключить постоянную генерацию байткода, кешируя скомпилированный код в памяти или на диске, тем самым увеличивая производительность и уменьшая время, затрачиваемое на исполнение PHP. Из поддерживаемых на сегодня акселераторов существует:

    • Windows Cache Extension for PHP
    • XCache
    • Zend OPcache

    В PHP версии 5.5 и выше уже встроен акселератор Zend OPcache, поэтому чтобы включить акселератор, вам достаточно просто обновить версию PHP

    Кеширование на стороне сайта

    Как правило, тут подразумевается возможность CMS сайта создавать статические html-копии страниц. Такой возможностью обладают большинство популярных движков и фреймворков. Лично я работал со Smarty, WordPress, поэтому могу заверить, что они отлично справляются со своей работой. В оригинальном WordPress из коробки нет кеширующих возможностей, которые необходимы любому малость нагруженному проекту, зато есть множество популярных плагинов для кеширования:

    1. WP Super Cache, который как раз и занимается генерацией статических страниц сайта;
    2. Hyper Cache, который по сути работает так же, как и предыдущий плагин;
    3. DB Cache. Суть работы — кеширование запросов к базе данных. Тоже очень полезная функция. Можно использовать в связке с двумя предыдущими плагинами;
    4. W3 Total Cache. Оставил его на десерт, это мой любимый плагин в WordPress. С ним сайт преображается, превращаясь из неповоротливого автобуса в гоночный болид. Его огромным преимуществом является огромный набор возможностей, как то несколько вариантов кеширования (статика, акселераторы, Memcached, запросы к базе данных, объектное и страничное кеширование), конкатенация и минификация кода (объединение и сжатие файлов CSS, Javascript, сжатие HTML за счёт удаления пробелов), использование CDN и многое другое.

    Что тут скажешь — используйте правильные CMS, и качественное кеширование будет доступно практически из коробки.

    Кеширование на стороне браузера (клиента), заголовки кеширования

    Кеширование в браузере возможно потому, что любой уважающий себя браузер это позволяет и поощряет. Возможно это благодаря HTTP заголовкам, которые сервер отдаёт клиенту, а именно:

    Благодаря им пользователи, которые неоднократно заходят на сайт, тратят крайне мало времени на загрузку страниц. Заголовки кеширования должны применяться ко всем кешируемым статическим ресурсам: файлы шаблона, картинок, файлы javascript и css, если есть, PDF, аудио и видео, и так далее.
    Рекомендуется выставлять заголовки так, чтобы статика хранилась не менее недели и не более года, лучше всего год.

    Expires

    Заголовок Expires отвечает за то, как долго кеш является актуальным, и браузер может использовать кешированные ресурсы, не запрашивая у сервера их новую версию. Является сильным и крайне желательным к использованию, так как действует в обязательном порядке. В заголовке рекомендуется указывать срок от недели до года. Больше года лучше не указывать, это является нарушением правил RFC.

    Например, чтобы настроить Expires в NGINX для всех статических файлов на год (365 дней), в конфигурационном файле NGINX должен присутствовать код

    Чтобы настроить Expires в Apache для всех статических файлов на год (365 дней), в конфигурационном файле Apache, либо в .htaccess нужно прописать


    Cache-Control: max-age;

    Cache-Control: max-age отвечает за то же самое.
    Более предпочтительно использование Expires, нежели Cache-Control ввиду большей распространённости. Однако, если Expires и Cache-Control будут присутствовать в заголовках одновременно, то приоритет будет отдан Cache-Control.

    В NGINX Cache-Control включается так же, как и Expires, директивой expires: 365d;

    Пример настройки Cache-Control в Apache при включённом кеширующем модуле mod_expires.

    В данном примере, кеширующий заголовок включает кеш всех файлов, имеющих вышеперечисленные расширения сроком на 6 месяцев (2592000 секунд).

    Last-Modified и ETag

    Эти заголовки работают по принципу цифровых отпечатков. Это означает, что для каждого адреса URL в кеше будет устанавливаться свой уникальный id. Last-Modified создаёт его на основе даты последнего изменения. Заголовок ETag использует любой уникальный идентификатор ресурса (чаще всего это версия файла или хеш контента). Last-Modified – «слабый» заголовок, так как браузер применяет эвристические алгоритмы, чтобы определить, запрашивать ли элемент из кеша.

    В NGINX для статичных файлов ETag и Last-Modified включены по умолчанию. Для динамических страниц их либо лучше не указывать, либо это должен делать скрипт, генерирующий страницу, либо, что лучше всего, использовать правильно настроенный кеш, тогда NGINX сам позаботится о заголовках. Например, для WordPress, вы можете воспользоваться WP Super Cache.

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

    Одновременное использование Expires и Cache-Control: max-age избыточно, так же, как избыточно одновременное использование Last-Modified и ETag. Используйте в связке Expires + ETag либо Expires + Last-Modified.

    Включить GZIP сжатие для статичных файлов

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

    Кэширование изображений в ASP.NET

    Written on 05 Июля 2013 . Posted in ASP.NET

    ОГЛАВЛЕНИЕ

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

    Введение

    Есть много способов повышения производительности веб-приложений. Одним из простейших, но самых эффективных методов является кэширование изображений в клиенте. В данной статье показано, как было реализовано кэширование изображений для сайта DotNetNuke.

    Проблема

    При создании сайта http://www.software-architects.com/ использовалось много изображений в стилях css для отображения фоновых изображений для элементов меню. После переноса файлов на веб-сервер было проверено с помощью сетевого монитора Microsoft, сколько трафика генерирует запрос к начальной странице. Это инструмент для сбора и анализа протоколов сетевого трафика. Его можно скачать из центра загрузок Microsoft.

    С помощью сетевого монитора Microsoft 3.1 был записан вызов к http://www.software-architects.com/. В результате было получено 20 запросов к 20 разным файлам для отображения одной страницы. Сетевой монитор Microsoft показывает, что около половины запросов требуются для изображений меню.

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

    Кэширование изображений в IIS

    Кэширование в IIS очень простое. Выберите папку в левой панели или один файл в правой панели и откройте диалоговое окно свойств.

    Отметьте «Включить истечение срока действия содержимого» и выберите, когда срок действия вашего содержимого должен истечь.

    Все! IIS сообщает клиенту с помощью заголовка «Cache-Control(управление КЭШем)», что содержимое может кэшироваться в клиенте. Заголовок «Expires(истекает)» содержит дату истечения срока действия. Клиент знает, что после этой даты он должен запросить у сервера новое содержимое.

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

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

    Кэширование изображений с помощью специального обработчика HttpHandler

    Первой задачей, требующей решения, был обход IIS для получения запроса к ASP.NET. Было решено написать специальный обработчик http, слушающий файлы с путями *.gif.ashx, *.jpg.ashx и *.png.ashx. Хорошую статью об IHttpHandler читайте на сайте APress: Используйте локальную область видимости для повышения производительности.
    Был создан новый проект библиотеки классов в Visual Studio с классом CachingHandler, отвечающим за обработку запросов к изображениям. CachingHandler реализует интерфейс IHttpHandler, как делает класс Page(страница). Интерфейс предоставляет свойство IsReusable и метод ProcessRequest.

    IsResuable показывает, может ли другой запрос повторно использовать обработчик http. То есть, надо гарантировать потокобезопасность метода ProcessRequest.

    ProcessRequest делает реальную работу. Он получает текущий контекст и отправляет результат клиенту.

    Обработчик http должен отправить файл клиенту. При слушании файлов с путями *.gif.ashx, *.jpg.ashx и *.png.ashx надо удалить «.ashx» из пути запроса, чтобы получить файл, который надо отправить клиенту. Кроме того, надо извлечь имя файла и расширение из файла.

    Далее загружается конфигурация для CachingHandler из файла web.config. Поэтому был создан класс CachingSection (показан позже), содержащий свойство CachingTimeSpan(интервал времени кэширования) и коллекцию FileExtensions(расширения файлов), знающую тип содержимого для каждого расширения файла. С помощью класса config конфигурируется объект ответа HttpCachePolicy(правила кэширования http):

    • SetExpires говорит клиенту, когда истекает срок действия содержимого.
    • SetCacheability говорит клиенту, кому разрешено кэшировать содержимое. Кэшируемость задается публичная. Отсюда следует, что ответ кэшируется клиентами и общими кэшами (кэш-посредниками).
    • SetValidUnitExpires задает, должен ли кэш ASP.NET игнорировать заголовки HTTP Cache-Control (управление кэшем), отправляемые клиентом, аннулирующие кэш.
    • ContentType устанавливает MIME-тип ответа.

    Наконец, в ответ добавляется заголовок content-disposition(расположение содержимого), сообщающий клиенту, что он должен открыть файл в браузере (встроенном). Кроме того, в качестве имени файла задается имя без расширения .ashx, потому что это имя будет отображаться при скачивании файла. Затем WriteFile используется для отправки файла клиенту.

    Определение специальных секций конфигурации в web.config

    В обработчике http использовался специальный класс для считывания конфигурационных данных из файла web.config. Поэтому был создан класс CachingSection, производный от ConfigurationSection. В этом классе реализовано свойство CachingTimeSpan, хранящее значение TimeSpan для времени кэширования объектов в клиенте и свойство FileExtensions, хранящее коллекцию объектов FileExtension. Чтобы сопоставить эти свойства с элементами в web.config, надо добавить к каждому свойству атрибут ConfigurationProperty, устанавливаемый в web.config.

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

    Можно скачать полный код для файла CachingSection.cs.

    Для каждого расширения нужен класс, хранящий свойство для расширения и свойство для типа содержимого.

    Теперь надо добавить раздел конфигурации в web.config. В теге configSections добавляется новый sectionGroup с именем SoftwareArchitects. В эту группу добавляется раздел по имени Caching. Тип атрибута задает класс и сборку класса CachingSection. Конечно, надо добавить сборку с классом CachingSection в папку bin веб-приложения. Затем можно добавить новый тег с именем группы в тег конфигурации. Внутрь группы добавляется новый тег с именем раздела, и в этом разделе теперь доступны все свойства, определенные в классе CachingSection.

    Прежде чем можно будет использовать CachingHandler, надо добавить его в раздел httpHandlers в web.config. Туда надо добавить запись для каждого расширения файла, которое надо сопоставить с обработчиком http. Было решено поддерживать изображения с расширениями .gif, .jpg и .png. Поэтому был добавлен обработчик для путей *.gif.ashx, *.jpg.ashx и *.png.ashx. В атрибуте типа был указан класс и сборка обработчика http. Конечно, сборку также надо поместить в папку bin.

    Также можно использовать другие расширения файлов, например *.gifx. Но для этого надо иметь доступ к IIS, чтобы настроить обработку новых расширений с помощью aspnet_isapi.dll. Так как поставщик услуг хостинга не давал доступ к IIS, пришлось использовать *.ashx, потому что он уже сопоставлен с aspnet_isapi.dll.

    Наконец, было добавлено расширение .ashx ко всем изображениям на сайте (в файлах .css и в файлах .aspx). При повторной проверке запроса к главной странице сайта первый запрос по-прежнему генерировал 20 запросов к веб-серверу, но второй запрос потребовал лишь 7 запросов к серверу для загрузки страницы, так как изображения были закэшированы в клиенте.

    Его работу можно увидеть на сайте http://www.software-architects.at/TechnicalArticles/CachinginASPNET/tabid/75/language/de-AT/Default.aspx. Щелкните правой кнопкой мыши по изображению и откройте диалоговое окно свойств. Вы увидите, что URL заканчивается на .ashx. Когда вы щелкаете правой кнопкой мыши по изображению и выбираете «Сохранить изображение как. «, предложенное имя файла не содержит расширение .ashx из-за заголовка content-disposition.
    Разумеется, можно использовать обработчик для других типов файлов, таких как файлы javascript или файлы css. Следовательно, вновь сократится число запросов.

    Тестирование CachingHandler

    Кэширование изображений легко протестировать с помощью простого сайта. Был добавлен проект сайта с именем CachingWebSite в решение Visual Studio, позволяющий проверить работу кэширования (скачать готовое решение). С одной стороны, сайт содержит страницу Default.aspx, содержащую тег изображения. Как видно, источник изображения заканчивается на .ashx.

    С другой стороны, сайт содержит стандартную тему с таблицей стилей Style.css. В таблице стилей используется фоновое изображение. Снова источник изображения заканчивается на .ashx.

    В web.config сайта был вставлен специальный раздел для настройки CachingHandler и обработчика http для каждого расширения, точно как описано выше. Более того, был добавлен тег трассировки в раздел system.web, чтобы отслеживать каждый запрос к файлу.

    При запуске проекта сайта отображается страница Default.aspx с логотипом, определенным в Default.aspx, и с фоновым изображением, определенным в таблице стилей.

    Чтобы просмотреть трассировку, откройте новую вкладку в IE и замените Default.aspx на Trace.axd в URL. Трассировка показывает, что потребовалось четыре запроса для отображения страницы Default.aspx. При первом запросе и каждый раз, когда пользователь нажимает F5, все файлы отправляются клиенту.

    Переключившись обратно на первую вкладку, вы получите три варианта перезагрузки страницы. Вы можете
    • нажать F5
    • нажать ссылку «Перезагрузить страницу. «
    • нажать кнопку » Перезагрузить страницу. «

    Нажатие на F5 перезагрузит все содержимое, тогда как нажатие ссылки или кнопки перезагрузит только содержимое, не закэшированное в клиенте. Ради следующего снимка экрана были нажаты ссылка и кнопка. Как видно, в трассировку добавились только запросы к Default.aspx и Style.css.

    Если пользователь переходит на страницу с помощью гиперссылки или выполняет обратную передачу, с сервера запрашиваются только файлы, не закэшированные в клиенте. Запросы № 5 и № 6 были вызваны нажатием ссылки, тогда как запросы № 7 и № 8 были вызваны нажатием кнопки.

    Как использовать кеш браузера пользователей для ускорения сайта (заголовки Last-Modified, ETag, Expires, Cache-Control)

    Здравствуйте, уважаемые читатели блога Goldbusinessnet.com. Продолжаю цикл статей, которые касаются мероприятий по оптимизации, и сегодня настал черед для настройки использования в этих целях кэша браузера со стороны пользователей, что является очередным шагом выполнения рекомендаций Google Page Speed по ускорению сайта.

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

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

    Рекомендация PageSpeed — используйте кэш браузера

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

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

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

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

    Тогда после процедуры gzip сжатия файлов CSS, JS, HTML следующим по приоритету советом была как раз необходимость использования кэша браузера:

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

    У моего теперешнего хостера кэширование включено, поэтому при анализе этого блога в упомянутом чуть выше online сервисе Pagespeed отразились опять же только внешние элементы, которые мне не подвластны (Граватар, контекстная реклама, Яндекс Метрика, Гугл Аналитикс):

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

    Настройка кеширования в браузере пользователей в целях увеличения скорости сайта

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

    Более того, описанные ниже телодвижения дадут результат только в том случае, ежели у вас работает Апач в чистом виде. Если используется связка Apache + nginx, то настраивать придется последний, и в этом случае владельцам сайтов на разделенном виртуальном хостинге без помощи не обойтись. Так что придется обратиться к хостеру (впрочем, тоже вариант).

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

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

    Находится .htaccess обычно в корневой директории (папке public_html или htdocs) вашего сайта. Для начала проверьте его наличие, подсоединившись к удаленному серверу, где хостится ваш проект, посредством ФТП-соединения (тут у меня разобран по косточкам менеджер Файлзилла). Если вы файла .htaccess в корне не наблюдаете, то попробуйте из верхнего меню FileZilla выбрать «Сервер» — «Принудительно отображать скрытые файлы»:

    Если и в этом случае он не появится (что, впрочем, маловероятно), примените замечательный редактор Нотепад плюс плюс и создайте в нем такой файл:

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

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

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

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

    Во-первых, необходимо обеспечить своевременное обновление веб-обозревателями кэшируемых объектов в интересах пользователей, которые будут получать в этом случае актуальный контент. Это можно сделать, используя заголовки Last-Modified и ETag (одновременно их оба нет нужды выводить, об этом недвусмысленно говорит сам Гугл).

    На практике это означает, что при отправке браузером GET запроса (в данной статье вы найдете подробности о взаимодействии сервера и клиентских приложений) он получит HTTP ответ с кодом состояния 304 (без загрузки оттуда контента), если запрашиваемый ресурс не был изменен. Этот ответ означает, что можно загрузить контент из кеша.

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

    Во-вторых, нужно обязательно указать, на протяжении какого периода браузер должен хранить в кеше те или иные ресурсы. С этой целью можно использовать Expires либо Cache-Control с параметром max-age. Вывод этих заголовков инициируется с помощью модулей соответственно mod_expires и mod_headers, которые в том числе содержат названия объектов, к которым и будет применены правила хранения их в кеше.

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

    Илон Маск рекомендует:  Что такое код sybase_min_client_severity

    В первую очередь, это весьма распространенные статические объекты, подлежащие хранению в кеше (скрипты, файлы стилей CSS, изображения с расширениями .png, .jpg, .gif и другие).

    Эти вводные, а также тот факт, что мы в качестве инструмента используем .htaccess, работающий на огромном множестве серверов Апач, позволит составить директиву, содержащую необходимый минимум правил, подходящий многим ресурсам, работающим на разных CMS.

    Что важно, в большинстве своем предложенный ниже код вполне достаточен для того, чтобы создать условия, при которых Pagespeed больше не будет предъявлять претензий, а, значит, он обеспечит ускорение загрузки страниц в необходимом объеме.

    Итак, на основании выше сказанного нам нужно обеспечить вывод одного из заголовков Last-Modified и ETag, а также одного из пары Expires либо Cache-Control: max-age. Для наглядности и расширения диапазона рассмотрим различные варианты.

    Вариации кодов для управления кешем с использованием заголовков Last-Modified, Expires и Cache-Control

    Если на вашем хостинге уже настроен вывод того же Last-Modified, то пол-дела сделано (к слову, проверить наличие этого важного заголовка можно с помощью онлайн сервисов, включая в их список инструмент для проверки ответа сервера от Яндекса). Если же нет, то сделать это весьма несложно, прописав в том же незаменимом .htaccess пару строк:

    Правда, работать этот метод будет опять же при условии наличия «чистого Апача» (но ведь как раз этот случай мы и рассматриваем). Будем считать, что заголовок Last-Modified, в качестве значения которого, кстати, будет выводится дата последнего изменения, настроен.

    Теперь настала очередь Cache-Control с параметром max-age, в качестве значения которого будет прописан срок хранения в кеше каждого конкретного статического объекта. На сцену выходит модуль mod headers, код которого и следует вставить в .htaccess:

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

    Время сохранения кеша определяется с помощью параметра max-age, его значение выставляется в секундах. Благодаря комментариям (которые, к слову, вы можете спокойно удалить), стоящим после символа решетки «#», основа этой конструкции, думаю, понятна.

    Однако, вместо mod headers вполне можно воспользоваться модулем mod expires, выводящим заголовок Expires (который, по мнению самого Гугла является предпочтительнее, поскольку имеет более широкую поддержку). При этом фрагмент кода для его включения будет таким:

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

    Для того, чтобы убедиться в этом, посмотрите на участок кода, касающийся изображений. Там я специально указал время в различных единицах исчисления: 1 month (месяц), 4 weeks (недели), 30 days (дни), 43829 minutes (минуты), 2592000 seconds (секунды).

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

    В дополнение к упомянутым модулям полезно задействовать еще и mod setenvif. Дело в том, что веб-обозреватели семейства Microsoft Internet Explorer и некоторые версии Мазилы корректно не воспринимают в ответе сервера HTTP заголовок Vary, который также вносит свою важную лепту в управление кэшированием. Этот модуль как раз позволяет решить эту проблему, исключая Vary из состава ответа сервера:


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

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

    Код формирования заголовков Etag и Expires для настройки кэша

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

    Но если в качестве значения Expires отображается дата последнего изменения, то в ETag используется тот или иной уникальный идентификатор ресурса (чаще в этой роли выступает версия файла). Для активации ETag требуется лишь ввести в тот же .htaccess одну строчку:

    Ну а затем применить уже известный нам модуль mod expires. Можно добавить и mod setenvif, который, как я уже сказал выше, запрещает формирование заголовков Vary для определенной группы веб-браузеров, чтобы гарантировать образование кеша с их стороны:

    Здесь использован комплекс с минимумом типов задействованных объектов, но зато наиболее востребованных (CSS, JavaScript и изображения), который также должен быть достаточным, чтобы обеспечить максимальную эффективность в ускорении сайта. При желании к комплекту «jpg|jpeg|gif|png|ico|css|js» можно добавить другие виды файлов.

    Кроме того, в приведенном выше примере кода для всех файлов действует один и тот же период «жизни» кеша, равный одному году («access plus 1 year»), который является рекомендуемым со стороны Гугла. Но можно для каждой группы объектов указать свой временной отрезок по примеру содержания модулей mod_expires и mod_headers из предыдущего раздела статьи.

    Проверка наличия нужных заголовков в ответе сервера

    После того, как вы вставите код в файл .htaccess, можно проверить, находятся ли необходимые заголовки в составе ответа сервера. Для этой цели можно воспользоваться каким-нибудь онлайн сервисом, например, Checkmy.ru, где в качестве клиента (User Agent), посылающего HTTP-запрос на сервер, выбираем любой браузер, а также вводим URL ресурса (для примера я взял путь до изображения, используемого в одной из статей блога):

    После нажатия кнопки «Отправить запрос», через несколько секунд появится результат:

    Как видите, в моем случае присутствуют все четыре заголовка. Я говорил, что обязательно должны выводится по одному из пар «Last-Modified — ETag» и «Expires — Cache-Control», остальные излишни. При этом полный комплект, насколько можно судить, не причинит вреда.

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

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

    Далее советую для закрепления материала обратиться к видео и посмотреть последовательно 6 уроков (один из которых посвящен настройке кеширования в браузерах), в которых подробно рассмотрены все наиболее важные аспекты ускорения сайта WP:

    Кеширование изображений с других сайтов

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

    Нажав кнопку «Принять и продолжить», вы соглашаетесь с Политики конфиденциальности

    Мы запустили рейтинг зарплат интернет-маркетологов! Прими участие в анонимном опросе.

    How-to – Читать 7 минут – 14 декабря 2020

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

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

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

    Рекомендации Google по оптимизации скорости загрузки сайтов

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

    Избегайте ошибочных запросов

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

    Исправление ошибочных запросов гораздо проще нахождения их. Если вы нашли какой-либо неправильный запрос, просто уберите ненужный код из HTML- или CSS-файла или скорректируйте его.

    Крайне важно контролировать скорость загрузки страницы и отслеживать обращения к несуществующим ресурсам!

    Избегайте методов «@import»

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

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

    Заменить их необходимо на прямое подключение стилей в HTML-коде:

    Объединяйте CSS-файлы

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

    Для этого сделайте простую операцию copy-paste из нескольких файлов в один! Один CSS-файл будет содержать ровно столько же полезной информации для сайта, но увеличит скорость загрузки!

    После объединения файлов не забудьте удалить лишние подключения старых файлов в HTML-коде страниц.

    Избегайте функции «document.write» в HTML

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

    Проверьте весь ваш HTML-код на наличие директив document.write, которые могут выглядеть так:

    Вместо этого используйте просто подключение внешнего скрипта при помощи такого вызова в HTML-коде страницы:

    Объединяйте внешние JS-файлы

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

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

    Объединяйте изображения в CSS-спрайты

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

    Количество обращений к серверу и, соответственно, скорость загрузки страниц можно уменьшить, объединяя несколько изображений в один CSS-спрайт (CSS-sprite). Вместо загрузки большого количества изображений ваш браузер теперь будет загружать одно! И в этом — прелесть CSS-спрайтов! Конечно, это в большей степени касается объединения нескольких небольших изображений, используемых в элементах оформления WEB-страницы (фоны меню, смайлы, углы, иконки и пр.).

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

    На примере двух изображений (рупора и смайла), объединенных в один спрайт, для отображения рупора напишем следующий CSS-стиль:

    Для смайла стиль будет выглядеть следующим образом:

    Соответствующие им фрагменты HTML-кода будут такими:

    Откладывайте загрузку JavaScript

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

    Только обозначенное ниже решение позволит загружать внешний скрипт ТОЛЬКО после полной загрузки страницы и не вызовет предупреждение «Defer loading of javascript» в инструментах для веб-мастеров от Google. Вот он, рекомендуемый Google, метод:

    Используйте кэширование

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

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

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

    ExpiresActive On
    ExpiresByType image/jpg «access 1 year»
    ExpiresByType image/jpeg «access 1 year»
    ExpiresByType image/gif «access 1 year»
    ExpiresByType image/png «access 1 year»
    ExpiresByType text/css «access 1 month»
    ExpiresByType text/html «access 1 month»
    ExpiresByType application/pdf «access 1 month»
    ExpiresByType text/x-javascript «access 1 month»
    ExpiresByType application/x-shockwave-flash «access 1 month»
    ExpiresByType image/x-icon «access 1 year»
    ExpiresDefault «access 1 month»

    Параметры access 1 year или access 1 month устанавливают время кэширования для выбранного типа данных. Вы можете настроить эти значения самостоятельно на свое усмотрение.

    Альтернативный код для включения кэширования через файл .htaccess:

    # Кэшировать html и htm файлы на 6 часов

    Header set Cache-Control «max-age=21600»

    # Кэшировать css, javascript и текстовые файлы на одну неделю

    Header set Cache-Control «max-age=604800»

    # Кэшировать флэш и изображения на месяц

    Header set Cache-Control «max-age=2592000»

    # Отключить кэширование для исполняемых файлов

    Header unset Cache-Control

    Во втором примере время кэширования max-age задается в секундах.

    Минимизируйте CSS-код

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

    Объясним на примерах что означает термин «минимизация CSS».

    «Обычный» CSS-код может выглядеть так:

    body <
    background-color: #ff0000;
    >

    h1 <
    color: red;
    text-align: right;
    >

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

    И это еще не всё. Если подходить к минимизации совсем «сурово», то можно отказаться от переносов на новую строку (2 байта экономии на каждом переносе) и не добавлять точку с запятой в конце каждого стиля (1 байт экономии на каждой точке с запятой).

    Уменьшая код таким образом, можно существенно сэкономить на его объеме и значительно выиграть в скорости загрузки страниц вашего сайта!

    Минимизируйте DNS-запросы

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

    Одним из ярких примеров таких обращений могут служить кнопки социальных сетей (Одноклассники, ВКонтакте, Facebook, Twitter, Google+ и т.д.): при их формировании на вашем сайте происходят обращения к внешним сайтам. Другой пример — использование (подключение) Google Web Fonts. Каждый шрифт требует использование двух DNS-запросов.

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

    Минимизируйте редиректы

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

    Редиректы означают необходимость обращения к одному файлу при обращении к другому. И они осуществляются во многих направлениях. Пример — редирект 301 — постоянное перенаправление с одного адреса на другой. Это, наверное, один из наиболее часто встречающихся редиректов, который используется при перенаправлении сайта с www на сайт без www (или наоборот) для исключения дублирования индексации сайтов-зеркал.

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

    При использовании редиректов придерживайтесь простых правил:

    • Никогда не делайте ссылку на страницу, если вы знаете, что на ней есть редирект;
    • Никогда не делайте более одного редиректа для достижения необходимого ресурса.

    Оптимизируйте порядок вызова стилей и скриптов

    Важно выбирать правильную последовательность загрузки стилей и скриптов в HTML-коде страниц вашего сайта. Сначала необходимо указывать внутренние объявления стилей, затем подключение внешних файлов стилей, и после этого — скрипты. Google проводил тестирование, на основе которых был сделан вывод о необходимости именно такой последовательности при объявлении стилей и скриптов.

    Когда интернет-браузер загружает страницу, он читает HTML-код и начинает последовательно вызывать ресурсы, которые указаны в коде (CSS-стили, скрипты, изображения и т.д.). Когда браузер начинает загружать скрипт, он останавливает загрузку чего-либо еще до тех пор, пока скрипт не прочитан (загружен) полностью. Google утверждает, что типичная веб-страница проводит от 80 до 90 процентов времени в ожидании загрузки из сети. Чтобы минимизировать это время, необходимо просто правильно размещать вызовы ресурсов на страницах и придерживаться следующих правил:

    • Объединяйте несколько внешних JavaScript-файлов в один;
    • Подключайте внешний CSS-файл перед подключением внешнего JavaScript-файла;
    • Не используйте внутренний JavaScript (в HTML-коде страницы) между вызовом внешнего CSS-файла и подключением других ресурсов.

    Используйте изображения правильных размеров

    Очень часто на сайтах веб-мастера не задумываются о правильных размерах изображений: для отображения маленьких рисунков (миниатюр) часто используются большие изображения с принудительной установкой малых размеров через параметры width и height.

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

    Для правильного размещения изображений необходимо:

    • Использовать изображения нужных размеров: при размещении на странице миниатюры следует использовать миниатюры изображений, для больших фотографий — изображения соответствующего размера;
    • Указывать точные размеры изображений: в атрибутах width и height тэга необходимо указывать точные изображения загружаемых картинок. В противном случае браузер может отобразить их в искаженном виде;
    • Не пренебрегать атрибутами width и height: если вы не указываете эти параметры, при медленной загрузке информация на странице может «прыгать», браузер будет формировать страницу не один раз, а дважды или более раз (в зависимости от количества изображений на странице): сначала браузер прочитает и разместит текст без учета размера изображений, затем подгрузятся картинки, «вклинятся» в текст и переместят его по-другому. Если же вы заранее укажете браузеру на размеры изображений, он уже будет знать про отведенное для них место и ему не придется помногу раз перекраивать web-страницу.

    Пример из личного опыта

    Во время аудита одного из наших «подопечных» сайтов мы обнаружили ну просто гигантское изображение — размером 4049×2699 пикселей. На странице оно принудительно сжималась средствами браузера путем указания ей требуемых размеров. Исходное изображение (залито красным цветом), помимо огромного размера, занимало 5.74 МБ (6 026 239 байт) на хостинге. Оптимизированное изображение (залито зеленым цветом) размером 250×167 пикселей стало «весить» всего 10.5 КБ (10 805 байт). Уменьшение в 557(!) раз налицо:

    Использование этих несложных правил позволит вашему сайту загружаться быстрее!

    Используйте файл .htaccess

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

    На всякий случай рекомендуется делать резервную копию этого файла перед его изменением!

    .htaccess — это файл, размещаемый в корневой (и не только в корневой) папке вашего сайта, в нем указываются параметры работы сервера и сайта, которые обычно используются в конфигурационных файлах web-сервера. Редактируется этот файл при помощи обычного текстового редактора.

    Информацию по работе с файлом .htaccess вы можете на соответствующих интернет-ресурсах.

    По материалам сайта www.feedthebot.com

    Сервисы для проверки скорости загрузки сайта

    Одними из самых популярных сервисов для проверки скорости загрузки сайтов являются:

    Поможем с оптимизацией скорости загрузки вашего сайта!

    Начните с простого звонка Наш телефон — — работает в режиме нон-стоп, чтобы вы могли оперативно получать интересующую вас информацию по решению задач развития и поддержки вашего сайта. Или пишите на электронную почту info@t-design.ru. Наша служба технической поддержки — это профессионалы в области сайтостроения, верски и адаптации материалов для размещения в интернете. Вы можете быть уверены, что все работы будут проведены строго в соответствии с принятыми правилами и с учетом нашего большого опыта работы в этой сфере. Мы проконсультируем по всем вопросам и подберем оптимальный тариф для вашей компании.

    Все услуги

    Битрикс24

    Удобная и понятная система управления компанией и бизнес-процессами, включающая в себя полный комплекс инструментов, необходимых современному руководителю предприятия и его сотрудникам.

    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL