Как я могу распознать медленные устройства на моем сайте?

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

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

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

Пока я могу думать только о плохих решениях:

screen size. narrow screen "might" mean slow device user agent information. I could look at the device, browser or cpu, but that does not seem a stable long term solution because of the amount of devices to consider

ОБНОВИТЬ: Исправлен мой вопрос, чтобы сосредоточиться на одной проблеме. В комментариях есть хорошее решение проблемы сенсорного интерфейса.

 Matt Whipple15 сент. 2012 г., 15:19
Это охватывает вопрос наведения:stackoverflow.com/questions/4643443/…
 Gregor15 сент. 2012 г., 14:56
Что вы думаете об обратном подходе: поиск быстрых браузеров и включение эффектов для них - это можно сделать с помощью запроса пользовательского агента в Webkit, Firefox и последних Internet Explorer.
 Gabe15 сент. 2012 г., 14:54
Что вы будете делать по-другому, если браузер работает слишком медленно?
 Basic15 сент. 2012 г., 15:09
Просто наблюдение, но родной Android-браузер может делать парящие события. Кажется, у него есть концепция невидимого курсора мыши, который находится в последнем месте прикосновения - поэтому можно смоделировать зависание, касаясь небольшим перетаскиванием, чтобы предотвратить щелчок. Не идеально и, конечно, не всегда поддерживается, но стоит знать
 SystematicFrank15 сент. 2012 г., 14:59
@gabe Я бы отключил некоторые элементы. Например, те динамические панели навигации, которые появляются, когда вы прокручиваете заголовок, выглядят ужасно. Также галереи изображений с анимированными переходами не являются плавными, я бы отключил переход изображений.

Ответы на вопрос(3)

Решение Вопроса

кажется, что не существует особенно хорошего решения для этой проблемы (что имеет смысл, поскольку обычно предполагается, что этот тип материала является тем типом материала, который скрыт). Я думаю, в любом случае лучше всего начинать с обнаружения UA, чтобы заботиться о тех платформах, о которых известно, что они попадают в ту или иную категорию. Тогда у вас есть 2 варианта гибкой адаптации к неизвестным / неопределенным платформам:

Progressive Enhancement: Start with a stripped down test and load a small performance test or tests to gauge the device performance and then load the files for the appropriate enhancements. Test such as already provided or at: Skip some code if the computer is slow

Graceful Degradation: Wrap those features that are candidates for causing unfavorable UX on slower devices in a higher order function that replaces them if they take too long on first execution. In this case I'd probably add it to Function.prototype and then allow an acceptable delay argument to be chained on to the function definition. After the first invocation store the time lapsed, and then on the second invocation if the time lapsed is over the delay swap out the function with a fallback. If the time elapsed is acceptable then remove the profiling code by swapping in the standard function. I'd need to sit down and work out sample code (maybe this weekend). This could also be adjusted by additional arguments such as to profile multiple times before swapping.

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

 18 сент. 2012 г., 14:16
Если бы вы хотели пример кода, я мог бы написать что-нибудь сегодня.
 18 сент. 2012 г., 14:34
Это может быть одним из недостатков, в зависимости от того, каковы улучшения пользовательского интерфейса (и каков первый запущенный вариант), возможно, не удастся обойтись одним заметным прыжком. Я просто скажу: просто добавьте сообщение, которое кратко вставляется сверху или снизу, что-то вроде "оптимизации настроек для вашего устройства". пользователь знает, что это особенность, а не одна или несколько ошибок.
 SystematicFrank18 сент. 2012 г., 09:30
Мне нравится идея постепенной деградации, так как я считаю, что "тяжелый" Виджет может сам по себе быть тестом скорости. Я спросил об обнаружении медленных устройств, когда я действительно хотел определить, работает ли какой-то виджет слишком медленно в клиенте. Проблема с другими решениями для скоростных испытаний заключается в том, что после получения числового результата необходимо найти порог того, что является приемлемым или нет.
 SystematicFrank18 сент. 2012 г., 14:23
не беспокойтесь, я очень четко понял, как это реализовать. Для меня это сложность деталей каждого случая и как реагировать достаточно быстро, в противном случае пользователь должен испытать хотя бы один раз сбой пользовательского интерфейса

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

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

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

 15 сент. 2012 г., 20:39
Imo, работающий с размером экрана, является приемлемым, если все, что вы делаете, это постепенное ухудшение не существенной лишней «магии». :) - но, да, во всем остальном вы будете мешать работе пользователей, поскольку телефоны и планшеты со временем улучшаются.

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

var speedtest = function(){
  /// record when we start
  var target = new Date().getTime(), count = 0, slow = 0;
  /// trigger a set interval to keep a constant eye on things
  var iid = setInterval(function(){
    /// get where we actually are in time
    var actual = new Date().getTime();
    /// calculate where we expect time to be
    target += 100;
    /// 100 value here would need to be tested to find the best sensitivity
    if ( (actual - target) > 100 ) {
      /// make sure we aren't firing on a one off slow down, wait until this
      /// has happened a few times in a row. 5 could be too much / too little.
      if ( (++slow) > 5 ) {
        /// finally if we are slow, stop the interval
        clearInterval(iid);
        /// and disable our fancy resource-hogging things
        turnOffFancyAnimations();
      }
    }
    else if ( slow > 0 ){
      /// decrease slow each time we pass a speedtest
      slow--;
    }
    /// update target to take into account browsers not being exactly accurate
    target = actual;
    /// use interval of 100, any lower than this might be unreliable
  },100);
}

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

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

 SystematicFrank15 сент. 2012 г., 15:51
Мне нравится ваш код, но, как вы сказали, у него есть некоторые недостатки. Кроме того, я не очень убежден в том, что тесты скорости должны быть хорошим подходом к проектированию С другой стороны, похоже, что хорошего решения не существует :(
 15 сент. 2012 г., 20:35
Да, не беспокойтесь, я бы сам не использовал этот подход в производстве, мне просто нравится экспериментировать с JS. С другой стороны, у вас всегда есть альтернатива ... Вы могли бы попросить пользователя или, по крайней мере, предоставить какой-то элемент управления, который позволил бы им отключить причудливые части, если они им не нужны. Я знаю многих пользователей, которые хотели бы отключить графические дополнения даже при просмотре на рабочем столе.

Ваш ответ на вопрос