Как включить throttling в браузере
Некоторые события в браузере происходят с очень высокой частотой. Количество событий при движении курсора, прокрутке страницы, изменении размеров окна браузера, зажатой клавиши и так далее может достигать 100 раз в секунду. Функции, вызываемые при такой частоте событий, создают большую нагрузку на браузер и производительность падает. Как оптимизировать данный процесс?
Ниже расположен элемент, при движении курсора на котором будет отображаться количество событий
Total Events - исходное количество событий при перемещении курсора
Throttle Events - количество событий при использовании функции throttle. Считаются события, которые происходят через каждые 100 миллисекунд. Остальные события игнорируются
Debounce Start Events - количество событий при использовании функции debounce. Считаются события, когда курсор начал перемещение и в течении 100 миллисекунд еще не закончил перемещаться. Остальные события игнорируются
Debounce End Events - количество событий при использовании функции debounce. Считаются события, когда курсор закончил перемещаться и после завершения перемещения прошло 100 миллисекунд. Остальные события игнорируются
После перемещения курсора на элементе выше, видим что количество событий при использовании функций throttle и debounce значительно сокращается, что даёт меньшую нагрузку на браузер и следовательно прирост производительности
Ниже рассмотрим код функций throttle и debounce
Код функций Throttle и Debounce
Основная задача функций throttle и debounce ограничивать количество вызовов других функций при высокой частоте событий (resize, scroll, keydown)
Throttle
Игнорирует вызовы передаваемой функции, пока между событиями (resize, scroll, keydown) не пройдет заданное время ожидания
Debounce
Игнорирует вызовы передаваемой функции, пока события (resize, scroll, keydown) продолжают повторяться в пределах заданного времени ожидания
Логика Throttle и Debounce
Разберем небольшой абстрактный пример
Предположим, на странице есть индикатор прокрутки. При прокрутке страницы вниз - ширина индикатора прокрутки увеличивается, при прокрутке вверх - уменьшается. За расчет и отображение ширины отвечает функция updateProgressbar()
Мы можем вызывать функцию updateProgressbar() при каждом событии прокрутки страницы, то есть до 100 раз в секунду, но данный подход сильно нагрузит браузер частыми расчетами
Можем ограничить количество вызовов функции updateProgressbar() при помощи функции throttle - функция updateProgressbar() будет вызываться один раз в секунду при прокрутке страницы. То есть при прокрутке страницы индикатор прокрутки будет обновлять ширину один раз в секунду
Можем ограничить количество вызовов функции updateProgressbar() при помощи функции debounce - функция updateProgressbar() будет вызываться один раз, спустя одну секунду после каждого окончания прокрутки страницы. То есть пользователь начал прокручивать страницу - ширина индикатора пока не обновляется. Как только пользователь закончил прокручивать страницу и прошла одна секунда ожидания, обновляем ширину индикатора
Можем ограничить количество вызовов функции updateProgressbar() при помощи функции debounce с дополнительным параметром немедленного вызова - функция updateProgressbar() будет вызываться один раз, как только пользователь начинает прокручивать страницу. То есть, как только пользователь начинает прокручивать страницу, ширина индикатора сразу же обновляется. Пользователь заканчивает прокрутку страницы, проходит секунда, и только когда пользователь снова начинает прокрутку страницы, ширина индикатора обновится
Последний пример имеет мало смысла на практике, главное понять логику, и что задача этих функций снизить нагрузку на браузер сокращая количество вызовов.
Применение Throttle и Debounce
Основные примеры использования:
Отслеживание прокрутки страницы - пример с индикатором прокрутки, чтобы уменьшить количество расчетов, применяем функцию throttle
Изменение размеров окна браузера - предположим, при изменении размеров окна браузера перерисовываются некоторые динамические элементы, что приводит к очень частым сложным расчетам, в данном случае можем использовать как throttle, так и debounce. Оптимизация при debounce будет значительней, так как вызов функции будет происходить только тогда, когда пользователь закончит менять размеры окна браузера, в то время как при throttle передаваемая функция будет срабатывать в процессе изменения размеров через заданное время ожидания
Сокращение количества ajax запросов - например, при вводе запроса в поле <input type="text"> используем функцию debounce с задержкой 200 миллисекунд - в таком случае запрос не будет отправляться на сервер после ввода каждой буквы, а будет отправлен один раз после того, как пользователь перестанет вводить запрос и пройдет 200 миллисекунд
Выбор функции зависит от задачи
Если нужно, чтобы функция при каком-либо действии (resize, scroll, keydown) выполнялась с определенной периодичностью, то используем throttle
Если необходим вызов функции по окончании какого-либо действия, то используем debounce
Если необходим вызов функции в начале какого-либо действия, то используем debounce с дополнительным параметром немедленного вызова
Итоги
Данная статья скорее информативная, хотя и постарался, как можно подробнее описать работу функций throttle и debounce и их применение
Первое время вы можете не до конца понимать логику самих функций throttle и debounce, но большим плюсом будет использование этих функций уже сейчас при разработке, так как это снижает нагрузку на браузер, а следовательно и на устройство пользователя
P.S. Интересно, а 5.0 ГГц у тебя получится взять? Или ты уже, наверно, не будешь даже пытаться? Для 5.0 ГГц нужно 1.32-1.35 вольта. а это нагрев до 95 градусов. В обычной нагрузке (от 20% до 90%) температура будет колебаться от 50 до 70 градусов, что, вообщем-то, не смертельно.
для интереса уже ставил 5ггц с напругой 1.3темпа больше,на постоянку думаю оставлю 4.8 Искусственный Интеллект (128711) Но на 1.3 вольта 5.0 ГГц стабильно держится, да? А температуры какие? Дело в том, что я хочу взять i7-3770K, пока есть возможность. Вот и интересуюсь.
Температура начала троттлинга индивидуальна для каждой модели процессора (возможно, с точностью до ревизии, сейчас не скажу) . Обозначается она Tj. Max, и по идее, ее можно посмотреть на сайте производителя, но не всегда эти характеристики легко отыскать) . Для большинства процессоров Intel она колеблется в диапазоне 95-105 градусов Цельсия.
Могу посоветовать скачать маленькую программку Core Temp - кроме температуры процессорных ядер, она показывает также температуру Tj.Max
Имеется в виду температура процессорных ядер, а не крышки. Температура крышки обозначается T. case, и на многих русскоязычных сайтах (в том числе на сайте НИКСа, например) приводится в характеристиках как якобы "критическая температура процессора". На самом деле ничего "критического" в ней нет, это просто неправильный перевод.
Это по самому термину T. case видно (case по английски крышка, корпус) .
Интересно, что температура крышки T. case никакими датчиками не регистрируется и нигде в данных мониторинга не приводится, то есть это значение бесполезно для практического использования, это просто цифра.
Далее, еще один интересный момент: мало кто знает, что датчики температуры ядер в процессорах Intel регистрируют именно разницу между текущей температурой ядра и температурой Tj.max. Отсюда расхождения в показаниях различных программ мониторинга температуры: они просто Tj.Max считают разную (чтобы вычислить реальную температуру, нужно от Tj.Max отнять показание датчика температуры в ядре процессора) .
У AMD совсем другой механизм, о них сейчас не говорим.
Так что можешь быть спокоен: троттлинг начнется не раньше, чем показания температуры в Аиде или в чем там еще достигнут 95-100 градусов.
Вот, только что заметил: у тебя на скрине прога RealTemp, тоже видно (Distance to Tj. Max), судя по ее показаниям, Tj. Max у тебя 105C, ну по крайней мере прога RealTemp так считает)
Network simulation helps developers or QAs simulate the performance of a website in different bandwidths like 2G, 3G, 4G, etc. This is extremely useful from a testing standpoint as testers get a sense of how the website loads and functions when accessed from different internet connections.
This article will demonstrate two methods, using which testers can simulate poor network conditions while testing websites in Chrome.
Note: For developers or QA engineers seeking to simulate poor network conditions across real mobile devices (for example, 4G network on iPhone 12 Mini or Samsung Galaxy S20), the second method will be more effective in deriving accurate results.
Method 1: Network Simulation Using Chrome DevTools
Chrome browser provides a network throttler in its DevTools. Developers or QAs can leverage this feature to analyze website performance in slower network profiles. However one must bear in mind that this is just a simulator and the results for a real device may vary up to some extent.
To use the network throttler in Chrome:
As the browser usually loads the page from the cache, users must select the Empty Cache And Hard Reload option. It forces the browser to load all the resources. This is helpful in examining how a first-time visitor experiences a webpage loading on slow 3G speed.
Check out this interesting article that explains how to test websites from different locations.
Method 2: Chrome Network Throttling on Real Devices Using BrowserStack Live
An accurate way of validating how web pages load in poor network connections is to test them on real browsers installed on devices. BrowserStack’s real device cloud enables developers and QAs to test their websites in real user conditions, including different internet bandwidths.
Instantly choose the desired Android or iOS device on which to simulate the network conditions. Simply sign up for free, navigate to the Live dashboard and choose the desired OS-device-browser combination. The image below represents a sample Live session on iPhone 12 Mini.
As shown above, the Google website is loaded over a 3G connection on a real iPhone 12 mini.
Developers or QAs can leverage the Throttle Network feature to test the website in multiple network profiles like Edge, 3G, 4G, etc. One can also add custom network profile values to test their websites as per specific requirements.
Throttling the network gives a better idea of how long a page takes to load on a particular mobile device when accessed in a specific network connection.
Moreover, it also helps developers or QAs to identify if there’s a scope for enhancing the experience for users accessing a site from slow bandwidths. Enhancements may include adding a progress bar or wait statements to avoid the frustration of page load delay among the users.
The demonstration above will help individual developers and QAs to perform network throttling for their websites. Besides, the second method will prove useful for those seeking to simulate different networks on real mobile devices while testing websites.
Читайте также: