Slow 3g chrome какая скорость

Обновлено: 25.01.2025

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

@pelms С моими это не помогает, Это не может сделать это достаточно медленно . Или попробуйте запустить соединение через прокси Tor Project .. @pelms оба ваших комментария предложения должны быть объединены в ответ. Я думаю, что они попадают в «быстрые и грязные» решения, которые, ну, всем нравятся :-)

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

МОДЕРАТОР РЕДАКТИРОВАТЬ 2013-02-02

Это расширение больше не доступно, но репозиторий создан на Github .

Похоже, что расширение Firefox Throttle больше не доступно.

Мне также нравится Charles Web Debugging Proxy , похожий инструмент. Чарльз также может регулировать скорость соединения . Чарльз - коммерческое программное обеспечение, но у него есть бесплатная пробная версия. Что мне больше всего нравится в Charles, так это то, что он кроссплатформенный : он основан на Java и может работать на Windows, Mac OS X и Linux. (Вы не упомянули, на какой платформе вы работаете, но, вероятно, это одна из них :-)

В Chrome вы можете открыть инструменты разработчика, щелкнуть значок устройства (1), а затем выбрать регулировку соединения (2).

Изменить (2015-11-03)

Начиная с Chrome 45, на самом деле стало немного проще: вам больше не нужно находиться в режиме устройства.

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

Вы можете замедлить определенные ресурсы с Deelay.me:

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

Хорошо знать такой сайт, но ОП хочет замедлить всю страницу, а не только активы .

Я предполагаю, что проблема та же самая, что и у меня. При внутренней разработке веб-проекта, работающего на серверах локальной сети или виртуальной машине, иногда требуется смоделировать реальный сценарий реального времени, как если бы нагрузка на сервер была высокой, чтобы увидеть, насколько быстро страница загружается на стороне клиента, и если некоторые данные, поступающие с сервера, фактически загружаются и не портят ваши клиентские функции из-за поведения сервера и задержек. Поскольку не существует идеального способа моделирования реальных сценариев, лучше всего убедиться, что вы запускаете события только после того, как данные полностью получены с сервера. Использование функции $ .ajax complete и async: false пока что помогает. Это гарантирует, что любое событие на основе данных, которое вам нужно запустить, не будет выполнено, если данные не существуют.

Имитация медленного подключения с использованием Chrome Если вы еще не установили его в своей системе, установите Chrome. Как только вы это сделаете, откройте новую вкладку и затем нажмите CTRL + SHIFT + I, чтобы открыть окно инструментов разработчика, или щелкните значок гамбургера, затем Дополнительные инструменты и затем Инструменты разработчика.

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

Теперь перейдите на вкладку Сеть. Справа вы должны увидеть ярлык под названием No Throttling.

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

Доступны варианты от Offline до WiFi, а номера отображаются как Latency, Download, Upload. Самым медленным является GPRS, за которым следуют Regular 2G, затем Good 2G, затем Regular 3G, Good 3G, Regular 4G, DSL и затем WiFi. Выберите один из вариантов, а затем перезагрузите страницу, на которой вы находитесь, или введите другой URL-адрес в адресной строке. Просто убедитесь, что вы находитесь на той же вкладке, где отображаются инструменты разработчика. Регулирование работает только для той вкладки, для которой он включен.

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

Всем, привет. Хочу поделиться своим проектом, который я делал в последние несколько месяцев. Это open-source инструмент командной строки, предназначенный для удобного сбора метрик производительности веб-сайта в различных сетевых (и не только) условиях.

Уже реализована эмуляция slow3g, fast3g, и 4g сетей, тестирование с браузерным кешированием или без, эмуляция замедления процессора. Собираются события первой и наибольшей отрисовки, время потраченное на построение макета и пересчет стилей, размер ресурсов загруженных до FCP и другие полезные метрики.

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

Зачем?

Когда появляется какой-то новый инструмент, вопрос номер один это — "Зачем?". Какую проблему ты пытаешься решить (кроме "потому что могу")?

Поэтому давайте начнем с проблемы. Был май, я пытался оптимизировать загрузку одного приложения на React.JS и, если честно, немного устал. Почему устал? Потому что на каждый чих мне надо было:

Выбрать параметры сети (например fast-3g)
Запустить профилирование
Записать результаты
Повторить все вышеперечисленное еще два раза, что бы вывести среднюю величину
Поменять параметры сети на новые
Повторить все вышеперечисленное еще раз
Отключить кэш
Повторить все вышеперечисленное еще раз

