Кэширование кода для JavaScript-разработчиков на примере Chrome


Оглавление (нажмите, чтобы открыть):

JavaScript кэширование

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

К счастью, мы можем воспользоваться возможностями JavaScript’a и написать функцию cache, способную кэшировать результаты работы других методов, чтобы, в случае надобности, повторно не вызывать эти самые методы:

Теперь на примерах рассмотрим как будет вести себя написанная выше функция cache.

Пример 1. Кэширование querySelector

Теперь посмотрим на скорость работы _io_q и querySelector:

Пример 2. Кэширование запросов с сервера

Напишем функцию, которая отправляет очень тяжелый запрос на сервер:

Посмотрим как будет вести себя функция:

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

Как и зачем используется заголовок Cache-control

Как использовать Cache-control c изменяемыми файлами

Уменьшение размера картинок при сохранении качества

Что такое Etag и как его настроить в Nginx

Как улучшить время получения первого байта и отзывчивость веб-сервера

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

Accelerated Mobile Pages для ускорения контентных страниц для мобильных устройств

Методы оптимизации сайтов на стороне браузеров

Как работает сжатие gzip и как его включить

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

Что такое minify и как его использовать

Оптимизация скорости загрузки баннерной рекламы

Основные ньюансы и методы мобильной оптимизации

Cache control в Nginx, как настроить и использовать

Улучшение производительности Web сервера на Ubuntu

Анализ скорости сайта с помощью Google Pagespeed

Анализ производительности страниц с помощью User Timing

Ускорение PHP приложений на платформе YII в несколько раз

Какие преимущества дает CDN и как с ним работать

Кэширование css, javascript ресурсов assets в yii2.

Автор: admin | 09 августа (Чт.) 2020г. в 23ч.44м.

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

Для того, чтобы включить кэш статических файлов ресурсов css и js в yii2 нужно сделать следующее. В файле конфигурации приложения main.php или config.php в yii2 находим массив ‘components’ и конфиг ‘assetManager’, если нет, то добавляем. Пишем следующее:

Теперь в качестве версии файла будет добавлена метка времени последней модификации файла. При изменении файла метка времени будет обновлена и браузер соответственно будет «работать» с новой версией файла.

Как проверить, что ресурс кэшируется?

Для того, чтобы убедиться что кэширование файлов css и js в браузере работает можно воспользоваться инструментом разработчика в google chrome. Перейдем на вкладку network и обновим страницу целевого сайта. Далее смотрим показатели скорости загрузки каждого скрипта:

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

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

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

Приветствую!

Меня зовут Сергей. Я — автор этого блога.

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

Отладка скриптов в браузере Chrome

Отладка скриптов в браузере Chrome

Здравствуйте! В продолжении темы обработки ошибок в JavaScript поговорим об отладке скриптов силами браузера. Для примера возьмем самый лучший браузер на Земле — Chrome.

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

Общий вид панели Sources

Запустите браузер Chrome.

Нажмите F12, при этом запустятся Инструменты разработчика.

Перейдите на вкладку Source

Здесь можно выделить 3 зоны:

  1. Область исходных файлов. В ней находятся все файлы проекта
  2. Область текста. В этой области находятся текст файла
  3. Область информации и контроля. О ней разговор пойдет позже

Как правило при отладке область исходных файлов не нужна, поэтому ее можно скрыть кнопкой.

Общие кнопки управления

3 наиболее часто используемые кнопки управления:

Формат Эта кнопка позволяет отформатировать код. Может вам понадобиться, если вы желаете отформатировать чужой код. Консоль Очень важная кнопка по нажатию на которой открывается консоль. В консоли можно вводить различные команды и операторы на JavaScript. Окно В случае с большим участком кода позволяет открыть код в отдельном окне.

Точки останова

Рассмотрим на примере файла pow.js. Если клацнуть на любой строке этого файла, то на этой строке будет задана точка останова.

Выглядеть это примерно так:

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

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

Информация о точке останова появляется на вкладке Breakpoints.

Вкладка Breakpoints очень полезна, когда код очень большой, она позволяет:

  • Быстро перейти на то место кода, где поставлен брейкпойнт простым кликом на текст.
  • Временно отключить точку останова кликом на чекбокс.
  • Быстро удалить точку останова правым кликом на текст и выбором Remove.
  • Точку останова можно инициировать и напрямую из а скрипта, командой debugger:
  • Правый клик на номере строки pow.js позволит вам создать так называемую условную точку останова (conditional breakpoint), т.е. задать условие, при котором точка останова сработает.

Остановиться и осмотреться

Поскольку наша функция выполняется одновременно с загрузкой страницы, то самый простой способ активировать отладчик JavaScript – это перезагрузить её. Для этого нажмите F5. И при этом выполнения скрипта будет остановлено на 6-й строке.

Обратите внимание на информационные вкладки:

  • Watch Expressions – здесь можно увидеть текущее значение переменных , которые вы отслеживаете в скрипте.
  • Call Stack – показывает стек вызовов — это все вызовы приведшие к этой строке кода.
  • Scope Variables – показывает переменные. Причем показывает как глобальные так и локальные переменные.

Управление выполнением

А теперь давайте «погоняем » скрипт и отследим его работу. Обратите внимание на панель сверху там находятся 6 кнопок работу которых мы и рассмотрим.

– продолжить выполнение, или можно нажать на клавишу F8. Эта кнопка продолжает выполнение скрипта. Таким образом мы можем пошагово проходить наш сценарий как будто он запускается в браузере. – сделать шаг, не заходя в функции, или клавиша F10.

Выполнить один шаг скрипта не заходя при этом внутрь функции.

– сделать шаг внутрь функции, клавиша F11. Выполняет один шаг скрипта и при этом заходит внутрь функции. – выполнять до выхода из текущей функции, клавиша Shift+F11.

выполняет полностью код, находящийся в функции.

– отключить/включить все точки останова. Эта кнопка просто отключает и при повторном нажатии включает все точки останова. – включить/отключить автоматическую остановку при ошибке. Данная кнопка весьма полезна при отладке и позволяет включать и отключать автоматическую остановку при ошибке.

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

Консоль браузера

При отладке кода скрипта бывает полезным перейти на вкладку Console и посмотреть нет ли там ошибок также можно выводить информацию в консоль с помощью console.log().

Консоль доступна в любом браузере

Ошибки в консоли

Ошибки JavaScript скриптов можно посмотреть в консоли.

В консоли вы можете увидеть:

Красная строка – это собственно сообщение об ошибке.

Если вы кликните на ссылке pow.js в консоли, справа в строке с ошибкой, то вы перейдете непосредственно к тому месту в скрипте, где эта ошибка произошла.

Итого

Отладчик вам позволяет:

  • Останавливаться на отмеченном месте (точка останова) или по команде debugger.
  • Выполнять код – отлаживать программу по одной строке или до определённого места.
  • Отслеживать переменные, выполнять команды в консоли и т.п.

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Сache

На этой странице

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

Интерфейс Cache представляет собой механизм хранения пары объектов Request / Response, которые кешируются, например, как часть жизненного цикла ServiceWorker . Заметьте, что интерфейс Cache доступен как в области видимости окна, так и в области видимости воркеров. Не обязательно использовать его вместе с сервис воркерами, даже если интерфейс определен в их спецификации.

Для вызывающего скрипта может быть множество именованных объектов Cache . Разработчик сам определяет реализацию того, как скрипт (например, в ServiceWorker ) управляет обновлением Cache . Записи в Cache не будут обновлены, пока не будет выполнен явный запрос; их время жизни не истечет до момента удаления. Используйте CacheStorage.open(cacheName) , чтобы открыть определенный именованный объект Cache и затем вызывайте любые методы Cache для управления его состоянием.

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

Замечание: Cache.put , Cache.add и Cache.addAll допускают сохранение в кеш только GET запросов.


Замечание: Изначально, реализация Cache (как в Blink, так и в Gecko) возвращала успешное завершение для промисов Cache.add , Cache.addAll и Cache.put , когда тело ответа было полностью помещено в хранилище. Более поздние версии используют новейший язык, утверждая, что браузер может разрешить промис как только запись будет записана в базу данных, даже если тело ответа все еще загружается в потоке.

Замечание: Начиная с Chrome 46, Cache API будут хранить запросы только от безопасных источников, то есть, доступных через HTTPS.

Замечание: Алгоритм сопоставления ключей зависит от заголовка VARY хранимого значения. Таким образом, сопоставление нового ключа требует одновременно как проверки самого ключа, так и значений для записей в Cache.

Замечание: Кеширующие API не приветствуют заголовки кеширования HTTP.

Методы

Примеры

Этот пример кода из примера выборочного кеширования сервис воркера. (смотрите работа выборочного кеширования). В коде используется CacheStorage.open(cacheName) для открытия любых объектов Cache с заголовком Content-Type, начинающимся с font/ .

Далее используется Cache.match(request, options) для определения того, находится ли уже совпадающий шрифт в кеше, и, если так, то возвращает его. Если же совпадающего шрифта нет, код получает этот шрифт по сети и использует Cache.put(request, response) для кеширования полученного ресурса.

Мастер Йода рекомендует:  Как начать разрабатывать под Android

Код обрабатывает исключения, возможные при операции fetch() . Заметьте, что HTTP-ответ с ошибкой (например, 404) не будет вызывать исключения. Будет возвращен нормальный объект ответа с установленным соответствующим кодом ошибки.

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

В примере кода «кеш» это аттрибут WorkerGlobalScope сервис воркеров. Он содержит объект CacheStorage, через который можно получить доступ к CacheStorage API.

Спецификации

Спецификация Статус Комментарий
Service Workers
Определение ‘Cache’ в этой спецификации.
Рабочий черновик Initial definition.

Совместимость с браузерами

