Verbessern Sie die Antwortgeschwindigkeit des AJAX-Clients

Das Aufkommen von AJAX hat die Funktionsweise von Webanwendungs-Clients stark verändert. Es ermöglicht Benutzern, sich auf ihre Arbeit zu konzentrieren, ohne sich mit lästigen Seitenaktualisierungen herumschlagen zu müssen. Theoretisch kann die AJAX-Technologie die Wartezeit für Benutzervorgänge erheblich verkürzen und den Datenverkehr im Netzwerk einsparen. Dies ist jedoch nicht immer der Fall. Benutzer beschweren sich häufig darüber, dass die Reaktionsgeschwindigkeit von Systemen, die AJAX verwenden, verringert ist.
Der Autor beschäftigt sich seit vielen Jahren mit der AJAX-Forschung und -Entwicklung und war an der Entwicklung von Dorado beteiligt, einer relativ ausgereiften AJAX-Plattform in China. Nach der Erfahrung des Autors ist AJAX nicht die Ursache für dieses Ergebnis. Oft wird die Verringerung der Systemreaktionsgeschwindigkeit durch unangemessenes Schnittstellendesign und unzureichend effiziente Programmiergewohnheiten verursacht. Im Folgenden analysieren wir einige Aspekte, auf die während des AJAX-Entwicklungsprozesses geachtet werden muss.

 Richtiger Einsatz von Client-Programmierung und Remote-Prozeduraufrufen.
Die clientseitige Programmierung basiert hauptsächlich auf JavaScript. JavaScript ist eine interpretierte Programmiersprache und ihre Betriebseffizienz ist etwas geringer als die von Java. Gleichzeitig läuft JavaScript in einer streng eingeschränkten Umgebung wie dem Browser. Daher sollten Entwickler ein klares Verständnis davon haben, welche Logik auf der Clientseite ausgeführt werden kann.
Wie die clientseitige Programmierung in tatsächlichen Anwendungen eingesetzt werden sollte, hängt von der Erfahrung und dem Urteilsvermögen des Entwicklers ab. Viele Probleme hier können nur verstanden werden. Aufgrund des begrenzten Platzes fassen wir hier grob die folgenden Vorsichtsmaßnahmen zusammen:

 Vermeiden Sie die häufige Verwendung von Remote-Prozeduraufrufen so weit wie möglich, vermeiden Sie beispielsweise die Verwendung von Remote-Prozeduraufrufen in Schleifenkörpern.
 Wenn möglich, verwenden Sie den AJAX-Remoteprozeduraufruf (asynchroner Remoteprozeduraufruf).
 Vermeiden Sie es, schwere Datenoperationen auf der Clientseite zu platzieren. Zum Beispiel: große Stapel von Datenkopiervorgängen, Berechnungen, die einen großen Datendurchlauf erfordern usw.
 Verbessern Sie die Operationsmethode von DOM-Objekten.
Bei der clientseitigen Programmierung beanspruchen Vorgänge an DOM-Objekten häufig am ehesten CPU-Zeit. Bei der Bedienung von DOM-Objekten ist der Leistungsunterschied zwischen verschiedenen Programmiermethoden oft sehr groß.
Im Folgenden finden Sie drei Codeteile mit genau den gleichen Ergebnissen. Ihre Funktion besteht darin, eine 10x1000-Tabelle auf der Webseite zu erstellen. Allerdings sind ihre Laufgeschwindigkeiten sehr unterschiedlich.
/* Testcode 1 – Dauer: 41 Sekunden*/
var table = document.createElement("TABLE");
document.body.appendChild(table);
for(var i = 0; i < 1000; i++){
var row = table.insertRow(-1);
for(var j = 0; j < 10; j++){
var cell = objRow.insertCell(-1);
cell.innerText = "( " + i + " , " + j + " )";
}
}

/* Testcode 2 – Dauer: 7,6 Sekunden*/
var table = document.getElementById("TABLE");
document.body.appendChild(table);
var tbody = document.createElement("TBODY");
table.appendChild(tbody);
for(var i = 0; i < 1000; i++){
var row = document.createElement("TR");
tbody.appendChild(row);
for(var j = 0; j < 10; j++){
var cell = document.createElement("TD");
row.appendChild(cell);
cell.innerText = "( " + i + " , " + j + " )";
}
}

/* Testcode 3 – benötigte Zeit: 1,26 Sekunden*/
var tbody = document.createElement("TBODY");
for(var i = 0; i < 1000; i++){
var row = document.createElement("TR");
for(var j = 0; j < 10; j++){
var cell = document.createElement("TD");
cell.innerText = "( " + i + " , " + j + " )";
row.appendChild(cell);
}
tbody.appendChild(row);
}
var table = document.getElementById("TABLE");
table.appendChild(tbody);
document.body.appendChild(table);
Der Unterschied zwischen „Testcode 1“ und „Testcode 2“ besteht hier darin, dass beim Erstellen von Tabellenzellen unterschiedliche API-Methoden verwendet werden. Der Unterschied zwischen „Testcode 2“ und „Testcode 3“ liegt in der leicht unterschiedlichen Abarbeitungsreihenfolge.
Wir können einen so großen Leistungsunterschied zwischen „Testcode 1“ und „Testcode 2“ nicht analysieren. Derzeit ist bekannt, dass insertRow und insertCell tabellenspezifische APIs in DHTML sind und createElement und appendChild native APIs von W3C DOM sind. Ersteres sollte eine Kapselung des Letzteren sein. Allerdings können wir daraus nicht schließen, dass die native API des DOM immer besser ist als die objektspezifische API. Es wird empfohlen, einige grundlegende Leistungstests durchzuführen, wenn Sie eine API häufig aufrufen müssen.
Der Leistungsunterschied zwischen „Testcode 2“ und „Testcode 3“ ergibt sich hauptsächlich aus der unterschiedlichen Build-Reihenfolge. Der Ansatz von „Testcode 2“ besteht darin, zuerst das äußerste