И так на каждую гипотезу. Понимаете, да? Одно изменение и минимум 12 запусков плюс подсчеты. Тяжело… Поэтому, пока я этим занимался, в голове крутилась мысль что было бы неплохо это как-то автоматизировать, но было не понятно как, да и времени было не много, нужно было катить:

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

А с тебя какая польза?

Хотя разработка еще не закончена (есть как минимум одна фича которой мне не хватает и один "может-быть-баг"), но вот что уже умеет Perfrunner

Эмулирование разных сетевых условий. Сейчас поддерживаются пять вариантов: online / regular4g / fast3g / hspa / slow3g . Параметры для них я честно нагуглил, так что я не уверен, что они 100% корректны. Если найдется кто-то более сведущий и поправит я буду очень благодарен.
Работа с кэшем или без. Т. е. можно эмулировать и первый заход пользователя и повторный.
Эмуляция замедления процессора для тестирования на более слабых устройствах. Кстати, чудесная штука. Если никогда не пробовали очень рекомендую поставить где-то на десятикратное замедление и понаблюдать как умирает React. Впрочем, Angular умирает точно так же.
Многократное тестирование. По умолчанию, (и в память о моих мучениях), Perfrunner запускает все тесты по 3 раза и агрегирует результат. Если нравится другое число, значение можно поменять с помощью флага --runs . Валидация выглядит как requiredPositiveInteger , так что, теоретически, можно выставить тысяч пять запусков и уйти пить кофе на целый день.

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

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

Теперь об отчетах. Вот что входит в текущую версию отчета:

first-contentful-paint, largest-contentful-pain, dom-interactive и еще чуть-чуть. Это нужно что бы понимать как быстро пользователь увидит что-то полезное или сможет взаимодействовать c сайтом.
layout duration, script duration, recalculate-style-duration. Это нужно что бы смотреть за счет чего у нас улучшаются (или не улучшаются) метрики из первого пункта.
Размер ресурсов, загруженных до FCP. Это нужно для понимания и контроля сколько ресурсов грузится во время критической секции загрузки.
Размер всех ресурсов, которые грузит сайт.
И метки производительности, если они есть.

Все это выводится в виде графиков (кликабельно):

Здесь показано как изменяются метрики после добавления jQuery в шапку страницы. Точно так же можно тестировать любые другие гипотезы, например влияние внедрения критического CSS в index.html для SPA приложений, использование директив preload и prefetch, lazy-loading и все остальное. Причем посмотреть можно не только как изменились метрики на вашем любимом 100мбит канале, но и, например, для slow-3g. Правда есть один нюанс, — для более-менее честной картины, ресурс желательно хостить удаленно, а не на localhost.

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

Как это все устроено?

На самом деле все довольно просто. Весь проект написан на TypeScript, код лежит в монорепозитории под управлением Lerna и разбит на 3 отдельных пакета – CLI, Reporters и Core

CLI обслуживает ввод-вывод и основан на command-line-args. Из интересного, именно здесь зашиты параметры сетевых условий, например вот так выглядят параметры для slow3g :

Reporters содержит логику по отображению данных. Здесь лежит код для генерации HTML, JSON и CSV отчетов. По умолчанию используется HTML отчет, но с помощью флага --reporter можно переключиться на JSON, CSV или даже подключить свой собственный, например вот так:

Ну и теперь про Core. Он основан на Puppeter и отвечает за запуск браузера, сбор метрик и их хранение. Причем, что любопытно, все строится примерно на следующем коде (если упростить):

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

Так, например, largest-contentfull-paint нельзя просто взять и вытянуть из performance.getEntries() , его там попросту нет. Вместо этого мы должны подписаться на это событие и ждать пока оно прилетит. Что, для моих целей довольно плохо, потому что если на сайте нет JavaScript-а (как, например на моем блоге, на котором я тестировал), то, внезапно, он в метриках все равно появится. Но, увы, тут или метрику выбрасывать или оверхед терпеть, другого решения я не нашел. Так же пришлось добавить обработку трейсов браузера. Это понадобилось чтобы достать оттуда типы ресурсов (mimetype) и размер переданных по сети файлов (и вообще там много интересного, очень рекомендую покурить трейсы на досуге).

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

Еще был «веселый» случай, который почти свел меня с ума часа на три. В случайном порядке, один из запусков, иногда, выдавал цифры в два раза хуже, чем остальные тесты (причем уже после прогрева). Трейсы показывали аномально высокие значение TTFB, а именно Stalled часть, которая могла длиться 1200-1500ms. Проблема оказалось в использовании Proxy, которая почему-то включилась на Windows машине. Поседеть я не поседел, но wtf/sec зашкаливал.