Feature Chrome Firefox (Gecko) Internet Explorer Opera Safari (WebKit)
Базовая поддержка 40.0 39 (39) [1] Нет 24 Нет
add() 44.0 (Да) [1] ? ? ?
addAll() 46.0 (Да) [1] ? ? ?
matchAll() 47.0 (Да) [1] ? ? ?
Требует HTTPS для add() , addAll() , и put() 46.0 (Да) [1] ? ? ?
Feature Android Android Webview Firefox Mobile (Gecko) Firefox OS IE Mobile Opera Mobile Safari Mobile Chrome for Android
Базовая поддержка Нет Нет 39.0 (39) ? Нет ? Нет 40.0
add() Нет Нет (Да) ? ? ? ? 44.0
addAll() Нет Нет (Да) ? ? ? ? 46.0
matchAll() Нет Нет (Да) ? ? ? ? 46.0
Требует HTTPS для add() , addAll() , и put() Нет Нет (Да) ? ? ? ? 46.0

[1] Сервис воркеры (и Push) были отключены в Firefox 45 Extended Support Release (ESR.)

HTTP-кеширование

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

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

Когда сервер возвращает запрос, он также отправляет набор HTTP-заголовков, описывающих тип контента, длину, команды для работы с кешем, маркер подтверждения и т. д. Например, в примере выше сервер возвращает запрос размером 1024 Б, отдает команду клиенту кешировать его на 120 секунд и отправляет маркер подтверждения (x234dff). Он используется, чтобы проверить, не изменился ли ресурс, после того как срок действия ответа истек.

Подтверждение кешированных ответов с помощью ETags

  • Сервер отправляет маркер подтверждения в HTTP-заголовке ETag.
  • С помощью маркера подтверждения можно проверить, изменился ли ресурс.

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

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

В примере выше клиент автоматически отправляет маркер ETag в HTTP-заголовке If-None-Match. Сервер проверяет совпадение маркера с нужным ресурсом, и если тот не изменился, отправляет ответ 304 Not Modified. Это значит, что кешированный ответ остался прежним, и его можно снова использовать в течение следующих 120 секунд. Обратите внимание, что скачивать ресурс ещё раз не нужно. Это уменьшает время загрузки страницы и экономит пропускную способность канала.

Чем полезна проверка актуальности для разработчика? Браузер сделает все автоматически: проверит, был ли указан маркер подтверждения ранее, добавит его в исходящий запрос и обновит временные отметки на основе ответа от сервера. Все, что нам нужно сделать, — проверить, действительно ли сервер отправляет нужные маркеры ETag. Чтобы узнать, какие параметры следует установить, ознакомьтесь с документацией к серверу.

Note: Совет. В проекте HTML5 Boilerplate размещены примеры файлов конфигурации для самых популярных серверов с подробными комментариями для всех параметров и настроек. Найдите в списке нужный сервер, выберите подходящие настройки и убедитесь, что они установлены на вашем сервере.

Cache-Control

  • Правила кеширования ресурса можно указать с помощью HTTP-заголовка Cache-Control.
  • Директивы Cache-Control определяют, где, как и на какое время может быть кеширован ресурс.

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

no-cache и no-store

Директива no-cache означает, что при повторном запросе к тому же URL ответ можно использовать только после проверки изменений. Таким образом, если указан соответствующий маркер подтверждения (ETag), будет выполнена повторная проверка. Однако при отсутствии изменений данные не будут скачиваться ещё раз.

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

public и private

Если в ответе содержится директива public, его можно кешировать, даже если с ним связана HTTP-аутентификация и код статуса ответа обычно нельзя сохранять. Эта директива требуется редко, потому что другая информация, заданная для кеширования, (например, max-age) показывает, что ответ можно сохранить.

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

max-age

Эта директива указывает период времени в секундах, в течение которого скачанный ответ может быть повторно использован. Отсчет начинается с момента запроса. Например, max-age=60 означает, что ответ может быть кеширован и использован в течение 60 секунд.

Выбор правил Cache-Control

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

Директивы Cache-Control Значение
max-age=86400 Ответ можно сохранить в браузере и промежуточных кешах (для него указана директива»public») на 1 день (60 секунд x 60 минут x 24 часа)
private, max-age=600 Браузер может кешировать ответ на 10 минут (60 секунд x 10 минут)
no-store Ответ нельзя кешировать. При повторном запросе нужно скачать его заново.

По данным HTTP Archive, на 300 000 самых популярных сайтов по рейтингу Alexa около половины скачанных запросов можно сохранить в кеше браузера. Это помогло бы сэкономить огромные объемы данных при повторном посещении страниц. Однако это не означает, что в вашем приложении обязательно есть 50% ресурсов, которые можно сжать. Некоторые сайты сохраняются в кеше более чем на 90%, а на других размещено много личной или меняющейся со временем информации, которую кешировать невозможно.

Проверьте ваши страницы, определите, какие ресурсы можно кешировать, и убедитесь, что они возвращают правильные заголовки Cache-Control и ETag.

Аннулирование и обновление кешированных ответов

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

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

Предположим, мы задали команду кешировать таблицу стилей CSS в течение 24 часов (max-age=86400), но чуть позже обновили дизайн сайта и хотим, чтобы это увидели все пользователи. Как сообщить им, что нужно обновить устаревшую копию CSS в кеше? Это непросто, потому что нам потребуется изменить URL ресурса.

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

Как совместить кеширование ресурсов и обновления сайта? Можно просто отредактировать URL файла, чтобы пользователь скачивал новый ответ каждый раз, когда его контент меняется. Для этого добавьте в имя файла идентификационную метку или номер версии, например style.x234dff.css.

Установка правил кеширования для каждого ресурса позволяет нам определять иерархии кешей . Благодаря этому мы можем указывать, на какой период сохранен ресурс и когда пользователь увидит его новую версию. Рассмотрим пример выше.

  • Для HTML указана директива no-cache, поэтому браузер будет проверять актуальность документа при каждом запросе и при изменениях скачивать последнюю версию ресурса. Кроме того, мы изменили HTML-разметку, добавив идентификационные метки в URL CSS- и JavaScript-ресурсов. Если эти файлы изменятся, HTML тоже обновится, и браузер скачает новую копию HTML-ответа.
  • Браузерам и промежуточным кешам (например, сетям доставки контента) разрешено сохранять CSS. Срок его действия заканчивается через 1 год. Обратите внимание, что мы можем установить такой длинный период, потому что мы добавили идентификационную метку в название файла. Поэтому если CSS обновится, то URL тоже изменится.
  • Срок действия для JavaScript тоже истекает через 1 год. Однако ресурс отмечен директивой private, потому что в нем содержатся личные данные пользователи, которые нельзя сохранять в кеше сетей доставки контента.
  • У кешированного изображения нет версии или уникальной идентификационной метки, и срок его действия заканчивается через 1 день.

Таким образом, с помощью ETag, Cache-Control и уникальных URL мы можем достичь нужных нам результатов: долгих сроков действия, контроля над кешированием ресурса и обновлений в любой момент.

Список методов оптимизации

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

Помните о некоторых советах и техниках, которые помогут вам выбрать стратегию кеширования:

  1. Используйте одинаковые URL для одного ресурса. В противном случае контент каждый раз будет скачиваться заново. Помните, что в URL регистр букв имеет значение!
  2. Убедитесь, что сервер отправляет маркер подтверждения (ETag). Если ресурс на сервере не изменился, то благодаря этому маркеру те же байты не будут передаваться повторно.
  3. Определите, какие ресурсы можно сохранить в промежуточных кешах. Чаще всего это ответы, которые одинаковы для всех пользователей.
  4. Определите подходящий срок действия для каждого ресурса. У данных могут быть разные требования к частоте обновления информации. Учитывая это, выберите подходящее значение max-age для каждого ресурса.
  5. Установите подходящую иерархию кешей для вашего сайта. Используйте URL ресурсов с идентификационными отметками контента и короткие сроки действия (или директиву no-cache) для HTML-документов. С их помощью вы можете указать, когда кешированные версии данных будут обновлены.
  6. Уменьшите пересылку данных. Если часть ресурса, например функции JavaScript или наборы CSS-стилей, обновляется часто, отправляйте ее код в отдельном файле. Тогда та часть контента, которая меняется редко, например коды библиотек, может быть загружена из кеша. Это уменьшит количество скачиваемых данных при обновлении ресурса.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

25 полезных Chrome-расширений для веб-разработчиков Материал редакции

Ресурс Creative Bloq выбрал 25 расширений для браузера Google Chrome, которые, по мнению редакции, могли бы пригодиться в работе веб-разработчика.

1. iMacros for Chrome

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

Расширение способно работать с сайтами, реализованными при помощи технологий Java, Flash, Flex, Ajax и Silverlight.

2. Font Playground

Расширение для тех, кто любит «поиграть со шрифтами» — позволяет экспериментировать со всем спектром шрифтов из библиотеки Google Fonts, не внося изменений в код страницы. Можно менять не только сам шрифт, но и его размер, стиль написания и так далее.

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

3. Project Naptha

Расширение для Google Chrome, которое позволяет выделять и копировать текст даже с картинок — будет полезным, по мнению Cretive Bloq, всем, кому хоть раз в своей работе приходилось иметь дело со встроенным текстом.

4. What Font

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

5. YSlow

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

6. Web Developer

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

7. Web Developer checklist

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

8. DevTools Autosave

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

9. Instant Wireframe

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

10. Ripple Emulator

Ripple Emulator — расширение-эмулятор для Google Chrome, которое позволяет тестировать веб-сайты на различных мобильных платформах с различными разрешениями экрана. Может быть использовано в сочетании с другими расширениями для тестирования и отладки ресурсов.

11. Streak

Streak — расширение, которое позволяет превратить почтовый ящик на Gmail в CRM-систему. Можно отслеживать статус сделок и переговоров, которые ведутся в электронной почте с контрагентами, использовать Streak для обработки запросов пользователей продукта и отслеживания исправлений присланных ошибок и так далее.

12. Search Stackoverflow

Расширение для быстрого поиска по популярному ресурсу для разработчиков Stack Overflow.

13. PHP Ninja Manual

Позволяет получить мгновенный доступ к документации по PHP 5.5 из браузера.

14. PerfectPixel

PerfectPixel — расширение для Google Chrome. Оно позволяет «наложить» на веб-страницу полупрозрачную сетку и сверять по ней заданные расстояния. Можно накладывать и другие изображения — например, первоначальный макет — чтобы убедиться, что получившаяся страница в точности ему соответствует:

15. Code Cola

Инструмент для просмотра исходного кода страниц и редактирования CSS-кода.

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


16. Chrome Sniffer

