Как лучше всего определить во время выполнения, если браузер слишком медленный, чтобы изящно обрабатывать сложные JavaScript / CSS? - PullRequest
27 голосов
/ 19 января 2011

Я согласен с идеей постепенного включения / отключения эффектов JavaScript (и CSS) на странице - в зависимости от того, насколько быстрым / медленным кажется браузер.

Я специально думаю о низком уровнемобильные устройства и старые настольные компьютеры - не только IE6: -)

Существуют ли какие-либо примеры такого рода действий?

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

Примечания:

  • Меня не интересует обнаружение браузера / ОС.
  • В данный момент меня не интересуют измерения пропускной способности - только производительность браузера / процессора.
  • Что может быть интересно измерить:
    • Базовый JavaScript
    • Манипуляция DOM
    • DOM / CSS рендеринг
  • Я бы хотел сделать это так, чтобы как можно меньше влиять на скорость рендеринга страницы.

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

[ Обновление : есть связанный вопрос, которыйЯ пропустил: Отключить функцию JavaScript в зависимости от производительности компьютера пользователя .Спасибо Андриоид !]

Ответы [ 6 ]

11 голосов
/ 19 января 2011

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

Для этого есть несколько причин, основные из которых:

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

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

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

Лучшее, что вы можете сделать, это либо

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

    или еще лучше

  2. Выберите, чтобы дать им то, что вы можете быть уверены, что большая часть вашей целевой аудитории сможет наслаждаться.

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

8 голосов
/ 19 января 2011

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

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

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

2 голосов
/ 19 января 2011

Посмотрите на некоторые тесты Google (защищенные авторским правом!) Для V8 :

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

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

1 голос
/ 08 января 2014

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

1 голос
/ 19 января 2011

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

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

0 голосов
/ 13 июня 2011

Некоторые идеи:

  • Установление временного ограничения на испытания представляется очевидным выбором.
  • Сохранение результатов теста в файле cookie также представляется очевидным.
  • Низкая производительность теста на тесте может приостановить дальнейшие сценарии
    • и запуск отображения неблокирующего пользовательского интерфейса подсказок (например, подсказок сохранения пароля, общих для современных веб-браузеров)
    • , который спрашивает пользователя, хотят ли они включить дальнейшие скриптовые эффекты, и сохраняет ответ в файле cookie.
    • пока пользователь не ответил на приглашение, затем периодически повторяйте тесты и автоматически принимайте запрос сценариев, если последовательные тесты заканчиваются быстрее, чем первый.
      .
  • О sidenote - Медленные скорости в сети также могут быть проверены
    • по времени загрузки внешних ресурсов (например, страниц с собственными файлами CSS или JavaScript)
    • и сравнение этого результата с результатами теста JavaScript.
    • это может быть полезно на сайтах, использующих множество эффектов XHR и / или интенсивное использование <img/> с.
      .
  • Кажется, что тесты рендеринга / манипулирования DOM сложно выполнить до того, как страница начала рендеринг, и, следовательно, могут вызвать весьма заметные задержки для всех пользователей.
...