Для тестирования я взял стандартную связку chai + mocha которые повешены на preversion и prepublish хук с помощью husky. Кроме этого, с помощью того же hasky и lint-staged, на prepush повешен prettier. Для CI/CD — традиционно взят Travis CI.

Content-Visiblity и как он влияет на сайт

А теперь давайте попробуем потестировать что-то действительно интересное. Наверное, вы уже в курсе, что в Chrome версии 85 появится новое, довольно любопытное, css правило — content-visibility. Если нет, то, упрощенно, оно позволяет отложить рендер той части сайта, которую пользователь на данный момент не видит. По идее это должно ускорить момент первой значимой отрисовки, но вот на сколько именно — это вопрос интересный. Попробуем замерить, сколько оно может сэкономить.

Для этого нам нужно запустить Canary версию Chrome вместо Puppeteer, и, на всякий случай, выключить headless режим. Perfrunner такие трюки позволяет.

И вот результат:

Network	Cache	FMP before (ms)	FMP after (ms)	Diff (ms)
slow-3g	false	4358	4267	91
slow-3g	true	2953	2857	96
fast-3g	false	421	329	92
fast-3g	true	221	122	99
regular-4g	false	316	223	93
regular-4g	true	221	123	98

Итого, от 90ms до 100ms экономии на моих несчастных 700 нодах (что не плохо) и CoreI7 процессоре. Для бюджетных смартфонов все должно быть еще лучше.

Если не работает

Если у вас не работает, ничего страшного. У меня тоже не работает не работало. Под капотом у Perfrunner-а стоит Puppeter у которого свои ограничения. Поэтому если возникли проблемы — вам сюда. В свою очередь, Perfrunner поддерживает --chrome-args , --ignore-default-args и, на худой конец, --executable-path флаги.

Итоги подведем (С).

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

На этом, собственно, все. Дополнительные настройки можно посмотреть в readme. Фидбек или багу оставить тут. Из следующих планов — поддержка perfrunner.config с кастомными настройками и списком страниц для запуска, рефакторинг и, наверное, commitizen.

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

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

Когда необходимо улучшить производительность, мы начинаем с аудита:

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

Подготовимся

Ваша версия может отличаться от этого руководства, так что некоторые функции могут выглядеть иначе или быть недоступными. У нас с Тони, например, это версия 80.0, а свою вы можете узнать, набрав в адресной строке chrome://version/ . Ничего страшного – просто имейте в виду, что ваш пользовательский интерфейс может отличаться от приведённых снимков. Сама методология давно укоренилась, так что она вряд ли поменятся в один миг.

Рис. 2. Вкладка редактора

Нажмите tony . Появится меню.

Рис. 3. Меню, которое появляется после нажатия tony

Кликните Remix Project . Название проекта сменится на случайно сгенерированное имя. Создалась редактируемая копия кода, В этот код позже мы внесём изменения.

Нажмите Show , а затем – In a New Window . В новой вкладке откроется демо. Эту вкладку мы будем именовать демонстрационной. Загрузка сайта займёт некоторое время – поклонники Тони не зря жаловались.

Рис. 4. Демонстрационная вкладка

Нажмите Ctrl+ Shift+J (Windows, Linux) или Cmd+Option+J (Mac). Вместе с демо откроется Chrome DevTools.

Рис. 5. Демо-страница и открытая панель DevTools

Определим базис

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

Рис. 6. Панель Audits

Выставим настройки для аудита, как на Рис. 6.

Device. Параметр Mobile изменяет описание пользовательского агента, имитируя мобильный экран. Выбор Desktop просто отключает эти настройки.

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

Кликаем Generate report . Через 10–30 секунд на панели Audits появится отчёт о работе сайта.

Рис. 7. Отчёт по результатам аудита сайта

Если в отчёте панели Audits появится ошибка, и в кружке рядом с Performance вы видите вместо числа знак вопроса, запустите демонстрационную вкладку в новом окне в режиме инкогнито. Процессу аудита часто мешают расширения Chrome.

Разбираемся в отчёте

Число в верхней части отчёта – общий показатель эффективности сайта. Для сайта Тони у вас наверняка получилось число 0. По мере внесения улучшений это число должно расти.

Рис. 8. Общий показатель эффективности и раздел Metrics

