Woran erkenne ich langsame Geräte auf meiner Website?

Beim Anpassen einer Webseite für mobile Geräte verlasse ich mich immer auf CSS-Medienabfragen.

In letzter Zeit kümmere ich mich nicht mehr nur um die Bildschirmgröße, sondern auch um die Javascript-Engine vieler mobiler Geräte. Einige gängige JavaScript-Effekte, die auf Fensterrollen oder einer schnellen Folge von DOM-Transformationen beruhen, funktionieren auf langsamen Geräten sehr schlecht.

Gibt es eine Möglichkeit, die Geräteleistung zu erraten, damit ich Elemente aktivieren / deaktivieren kann, die auf langsamen Geräten schlecht aussehen?

Bisher kann ich mir nur schlechte Lösungen vorstellen:

Bildschirmgröße. schmaler Bildschirm "könnte" langsames Gerät bedeutenBenutzeragenteninformationen. Ich könnte mir das Gerät, den Browser oder die CPU ansehen, aber das scheint auf lange Sicht keine stabile Lösung zu sein, da viele Geräte in Betracht gezogen werden müssen

UPDATE: Meine Frage wurde korrigiert, um sich auf ein Problem zu konzentrieren. In den Kommentaren gibt es eine gute Lösung für das Touch-Interface-Problem.

 Basic15. Sept. 2012, 15:11
Sie können einige DOM-Operationen ausführen und zeitlich festlegen. Ich weiß, dass es nicht perfekt ist, und Sie müssen sicherstellen, dass es die Seite nicht übermäßig beeinflusst, aber es gibt Ihnen möglicherweise eine ziemlich genaue Vorstellung von der Geschwindigkeit des Clients beim Bearbeiten von Elementen
 SystematicFrank15. Sept. 2012, 15:11
@gabe Ich habe die Frage aktualisiert, um sie allgemeiner zu gestalten. Schauen Sie sich den Abschnitt UPDATE an. Ihre Vorstellung von einem inversen Ansatz ist heute gut, aber in Zukunft wird es eine Kombination aus langsamen und furchtbar schnellen Mobilgeräten geben. Daher scheint es keine gute stabile langfristige Lösung zu sein.
 Gabe15. Sept. 2012, 14:54
Was machen Sie anders, wenn der Browser zu langsam ist?
 Gregor15. Sept. 2012, 14:56
Was halten Sie von einem inversen Ansatz: Schnelle Browser finden und Effekte für diese aktivieren - dies kann mithilfe einer Benutzeragentenabfrage in Webkit, Firefox und neueren Internet Explorern erfolgen.
 Matt Whipple15. Sept. 2012, 15:19
Dies betrifft die Hover-Frage:stackoverflow.com/questions/4643443/…
 SystematicFrank15. Sept. 2012, 14:59
@gabe Ich würde einige Elemente deaktivieren. Beispielsweise sehen die dynamischen Navigationsleisten, die beim Scrollen über die Kopfzeile angezeigt werden, fürchterlich aus. Auch Bildergalerien mit animierten Übergängen sind nicht flüssig, ich würde den Bildübergang deaktivieren.
 Basic15. Sept. 2012, 15:09
Nur eine Beobachtung, aber der native Android-Browser kann Hover-Ereignisse ausführen. Es scheint das Konzept eines unsichtbaren Mauszeigers zu haben, der sich an der letzten Berührungsposition befindet. Der Schwebeflug kann also simuliert werden, indem Sie ihn mit einem kleinen Ziehen berühren, um ein Klicken zu verhindern. Nicht ideal und schon gar nicht universell unterstützt, aber wissenswert

Antworten auf die Frage(3)

die mir in den Sinn kam, bestand darin, vor oder während der Verwendung der Effekte im Hintergrund einen Geschwindigkeitstest in JS durchzuführen. Dies sollte Geräte erfassen, die aufgrund ihrer Prozessorgeschwindigkeit langsam sind oder umgekehrt, und Geräte erfassen, die zeitgenau / schnell sind. Wenn die Geräte jedoch Optimierungen aufweisen, dh unterschiedliche Prozessoren zur Berechnung der grafischen Effekte verwenden, funktioniert dies nicht.

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);
}

Wenn Sie dies ausführen, wirkt sich dies natürlich auch auf die Geschwindigkeit des Geräts aus, sodass dies nicht die beste Lösung ist. In der Regel neige ich dazu, Animationen und andere überflüssige Dinge einfach zu deaktivieren, wenn der Bildschirm klein ist.

Ein weiterer Nachteil dieser Methode - die ich zuvor erlebt habe - ist, dass bestimmte Browser, die Umgebungen mit mehreren Registerkarten implementieren, setIntervals automatisch auf eine bestimmte Geschwindigkeit begrenzt werden, wenn die Registerkarte nicht angezeigt wird. Dies würde für diese Browser bedeuten, dass das Wegblättern ihre Erfahrung automatisch herabsetzt - es sei denn, diese auferlegte Geschwindigkeitsbegrenzung könnte auf irgendeine Weise erkannt werden.

 SystematicFrank15. Sept. 2012, 15:51
Ich mag Ihren Code, aber wie Sie sagten, hat er einige Nachteile. Ich bin auch nicht sehr davon überzeugt, Geschwindigkeitstests als guten Entwurfsansatz zu verwenden. Auf der anderen Seite scheint es keine gute Lösung zu geben :(
 Pebbl15. Sept. 2012, 20:35
Ja, keine Sorge, ich würde diesen Ansatz nicht selbst in der Produktion verwenden, ich experimentiere einfach gerne mit JS. Auf der anderen Seite haben Sie immer eine Alternative ... Sie können den Benutzer fragen oder zumindest eine Art von Steuerung anzeigen, die es ihm ermöglicht, die ausgefallenen Teile zu deaktivieren, wenn er sie nicht möchte. Ich kenne viele Benutzer, die die grafischen Extras auch bei der Desktop-Anzeige deaktivieren möchten.
Lösung für das Problem

als gäbe es keine besonders gute Lösung für dieses Problem (was Sinn machen würde, da diese Art von Dingen normalerweise die Art von Dingen sein soll, die versteckt sind). Ich denke, in jedem Fall ist es am besten, wenn Sie mit der UA-Erkennung beginnen und sich um die Plattformen kümmern, von denen bekannt ist, dass sie in die eine oder andere Kategorie fallen. Dann haben Sie 2 Möglichkeiten, sich flexibel an unbekannte / ungewisse Plattformen anzupassen:

Progressive Enhancement: Beginnen Sie mit einem reduzierten Test und laden Sie einen kleinen Leistungstest oder Tests, um die Geräteleistung zu messen, und laden Sie dann die Dateien für die entsprechenden Verbesserungen. Test wie bereits bereitgestellt oder bei:Überspringen Sie Code, wenn der Computer langsam ist

Graceful Degradation: Binden Sie die Funktionen, die für eine ungünstige UX bei langsameren Geräten in Frage kommen, in eine Funktion höherer Ordnung ein, die sie ersetzt, wenn sie bei der ersten Ausführung zu lange dauern. In diesem Fall würde ich es wahrscheinlich hinzufügenFunction.prototype Anschließend kann ein akzeptables Verzögerungsargument an die Funktionsdefinition angekettet werden. Nach dem ersten Aufruf wird die verstrichene Zeit gespeichert, und nach dem zweiten Aufruf wird die Funktion mit einem Fallback ausgetauscht, wenn die verstrichene Zeit abgelaufen ist. Wenn die abgelaufene Zeit akzeptabel ist, entfernen Sie den Profiling-Code, indem Sie die Standardfunktion austauschen. Ich müsste mich hinsetzen und Beispielcode ausarbeiten (vielleicht an diesem Wochenende). Dies könnte auch durch zusätzliche Argumente angepasst werden, z. B. das mehrfache Profilieren vor dem Tauschen.

Die erste Option ist wahrscheinlich die freundlichere, die zweite Option greift möglicherweise weniger in den vorhandenen Code ein. Cookies oder das Sammeln weiterer UA-Daten können auch dazu beitragen, das Profil nach dem Abrufen von Informationen fortzusetzen.

 Matt Whipple18. Sept. 2012, 14:16
Wenn Sie ein Codebeispiel wollten, könnte ich heute etwas schreiben.
 SystematicFrank18. Sept. 2012, 14:23
Keine Sorge, ich habe sehr klar, wie ich das umsetzen soll. Für mich ist es kompliziert, im Detail jeden Fall und wie man schnell genug reagiert, sonst muss der Benutzer mindestens einmal einen UI-Fehler erleben
 Matt Whipple18. Sept. 2012, 14:34
Das wäre einer der Nachteile, abhängig von den Verbesserungen der Benutzeroberfläche (und dem zuerst ausgelösten), kann es unmöglich sein, einen merklichen Sprung zu machen. Ich würde nur sagen, fügen Sie einfach eine Nachricht hinzu, die kurz von oben oder unten eingeblendet wird und so etwas wie "Einstellungen für Ihr Gerät optimieren" sagt, damit der Benutzer weiß, dass dies eine Funktion ist und nicht ein oder mehrere Fehler.
 SystematicFrank18. Sept. 2012, 09:30
Ich mag die Idee der würdevollen Degradierung, da ich glaube, dass ein "schweres" Widget selbst ein Geschwindigkeitstest sein kann. Ich fragte nach langsamen Geräten, als ich wirklich feststellen wollte, ob ein Widget im Client zu langsam lief. Das Problem bei anderen Geschwindigkeitstestlösungen ist, dass man nach Erhalt eines numerischen Ergebnisses einen Schwellenwert finden muss, der annehmbar ist oder nicht.

anspruchsvolle Berechnungen durch und messen Sie das Ergebnis. Wenn es langsamer ist als das Gerät, das Sie für das am langsamsten unterstützte Gerät halten, wechseln Sie zu einer weniger intensiven Version Ihrer Site.

Sie können auch einfach einen leicht zugänglichen Link erstellen, um zur einfacheren Site zu wechseln, wenn der Benutzer Leistungsprobleme hat.

Es ist keine gute Idee, die Bildschirmgröße zu ändern. Viele moderne Telefone verfügen über kleine Bildschirme mit schnellen Prozessoren.

 Pebbl15. Sept. 2012, 20:39
Die Bildschirmgröße zu ändern ist akzeptabel, wenn Sie lediglich den Abbau nicht notwendiger überflüssiger "Magie" in angemessener Weise vornehmen :) - aber für alles andere werden Sie die Benutzererfahrung beeinträchtigen, da sich Telefone und Tablets im Laufe der Zeit verbessern.

Ihre Antwort auf die Frage