Расширение для браузера, которое определяет, какие JavaScript-библиотеки, фреймворк или CMS используются на ресурсе.

17. User-Agent Switcher

User-Agent Switcher — это расширение, которое позволяет «маскировать» браузер Google Chrome под Internet Explorer, Opera или любой другой браузер.

18. IE Tab

Встроенный эмулятор Internet Explorer для Chrome.

19. PicMonkey

Простой и бесплатный онлайн-редактор изображений. Позволяет «захватывать» изображения или делать скриншоты браузера — и сразу же редактировать их при помощи расширения для Chrome.

20. Chrome Daltonize

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

21. Page Ruler

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

22. Check My Links

Расширение, которое проверяет веб-страницу на наличие «битых» или неправильных ссылок.

23. Flickr Tab

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

24. Google Art Project

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

25. Data Saver

Официальное расширение от Google для сжатия трафика, которое включает экономию трафика в браузере Google Chrome.

Изучите, как отладить JavaScript с помощью Chrome DevTools

Забудьте об отладке при помощи console.log навсегда! Изучите, как использовать точки останова для отладки кода в инструментах разработчика Chrome

Поиск и исправление ошибок может быть затруднительным. Вы можете поддаться соблазну бесконтрольно использовать console.log() , чтобы заставить ваш код работать правильно. С этим покончено!

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

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

Шаг 1: Воспроизводим ошибку

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

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

  • Вот веб-страница, с которой мы будем работать в рамках этой статьи. Открывайте её в новой вкладке: ДЕМО.
  • В демо для Number 1 введите 5 .
  • Введите 1 для Number 2.
  • Нажмите Add Number 1 and Number 2.
  • Посмотрите на метку ниже инпутов и кнопки. Она говорит, что 5 + 1 = 51 .

Упс. Это неверный результат. Результат должен быть равен 6 . Это и есть ошибка, которую мы собираемся исправить.

Шаг 2: Приостанавливаем выполнение кода с помощью точки останова

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

  • Вернитесь к демо и откройте DevTools, нажав Command+Option+I (Mac) или Control+Shift+I (Windows, Linux).
  • Перейдите во вкладку Sources.
  • Нажмите Event Listener Breakpoints, чтобы развернуть меню. DevTools раскрывает список категорий событий, таких как Animation и Clipboard.
  • Разверните категорию событий Mouse.
  • Выберите click.
  • Вернувшись к демо, снова нажмите Add Number 1 and Number 2. DevTools приостановит работу и выделит строку кода в панели Sources:

Когда вы выбираете click, вы устанавливаете точку останова на основе всех событий click . Когда происходит клик по любой ноде и эта нода имеет обработчик события click , DevTools автоматически останавливает исполнение на первой строке кода обработчика click для этой ноды.

Шаг 3: Исследуем код

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

  • На панели Sources в DevTools нажмите Step into next function call.

Эта кнопка позволяет вам осуществить выполнение функции onClick() по одной строке за раз. DevTools остановит выполнение и выделит следующую строку кода:

  • Теперь нажмите кнопку Step over next function call.

Это говорит DevTools выполнить функцию inputAreEmpty() , не заходя в неё. Обратите внимание, что DevTools пропускает несколько строк кода. Это происходит из-за того, что inputAreEmpty() расценивается как false , поэтому блок кода оператора if не выполняется.

Это основная идея исследования кода. Если вы посмотрите на код get-started.js , вы увидите, что ошибка, вероятно, находится где-то в функции updateLabel() . Вместо того, чтобы исследовать каждую строку кода, вы можете использовать другой тип точки останова, чтобы приостановить код ближе к месту ошибки.

Шаг 4: Устанавливаем другую точку останова

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

  • Посмотрите на последнюю строку кода в updateLabel() :

Слева от кода вы можете увидеть номер этой конкретной строки: 32. Нажмите на него. DevTools поместит синюю иконку поверх номера. Это означает, что на этой строке есть точка останова. DevTools теперь всегда будет приостанавливаться до неё.

  • Нажмите кнопку Resume script execution:

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

  • Посмотрите на уже выполненные строки кода в updateLabel() . DevTools выводит значения addend1 , addend2 и sum .

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

Шаг 5: Проверяем значения переменных

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

Watch Expressions — альтернатива от DevTools для console.log() . Используйте Watch Expressions для отслеживания значения переменных во времени. Как следует из названия, Watch Expressions не ограничиваются только переменными. Вы можете сохранить любое допустимое выражение JavaScript в Watch Expression. Попробуйте прямо сейчас:

  • На панели Sources DevTools нажмите Watch. Секция раскроется.
  • Нажмите Add Expression.

Как и предполагалось, sum расценивается в качестве строки, а должна быть числом. Это причина нашей ошибки в демо.

Вторая альтернатива в DevTools для console.log() — это консоль. Используйте консоль для взаимодействия с произвольными операторами JavaScript. При отладке разработчики обычно используют консоль для перезаписи значений переменных. В вашем случае консоль может нам помочь проверить возможные пути исправления обнаруженной ошибки. Попробуйте прямо сейчас:

  • Если у вас не открыта консоль, откройте её нажатием Escape. Она откроется в нижней части окна DevTools.
  • В консоли введите parseInt(addend1) + parseInt(addend2) .
  • Нажмите Enter. DevTools вычислит команду и выведет 6 — ожидаемый результат.

Шаг 6: Исправляем

Мы определили потенциальное исправление ошибки. Осталось только проверить его, отредактировав код и перезапустив демо. Вам не нужно выходить из DevTools для применения исправления. Вы можете редактировать код JavaScript непосредственно в пользовательском интерфейсе DevTools. Попробуйте прямо сейчас:

  • В редакторе кода на панели Sources DevTools замените var sum = addend1 + addend2 на var sum = parseInt(addend1) + parseInt(addend2); . Это на одну строку выше места вашей остановки.
  • Нажмите Command+S (Mac) или Control+S (Windows, Linux) для сохранения изменений. Фон кода изменится на красный, сигнализируя, что сценарий был изменен в DevTools.
  • Нажмите Deactivate breakpoints.

Кнопка окрасится синим, указывая, что она активна: DevTools игнорирует любые точки останова.

  • Нажмите Resume script execution

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

Часть этой страницы — модификации, основанные на работе, созданной и распространяемой Google , и используются в соответствии с условиями, описанными в Creative Commons 3.0 Attribution License . Эта статья была адаптирована из Get Started with Debugging JavaScript in Chrome DevTools от Kayce Basques.

Отключение кеша Chrome для разработки веб-сайта

Я изменяю внешний вид сайта (модификации CSS), но не вижу результата в Chrome из-за раздражающего постоянного кеша. Я попробовал Shift + обновить, но он не работает.

Как временно отключить кеш или обновить страницу каким-либо образом, чтобы увидеть изменения?

Chrome DevTools может отключить кэш.

  1. Щелкните правой кнопкой мыши и выберите Inspect Element , чтобы открыть DevTools. Или используйте одно из следующих сочетаний клавиш:
    • F12
    • Command + Option + i на Mac
    • Control + Shift + i в Windows или Linux
  2. Нажмите Network на панели инструментов, чтобы открыть панель сети.
  3. Установите флажок Disable cache вверху.

Имейте в виду, что, как указано в твите из @ChromiumDev, этот параметр активен только тогда, когда открытые устройства являются.

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

Если вы не хотите использовать флажок Disable cache , длительное нажатие на кнопку обновления с открытым DevTools покажет меню с параметрами Hard Reload или Empty Cache and Hard Reload , которое должно иметь аналогичное эффект. Читайте о разнице между вариантами. Доступны следующие ярлыки:

  • Command + Option + R на Mac
  • Control + Shift + R в Windows или Linux

Очистка кеша слишком раздражает, когда нужно очищать кеш 30 раз в час. поэтому я установил расширение Chrome под названием Classic Cache Killer, которое очищает кеш при каждой загрузке страницы.

Теперь мой макет json, javascript, css, html и data обновляется каждый раз при каждой загрузке страницы.

Мне никогда не придется беспокоиться, если мне нужно очистить кэш.

Я нашел около 20 очистителей кеша для Chrome, но этот казался легким и не требующим усилий. В обновлении Cache Killer теперь может оставаться «всегда включенным».

Примечание: я не знаю автора плагина. Я просто нашел это полезным.

Лучшие практики кэширования

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

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

Паттерн №1: неизменяемый контент и долгий max-age кэша

  • Содержимое по URL не меняется, следовательно…
  • Браузер или CDN могут без проблем закэшировать ресурс на год
  • Закэшированный контент, который младше, чем заданный max-age может использоваться без консультации с сервером

Страница : Эй, мне нужны «/script-v1.js» , «/styles-v1.css» и «/cats-v1.jpg» 10:24

Кэш : У меня пусто, как насчет тебя, Сервер? 10:24

Сервер : ОК, вот они. Кстати, Кэш, их стоит использовать в течение года, не больше. 10:25


Страница : Ура! 10:25

Страница : Эй, мне нужны «/script-v2.js» , «/styles-v2.css» и «/cats-v1.jpg» 08:14

Кэш : Картинка с котиками есть, остального нет. Сервер? 08:14

Сервер : Легко — вот новые CSS & JS. Еще раз, Кэш: их срок годности не больше года. 08:15

Кэш : Супер! 08:15

Страница : Спасибо! 08:15

Кэш : Хм, я не пользовался «/script-v1.js» & «/styles-v1.css» достаточно долго. Пора их удалять. 12:32

Используя этот паттерн, вы никогда не меняете контент определенного URL, вы меняете сам URL:

В каждом URL есть что-то, меняющееся одновременно с контентом. Это может быть номер версии, модифицированная дата или хэш контента (этот вариант я и выбрал для своего блога).

В большинстве серверных фреймворков есть инструменты, позволяющие с легкостью делать подобные вещи (в Django я использую Manifest​Static​Files​Storage); есть также совсем небольшие библиотеки в Node.js, решающие те же задачи, например, gulp-rev.

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

Паттерн №2: изменяемый контент, всегда проходящий ревалидацию на сервере

  • Содержимое URL изменится, значит…
  • Любая локальная закэшированная версия не может использоваться без указания сервера.