В разделе Metrics представлены количественные показатели производительности сайта. Каждый параметр отвечает за определённый аспект производительности. Например, First Contentful Paint сообщает, через какое время контент начал отображаться на экране – важный параметр для восприятия пользователем загрузки страницы. Time to Interactive отмечает точку, когда страница стала достаточно готова, чтобы с ней можно было взаимодействовать. Развёрнутое описание каждой метрики можно получить при нажатии переключателя списков.

После метрик идёт лента скриншотов, показывающих как страница выглядела в процессе загрузки.

Рис. 9. Панель скриншотов почти пуста – большую часть времени загрузки на сайте ничего не отображалось

Раздел Opportunities (англ. «возможности») содержит советы о том, как улучшить загрузку сайта и связанный с ней код. Каждый совет можно раскрыть, нажать Learn more и прочитать документацию на web.dev о том, почему это важно.

Рис. 12. Раздел Passed audits

Как ни странно, иногда этот раздел может работать некорректно, так что и эти пункты нужно внимательно рассмотреть. Например, мы скоро увидим, что сайт Тони не сжимает текст ( enable text compression ) и использует слишком большие изображения ( properly size images )

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

Сжатие текста

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

Рис. 15. Внешний вид редактора после вставки

Некоторая время займёт перестройка структуры сайта. Перезагрузите демонстрационную страницу. В столбце Size теперь будут отображаться два различных значения для текстовых ресурсов. Например, bundle.js сжимается до 256 Кб.

Рис. 17. Показатель производительности вырос с 0 до 10 после сжатия

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

Изменение размера изображений

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

Вернёмся на вкладку редактора, откроем src/model.js и заменим const dir = 'big' на const dir = 'small' . Этот каталог содержит копии тех же изображений, размер которых был изменен. После обновления страницы повторим процедуру аудита.

Рис. 18. Показатель производительности вырос с 10 до 12 после оптимизации изображений

Похоже, что изменение имеет незначительное влияние на общую производительность. Тем не менее вы сохраняете травфик пользователей. Общий размер старых фотографий составлял около 5,3 Мб, а сейчас всего лишь около 0,18 Мб.

Устранение ресурсов, блокирующих загрузку сайта

Среди главных замечаний в отчете значится Eliminate render-blocking resources (устранить ресурсы, блокирующие рендеринг). Таким ресурсом, могут являться внешние файлы JavaScript и CSS, которые браузер должен загрузить, проанализировать и выполнить, прежде чем отобразить страницу.

Первая задача – найти код, который не нужно выполнять при загрузке страницы. Чтобы посмотреть блокирующие ресурсы, развернём в отчёте аудита указанный совет. Среди ресурсов видим lodah.js и jquery.js .

Рис. 19. Подробная информация о блокирующих ресурсах

Нажмём сочетание клавиш Ctrl+Shift+P (Windows, Linux) или Cmd+Option+P (Mac). В открывшемся меню команд начнём печать слово Coverage и выберем Show Coverage .

Рис. 20. Открытие командного меню для поиска команды

Нажимаем кнопку для перезагрузки страницы. Вкладка Coverage обеспечивает обзор того, как выполняется код в bundle.js , jquery.js и lodash.js во время загрузки страницы. На Рис. 21 показано, что около 74% jQuery и 30% Lodash не используются.

Рис. 21. Отчёт о покрытии (англ. coverage)

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

