Ich plane, eine Website mit ungefähr 20 verschiedenen Ansichten / Seiten zu erstellen, die hauptsächlich für Mobiltelefone bestimmt sind.

Wenn ich mich darauf konzentrieren möchte, die Benutzererfahrung beim Wechseln zwischen den Seiten sehr reaktionsschnell (wie schnell) zu gestalten, ist es dann eine gute Idee, die Site als Einzelseitenanwendung zu erstellen?

Ich weiß, dass Sie viele Tipps tun können, um die Gesamtleistung einer mobilen Website zu steigern:

http://www.slideshare.net/blazeio/mobile-web-performance-optimization-tips-and-tricks

Mein Hauptanliegen ist jedoch, dass das clientseitige JavaScript (wie AngularJS) die Leistung tatsächlich verringert, wenn AJAX-Anforderungen ausgeführt und dann Elemente dynamisch angezeigt / ausgeblendet / erstellt werden müssen, verglichen mit der Erstellung einer herkömmlichen HTTP-Anforderung zum Abrufen einer Seite und seinen Inhalt und zeigt das direkt.

Gibt es Ressourcen oder Kommentare, die mir helfen könnten zu verstehen, welche Architektur für mobile Websites besser geeignet ist?

34
corgrath 27 Nov. 2013 im 03:03

4 Antworten

Der Wendepunkt für diese Entscheidung ist die Komplexität der Entwicklung. Normale Webserver-basierte Apps sind einfacher zu entwickeln, da es viel mehr Entwickler gibt, die alle Tricks kennen, wie eine solche Anwendung mit maximaler Effektivität ausgeführt werden kann. SPAs hingegen können in allen Bereichen eine bessere Leistung erzielen 1) schnellere Datenübertragung, 2) schnellere GUI-Operationen (DOM), 3) intelligentere UX, aber all dies erfordert erfahrenere (teurere) Entwickler, die es schnell und effizient machen können zuverlässig. Diese Entwickler sind weniger. Wenn Sie vorhaben, alles selbst zu tun, bedeutet dies eine längere Lernkurve für Sie und viel Versuch / Irrtum. Dies liegt hauptsächlich daran, dass SPAs im Vergleich zum regulären WWW neu sind.

Um ein effektives SPA zu erstellen, müssen Sie den Verbindungs- / Socket-Teil sehr gut kennen, die Engpässe kennen, wie Protokolle ausgewählt werden, welche Plattformen (Geräte) welche Verbindungsprotokolle unterstützen. Die Auswahl Ihrer bevorzugten Lösung ist nicht einfach: Engine, IO, Socket.IO, SockJS und andere.

Sie müssen die DOM-Manipulation in Bezug auf die dynamische Leistung sehr gut kennen, um mit Bedacht zwischen divs / tables / canvas wählen zu können.

Sie müssen die serverseitigen Funktionen zum Speichern von Daten effektiv nutzen, d. H. Cookies, Cache, lokale Datenspeichereinrichtungen (Dateien / Datenbank), um Daten während der Sitzung und zwischen den Sitzungen zu speichern.

JavaScript ist heutzutage unter iOS / Android sehr schnell, daher sollte die Geschwindigkeit der Sprache selbst sowieso kein Problem sein. Der große Vorteil ist die Verwendung von Node.js, sodass Sie sowohl auf der Client- als auch auf der Serverseite in derselben Sprache programmieren können. hashThisPassword() -Funktionen müssen nicht in zwei (oder mehr) Sprachen synchronisiert werden.

0
exebook 2 Dez. 2013 im 11:38

TL; DR: Ja, es ist machbar, aber Sie müssen diszipliniert sein und der Vorteil liegt in der Wahrnehmung der Leistung

Ich habe in den letzten Monaten daran gearbeitet, eine herkömmliche serverzentrierte "Desktop" -Webanwendung auf ein responsives SPA umzustellen. Insbesondere haben wir ein MV * -Design gewählt, das von einem Mediator-Router unterstützt wird, und ein entkoppeltes Abrufen mit AMD. Wir untersuchen die Verlagerung auf RVP.

Ich habe einige unserer Designprinzipien unten aufgeführt:

  • Entscheiden Sie frühzeitig, inwieweit Ihre Plattform eine progressive Verbesserung unterstützt. Weniger Skripte, die benötigt werden, desto besser. Wir verlassen uns auf unseren Erstellungsprozess, um sicherzustellen, dass wir dynamisch generiertes, aber statisch bereitgestelltes HTML und andere Inhalte unterstützen können
  • Erstellen Sie Ihre Toolchain frühzeitig (Minimierung, Bildverknappung oder Spriting usw.)
  • Entkoppeln Sie das Abrufen so weit wie möglich von Benutzeraktionen, indem Sie lokalen Speicher und Techniken wie das Vorabrufen oder das vorausschauende Abrufen verwenden.
  • Stellen Sie sicher, dass Sie messen, was Ihre Benutzer tun, damit Sie (sofern sinnvoll) schrittweise Anwendungslogik oder -inhalte abrufen können
  • Seien Sie sehr pingelig, welche Frameworks den Rest Ihrer Architektur unterstützen (anstatt sie zu diktieren).
  • Seien Sie sehr pingelig, welche Komponenten und Dienstprogramme von Drittanbietern Sie verwenden. Vermeiden Sie Frameworks, in denen Sie keinen wesentlichen Teil des Funktionsumfangs verwenden (alles, was Sie nicht verwenden, sind zusätzliche Kosten in Bezug auf Gewicht, Latenz, Verarbeitung auf dem Gerät usw.).