Страница : Эй, мне нужно содержимое «/about/» и «/sw.js» 11:32

Кэш : Ничем не могу помочь. Сервер? 11:32

Сервер : Есть такие. Кэш, держи их при себе, но перед использованием спрашивай у меня. 11:33

Кэш : Так точно! 11:33

Страница : Спс! 11:33

На следующий день

Страница : Эй, мне опять нужно содержимое «/about/» и «/sw.js» 09:46

Кэш : Минутку. Сервер, с моими копиями все в порядке? Копия «/about/» лежит с понедельника, а «/sw.js» вчерашняя. 09:46

Сервер : «/sw.js» не менялась… 09:47

Кэш : Круто. Страница, держи «/sw.js» . 09:47

Сервер : …но «/about/» у меня новой версии. Кэш, держи ее, но как и в прошлый раз, не забудь сначала спросить меня. 09:47

Кэш : Понял! 09:47

Страница : Отлично! 09:47

Примечание: no-cache не значит “не кэшировать”, это значит “проверять” (или ревалидировать) закэшированный ресурс у сервера. А не кэшировать совсем браузеру приказывает no-store . Также и must-revalidate означает не обязательную ревалидацию, а то, что закэшированный ресурс используется только, если он младше, чем заданный max-age , и только в ином случае он ревалидируется. Вот так все запущено с ключевыми словами для кэширования.

В этом паттерне мы можете добавить к ответу ETag (идентификатор версии на ваш выбор) или заголовок Last-Modified . При следующем запросе содержимого со стороны клиента, выводится If-None-Match или If-Modified-Since соответственно, позволяя серверу сказать “Используй то, что у тебя есть, твой кэш актуален”, то есть вернуть HTTP 304.

Если отправка ETag / Last-Modified невозможна, сервер всегда отсылает содержимое полностью.

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

Это не редкость, когда у нас нет инфраструктуры для первого паттерна, но точно также могут возникнуть проблемы с сетевыми запросами в паттерне 2. В итоге используется промежуточный вариант: короткий max-age и изменяемый контент. Это плохой компромисс.

Использование max-age с изменяемым контентом это, как правило, неправильный выбор

И, к сожалению, он распространен, в качестве примера можно привести Github pages.

С серверным заголовком:

  • Содержимое URL меняется
  • Если в браузере есть кэшированная версия свежее 10 минут, она используется без консультации с сервером
  • Если такого кэша нет, используется запрос к сети, по возможности с If- Modified-Since или If-None-Match

Страница : Эй, мне нужны «/article/» , «/script.js» и «/styles.css» 10:21

Кэш : У меня ничего нет, как у тебя, Сервер? 10:21

Сервер : Без проблем, вот они. Но запомни, Кэш: их можно использовать в течение ближайших 10 минут. 10:22

Страница : Спс! 10:22

6 minutes later

Страница : Эй, мне опять нужны «/article/» , «/script.js» и «/styles.css» 10:28

Кэш : Упс, я извиняюсь, но я потерял «/styles.css» , но все остальное у меня есть, держи. Сервер, можешь подогнать мне «/styles.css» ? 10:28

Сервер : Легко, он уже изменился с тех пор, как ты в прошлый раз забирал его. Ближайшие 10 минут можешь смело его использовать. 10:29

Кэш : Без проблем. 10:29

Страница : Спасибо! Но, кажется, что-то пошло не так! Все поломалось! Что, вообще, происходит? 10:29

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

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

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

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

К счастью, у пользователей есть запасной выход…

Обновление страницы иногда спасает

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

Сервис-воркер может продлить жизнь этих багов

Например, у вас есть такой сервис-воркер:

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

Если мы меняем CSS/JS, мы также увеличиваем номер version , что инициирует обновление. Однако, так как addAll обращается сначала к кэшу, мы можем попасть в состояние гонки из-за max-age и несоответствующих версий CSS & JS.

После того как они закэшированы, у нас будут несовместимые CSS & JS до следующего обновления сервис-воркера — и это если мы опять не попадем при обновлении в состояние гонки.

Вы можете пропустить кэширование в сервис-воркере:

К сожалению, опции для кэширования не поддерживаются в Chrome/Opera и только-только добавлены в ночную сборку Firefox, но вы можете сделать это самостоятельно:

В этом примере, я сбрасываю кэш с помощью случайного числа, но вы можете пойти дальше и добавлять хэш контента при сборке (это похоже на то, что делает sw-precache). Это своего рода реализация первого паттерна с помощью JavaScript, но работающая только с сервис-воркером, а не браузерами и CDN.

Сервис-воркеры и HTTP-кэш отлично работают вместе, не заставляйте их воевать!

Как видите, вы можете обойти ошибки с кэшированием в вашем сервис-воркере, но правильней будет решить корень проблемы. Правильная настройка кэширования не только облегчает работу сервис-воркера, но и помогает браузерам, не поддерживающим сервис-воркеры (Safari, IE/Edge), а также позволяет вам извлечь максимум из вашей CDN.

Правильные заголовки кэширования также могут значительно упростить обновление сервис-воркера.