Вкладка Coverage помогает анализировать код построчно и отправлять только то, что необходимо для загрузки страницы. Давайте проверим, необходимы ли вообще файлы jquery.js и lodash.js . С помощью Ctrl+Shift+P (Windows, Linux) или Cmd+Option+P (Mac) добавим вкладку Request blocking (Show Request Blocking). На открывшейся панели нажмём кнопку Add pattern . Введём строку /libs/* , чтобы блокировать ресурсы из папки libs .

Рис. 23. Панель Network показывает, что запросы были заблокированы

При этом страница загружается и является интерактивной – похоже, отключенные ресурсы вообще не нужны!

Вкладка Request blocking полезна для имитации поведения страницы, когда какой-либо ресурс недоступен.

Удалим шаблон блокировки из Request blocking . Вернёмся на вкладку редактора и откроем template.html . Удалим строки <script src="https://proglib.io/libs/lodash.js"> и <script src="https://proglib.io/libs/jquery.js"></script> . Перезагрузим страницу и вновь проведём аудит.

Рис. 24. Результаты отчёта после удаления ссылок на ресурсы, блокирующие рендеринг

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

Если вы используете фреймворк, проверьте, есть ли у него production mode. Такой режим позволяет использовать функцию tree shaking, чтобы исключить ненужный код, блокирующий рендеринг.

Минимизируем работу в основном потоке браузера

Среди пунктов, отмеченных в Diagnostics , присутствует совет Minimize main thread work . Основной поток – это то, где браузер выполняет большую часть работы, необходимой для отображения страницы – анализ и выполнение HTML, CSS и JavaScript. Для анализа основного потока используется панель Performance .

Чтобы провести испытания в «полевых условиях», полезно имитировать устройства с медленным интернетом и аппаратными ограничениями. Для этого в настройках панели выставим в выпадающем списке Network Slow 3G, а в списке CPU 6x slowdown. Перезагрузим страницу для профилирования. DevTools отобразит развёртку загрузки страницы во времени – эта визуализация в DevTools носит название trace .

Рис. 25. Панель Performance отслеживает загрузку сайта

В trace показывается активность в хронологическом порядке слева направо. Диаграммы FPS, CPU и NET в верхней части дают обзор соответствующих видов активности. Жёлтые области показывают, когда процессор был полностью занят выполнением скрипта. Изучим внимательнее выделенную область – раскроем раздел Timings :

Рис. 27. Рост производительности при переходе на production mode

Однако что-то до сих пор сильно тормозит загрузку сайта. Вернёмся к разделу Perfromance . Свернём Timings и обратимся к разделу Main (его начало видно на Рис. 25). Здесь расположен хронологический журнал активностей основного потока с указанием причинно-следственных связей: событие Evaluate Script вызвало анонимную функцию, та вызвала _webpack_require__ и т. д. Прокрутим вниз к концу раздела Main .

Рис. 28. App делает множество вызовов к функции Bitcoin

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

В нижней части Performance нажмём на вкладку Bottom-Up . В этом разделе отображается информация о выделенном объекте. Например, если мы кликнем на одно из действий mineBitcoin , в разделе Bottom-Up отобразится информация для этого действия.

Рис. 29. Раздел Main и вкладка Bottom-Up в случае выбора Evaluate Script

Столбец Self Time показывает, сколько времени было потрачено непосредственно для каждого блока. Видно, что 87.4% времени уходит на работу с функцией mineBitcoin . Ох уж этот Тони!

Снизим активность JavaScript, удалив вызовы mineBitcoin . Перейдём в редакторе в src/App.jsx и закомментируем вызов this.mineBitcoin(1500) . Проведём заключительный аудит страницы.

Рис. 30. Отчёт после удаления лишних обращений JavaScript

Это последнее изменение вызвало огромный скачок в производительности!

Панель Performance – наиболее распространённый способ понять, какую активность выполняет сайт во время загрузки, и найти способы удалить ненужные действия. Если вы предпочитаете визуальному подходу логирование результатов, изучите User Timing API.

Отдельное спасибо от Тони

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

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

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

Исправления, которые стоит попробовать:

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

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

Исправление 1: закройте ненужные вкладки

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

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

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

Исправление 2. Отключите приложения и расширения Chrome, которые вам не нужны

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

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

Исправление 3. Включите службу прогнозирования в Chrome

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

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

Исправление 4. Удалите старые зависшие данные браузера.

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

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

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

Исправление 5: отключить аппаратное ускорение

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

Посмотрите, решена ли проблема с медленной скоростью Chrome. Если нет, попробуйте сбросить настройки браузера.

Исправление 6. Проверьте свой компьютер на наличие вредоносных программ в Chrome и сбросьте настройки браузера.

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

Чтобы проверить компьютер на наличие вредоносных программ в Chrome:

Чтобы сбросить настройки браузера:

Посмотрите, сохраняется ли эта досадная проблема. Если да, попробуйте обновить Chrome до последней версии.

Исправление 7. Обновите Chrome до последней версии.

Эта проблема может возникнуть, если ваш Chrome устарел. Поэтому попробуйте обновить Chrome до последней версии. Вот как это сделать:

Посмотрите, появится ли эта проблема снова. В противном случае вы устранили эту неприятную проблему.

Дополнительный совет: обновите сетевой драйвер

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

Обновить драйверы можно двумя способами: вручную и автоматически .

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

Или же

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

Вы можете автоматически обновлять драйверы с помощью Свобода или же версия Pro Driver Easy. Но с версией Pro требуется всего 2 клика (и вы получаете полную поддержку и 30-дневную гарантию возврата денег):

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

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