Möglicherweise ist dieser Framework-Vergleich hilfreich

2
Community 23 Mai 2017 im 12:09

Die akzeptierte Antwort ist sehr gut und ich stimme dem zu. Die neuesten Anwendungen, die ich entwickelt habe, wurden größtenteils mit SPA erstellt.

Ich möchte jedoch hinzufügen, dass SPA nicht für alle Anwendungen die magische Lösung ist, insbesondere wenn es um "Critical Path Rendering" geht.


Eine kurze Geschichte

Um eine schnelle "Zeit zum ersten Tweet" zu erreichen, wird die Verarbeitung eines Ganzen durchgeführt Framework wie AngularJS könnte ein Problem sein.

Wir haben erkannt, dass es mit Angular schwieriger sein wird, das zu erreichen, was der Kunde wollte. Also haben wir die Anwendung ohne sie erstellt. Die Anwendung nutzte AJAX-Anforderungen und andere Optimierungspraktiken in großem Umfang. Am Ende verkürzte sich die Zeit zum Rendern der Hauptseite um fast 1 Sekunde. In zwei Monaten nach der Bereitstellung konnte der Kunde eine Umsatzsteigerung von 30% verzeichnen! Ok, es war eine Anwendung mit einfachen Funktionen und hatte nicht den ganzen Reichtum, den ein SPA normalerweise hat.


0
fabriciorissetto 30 Sept. 2015 im 18:47

Es gibt zwei große Möglichkeiten, wie Sie auf der SPA-Route Möglichkeiten nutzen können, um die Benutzererfahrung zu verbessern:

Weniger heruntergeladene Inhalte

Wenn Sie für jede Seite in Ihrer Anwendung unterschiedliche HTML-Seiten haben, müssen Sie jede Seite vollständig herunterladen. Wenn Ihre Site ein gemeinsames Markup zwischen den Seiten aufweist, wird es für jede Seite erneut heruntergeladen. Vergleichen Sie dies mit einem SPA, in dem Sie zumindest nur die Änderungen herunterladen, die erforderlich sind, um von der aktuellen Seite zur nächsten zu gelangen. In einigen Fällen wird es kaum Verbesserungen geben, in anderen wird es ziemlich bedeutend sein.

Eine andere Möglichkeit, wie SPA effizienter sein kann, besteht darin, die Logik zum Erstellen des Markups und Ihrer Daten zu trennen. Betrachten Sie das Beispiel einer Liste mit 100 Namen und Partituren:

Traditionell:

<ul id="myList">
  <li><strong>Name 1</strong> score 1</li>
  <li><strong>Name 2</strong> score 2</li>
  <li><strong>Name 3</strong> score 3</li>
  ...
  <li><strong>Name 100</strong> score 100</li>
<ul>

SPA:

<ul id="myList"></ul>

var myData = { 
  "Name 1" : "score 1",
  "Name 2" : "score 2",
  "Name 3" : "score 3",
  ...  
  "Name 100" : "score 100"
}
var html = '';
for (var name in myData) {
  var html += '<li><strong>' + name + '</strong> ' + myData[name] + '</li>';
}
document.getElementById('myList').innerHTML = html;

Das SPA-Modell kann auch beim Erstellen des DOM Bytes speichern. Außerdem ist die Logik wiederverwendbar. Wenn Sie also die Liste mit mehr Inhalt neu erstellen müssen, müssen Sie einem Objekt nur Inhalte hinzufügen und eine Methode aufrufen.

Das perfekte Gleichgewicht zwischen Downloadgröße und erforderlicher Verarbeitung zu finden, ist ein sehr schwieriges Problem und hängt von vielen Problemen ab, einschließlich der Besonderheiten der Anwendung, des Geräts, anderer Tricks usw. Glücklicherweise liefert ein vernünftiger Ansatz ausreichend gute Ergebnisse meistens.

Übergänge

Abgesehen von einigen IE-Experimenten können Sie keine Änderungen an Übergängen zwischen verschiedenen Seiten im Browser vornehmen. Dies ist ein wichtiges Verkaufsargument für SPA, da Sie mit cleveren Übergängen den Anschein von Geschwindigkeit erwecken können, auch wenn die Website nicht so schnell ist. Auch ohne Übergänge ist ein SPA viel besser geeignet, um dem Benutzer beim Laden Feedback zu geben, als eine normale Site.

Eine Sache zu beachten ist, dass Sie sich auf das anfängliche Laden der Seite konzentrieren sollten, um so reibungslos wie möglich zu sein (indem Sie nur das Nötigste laden) und danach so viele Batch-Anforderungen wie möglich. Ein großes Problem bei der mobilen Latenz besteht darin, dass das Gerät ausgeschaltet wird, wenn es für eine Weile nicht verwendet werden muss. Das erneute Einschalten verursacht einen erheblichen Overhead. Daher sollten Anforderungen nach Möglichkeit gestapelt werden.


Mein persönlicher Rat ist, wenn Sie SPA gehen können, sollten Sie. Es gibt sehr wenig, was getan werden kann, um die Effizienz regulärer HTML-Sites zu verbessern, während ich vermute, dass SPAs in Zukunft ständig verbessert werden. Zumindest können Sie von einem sorgfältig erstellten SPA eine ähnliche Leistung erwarten wie bei normalem HTML, und die potenziellen Möglichkeiten können große Vorteile bringen.

5
Tibos 2 Dez. 2013 im 11:02