Здесь я закэшировал корневую страницу с паттерном №2 (серверная ревалидация) и все остальные ресурсы с паттерном №1 (неизменяемый контент). Каждое обновление сервис-воркера будет вызывать запрос к корневой странице, а все остальные ресурсы будут загружаться только, если их URL изменился. Это хорошо тем, что сохраняет трафик и улучшает производительность, независимо от того, обновляетесь ли вы с предыдущей или очень старой версии.

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

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

При аккуратном использовании max-age и изменяемый контент могут быть очень хороши

max-age очень часто бывает неправильным выбором для изменяемого контента, но не всегда. Например, у оригинала статьи max-age составляет три минуты. Состояние гонки не является проблемой, так как на странице нет зависимостей, использующих одинаковый паттерн кэширования ( CSS, JS & изображения используют паттерн №1 — неизменяемый контент), все остальное этот паттерн не использует.

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

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

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

Отладка скриптов в браузере Chrome

Отладка скриптов в браузере Chrome

Здравствуйте! В продолжении темы обработки ошибок в JavaScript поговорим об отладке скриптов силами браузера. Для примера возьмем самый лучший браузер на Земле — Chrome.

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

Общий вид панели Sources

Запустите браузер Chrome.

Нажмите F12, при этом запустятся Инструменты разработчика.

Перейдите на вкладку Source

Здесь можно выделить 3 зоны:

  1. Область исходных файлов. В ней находятся все файлы проекта
  2. Область текста. В этой области находятся текст файла
  3. Область информации и контроля. О ней разговор пойдет позже

Как правило при отладке область исходных файлов не нужна, поэтому ее можно скрыть кнопкой.

Общие кнопки управления

3 наиболее часто используемые кнопки управления:

Формат Эта кнопка позволяет отформатировать код. Может вам понадобиться, если вы желаете отформатировать чужой код. Консоль Очень важная кнопка по нажатию на которой открывается консоль. В консоли можно вводить различные команды и операторы на JavaScript. Окно В случае с большим участком кода позволяет открыть код в отдельном окне.

Точки останова

Рассмотрим на примере файла pow.js. Если клацнуть на любой строке этого файла, то на этой строке будет задана точка останова.

Выглядеть это примерно так:

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

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

Информация о точке останова появляется на вкладке Breakpoints.

Вкладка Breakpoints очень полезна, когда код очень большой, она позволяет:

  • Быстро перейти на то место кода, где поставлен брейкпойнт простым кликом на текст.
  • Временно отключить точку останова кликом на чекбокс.
  • Быстро удалить точку останова правым кликом на текст и выбором Remove.
  • Точку останова можно инициировать и напрямую из а скрипта, командой debugger:
  • Правый клик на номере строки pow.js позволит вам создать так называемую условную точку останова (conditional breakpoint), т.е. задать условие, при котором точка останова сработает.

Остановиться и осмотреться

Поскольку наша функция выполняется одновременно с загрузкой страницы, то самый простой способ активировать отладчик JavaScript – это перезагрузить её. Для этого нажмите F5. И при этом выполнения скрипта будет остановлено на 6-й строке.

Обратите внимание на информационные вкладки:

  • Watch Expressions – здесь можно увидеть текущее значение переменных , которые вы отслеживаете в скрипте.
  • Call Stack – показывает стек вызовов — это все вызовы приведшие к этой строке кода.
  • Scope Variables – показывает переменные. Причем показывает как глобальные так и локальные переменные.

Управление выполнением

А теперь давайте «погоняем » скрипт и отследим его работу. Обратите внимание на панель сверху там находятся 6 кнопок работу которых мы и рассмотрим.

– продолжить выполнение, или можно нажать на клавишу F8. Эта кнопка продолжает выполнение скрипта. Таким образом мы можем пошагово проходить наш сценарий как будто он запускается в браузере. – сделать шаг, не заходя в функции, или клавиша F10.

Выполнить один шаг скрипта не заходя при этом внутрь функции.

– сделать шаг внутрь функции, клавиша F11. Выполняет один шаг скрипта и при этом заходит внутрь функции. – выполнять до выхода из текущей функции, клавиша Shift+F11.

выполняет полностью код, находящийся в функции.

– отключить/включить все точки останова. Эта кнопка просто отключает и при повторном нажатии включает все точки останова. – включить/отключить автоматическую остановку при ошибке. Данная кнопка весьма полезна при отладке и позволяет включать и отключать автоматическую остановку при ошибке.

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

Консоль браузера

При отладке кода скрипта бывает полезным перейти на вкладку Console и посмотреть нет ли там ошибок также можно выводить информацию в консоль с помощью console.log().

Консоль доступна в любом браузере

Ошибки в консоли

Ошибки JavaScript скриптов можно посмотреть в консоли.

В консоли вы можете увидеть:

Красная строка – это собственно сообщение об ошибке.

Если вы кликните на ссылке pow.js в консоли, справа в строке с ошибкой, то вы перейдете непосредственно к тому месту в скрипте, где эта ошибка произошла.

Итого

Отладчик вам позволяет:

  • Останавливаться на отмеченном месте (точка останова) или по команде debugger.
  • Выполнять код – отлаживать программу по одной строке или до определённого места.
  • Отслеживать переменные, выполнять команды в консоли и т.п.

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Добавить комментарий