Informationen zur Leistung Ihre Webanwendung in IE11 und anderen Browsern

IEBlog Deutsch

Blog des Internet Explorer-Entwicklerteams

Informationen zur Leistung Ihre Webanwendung in IE11 und anderen Browsern

  • Comments 0

Die W3C Web Performance-Arbeitsgruppe hat gemeinsam mit Google, Mozilla und weiteren führenden Vertretern aus der Community die Schnittstellen Navigation Timing, Resource Timing, User Timing und Performance Timeline standardisiert, anhand derer Sie die Leistung Ihrer Webanwendung bezüglich Navigation, Ressourcenabruf und Skriptausführung beurteilen können. Mithilfe dieser Schnittstellen können Sie die Benutzererfahrung von Ihrer Webanwendung unter realen Bedingungen analysieren. So sind Sie nicht mehr auf synthetische Testverfahren angewiesen, die die Leistung der Anwendung in einer künstlichen Umgebung testen. Dank dieser Zeiterfassungsdaten können Sie Möglichkeiten identifizieren, um die Leistung Ihrer Webanwendung zu verbessern. Alle genannten Schnittstellen werden in IE11 unterstützt. Im Performance Timing Test Drive finden Sie eine Demo der Schnittstellen in Aktion.

Mit dem Performance Timing Test Drive können Sie die Timing-APIs testen.
Mit dem Performance Timing Test Drive können Sie die Timing-APIs testen.

Performance Timeline

Die Spezifikation Performance Timeline wurde als eine „W3C Recommendation“ veröffentlicht und wird in IE11 und Chrome 30 vollständig unterstützt. Wenn Sie diese Schnittstelle verwenden, erhalten Sie eine End-to-End-Ansicht der für die Navigation, das Abrufen von Ressourcen und das Ausführen von Skripten in Ihrer Anwendung benötigten Zeit. Die Spezifikation definiert sowohl die Mindestattribute, die bei allen Leistungsmetriken implementiert werden müssen, als auch die Schnittstellen, die Entwickler zum Aufrufen einer beliebigen Leistungsmetrik verwenden können.

Alle Leistungsmetriken müssen die folgenden vier Attribute unterstützen:

  • name. Dieses Attribut speichert einen eindeutigen Bezeichner für die Leistungsmetrik. Bei einer Ressource ist dies beispielsweise die aufgelöste URL der Ressource.
  • entryType. Dieses Attribut speichert den Typ der Leistungsmetrik. Beispielsweise wird eine Metrik für eine Ressource als „resource“ gespeichert.
  • startTime. Dieses Attribut speichert den ersten aufgezeichneten Zeitstempel der Leistungsmetrik.
  • duration. Dieses Attribut speichert die gesamte Dauer des Ereignisses, das von der Metrik aufgezeichnet wird.

Alle Zeiterfassungsdaten werden mit genauen Zeitwerten aufgezeichnet. Dafür wird Typ DOMHighResTimeStamps verwendet, der in der Spezifikation High Resolution Time definiert ist. Anders als beim Typ DOMTimeStamps, der Zeitwerte in Millisekunden ab dem 1. Januar 1970 UTC misst, erfolgt die Messung des „High Resolution Time“-Werts mindestens in Millisekunden ab dem Start der Dokumentnavigation. Wenn ich beispielsweise die aktuelle Zeit über performance.now() und „High Resolution Time“ entsprechend über Date.now() abrufe, wird folgende Interpretation der aktuellen Zeit ausgegeben:

> performance.now();

4038.2319370044793

 

> Date.now()

1386797626201

Dieser Zeitwert hat außerdem den Vorteil, dass er unabhängig von Abweichungen oder Anpassungen der Systemuhr ist. Im What Time Is It Test Drive wird die Verwendung von „High Resolution Time“ erläutert.

Sie können mit den folgenden Schnittstellen eine Liste der aufgezeichneten Leistungsmetriken zum Zeitpunkt des Aufrufs abrufen. Die Attribute „startTime“ und „duration“ sowie andere von der Metrik bereitgestellten Attribute bieten eine vollständige Zeitachsenansicht der Seitenleistung aus der Perspektive des Kunden.

PerformanceEntryList getEntries();

PerformanceEntryList getEntriesByType(DOMString entryType);

PerformanceEntryList getEntriesByName(DOMString name, optional DOMString entryType);

Die getEntries-Methode gibt eine Liste aller Leistungsmetriken auf der Seite zurück, die anderen Methoden geben je nach Name oder Typ bestimmte Elemente zurück. Wir gehen davon aus, dass die meisten Entwickler von der gesamten Liste an Metriken nur „JSON stringify“ verwenden und die Ergebnisse zur Analyse an die eigenen Server und nicht an den Client senden.

Betrachten wir nun jede dieser Leistungsmetriken etwas genauer: Navigation, Ressource, Markierungen und Messungen.

Navigation Timing

Die Schnittstelle „Navigation Timing“ stellt präzise Zeitmessungen für sämtliche Navigationsphasen auf Ihrer Webanwendung bereit. Die Spezifikation Navigation Timing L1 wurde als eine „W3C Recommendation“ veröffentlicht und wird in Browserversionen ab IE9, Chrome 28 und Firefox 23 vollständig unterstützt. Die Spezifikation Navigation Timing L2 ist ein erster veröffentlichter Entwurf und wird von IE11 unterstützt.

Entwickler können mit „Navigation Timing“ nicht nur die präzise und vollständige Ladezeit einer Seite, einschließlich der zum Abrufen der Seite vom Server benötigen Zeit, erfassen. Sie erhalten auch eine detaillierte Aufschlüsselung über die Dauer der verschiedenen Prozesse der Netzwerk- und DOM-Verarbeitungsphasen: Entladen, Umleiten, App-Cache, DNS, TCP, Anforderung, Antwort, DOM-Verarbeitung und Load-Ereignis. Im folgenden Skript werden über „Navigation Timing L2“ ausführliche Informationen abgerufen. Der Eintragstyp für die Metrik ist „navigation“, und der Name ist „document“. Sehen Sie sich eine Demo von „Navigation Timing“ auf der IE Test Drive-Website an.

<!DOCTYPE html>

<html>

<head></head>

<body>

<script>

 function sendNavigationTiming() {

   var nt = performance.getEntriesByType('navigation')[0];

   var navigation = ' Start Time: ' + nt.startTime + 'ms';

   navigation += ' Duration: ' + nt.duration + 'ms';

   navigation += ' Unload: ' + (nt.unloadEventEnd - nt.unloadEventStart) + 'ms';

   navigation += ' Redirect: ' + (nt.redirectEnd - nt.redirectStart) + 'ms';

   navigation += ' App Cache: ' + (nt. domainLookupStart - nt.fetchStart) + 'ms';

   navigation += ' DNS: ' + (nt.domainLookupEnd - nt.domainLookupStart) + 'ms';

   navigation += ' TCP: ' + (nt.connectEnd - nt.connectStart) + 'ms';

   navigation += ' Request: ' + (nt.responseStart - nt.requestStart) + 'ms';

   navigation += ' Response: ' + (nt.responseEnd - nt.responseStart) + 'ms';

   navigation += ' Processing: ' + (nt.domComplete - nt.domLoading) + 'ms';

   navigation += ' Load Event: ' + (nt.loadEventEnd - nt.loadEventStart) + 'ms';

   sendAnalytics(navigation);

 }

</script>

</body>

</html>

Durch Analyse der präzisen Dauer jeder Netzwerkphase können Sie Leistungsprobleme besser diagnostizieren und beheben. Beispielsweise können Sie sich bei einer langen Umleitungsdauer gegen eine Umleitung entscheiden, bei langen DNS-Zeiten einen DNS-Cache-Dienst verwenden, bei zu langen Anforderungszeiten ein CDN näher an der Benutzerseite verwenden oder bei zu langen Antwortzeiten GZip für Ihre Inhalte nutzen. In diesem Video finden Sie Tipps und Tricks zur Verbesserung Ihrer Netzwerkleistung.

Der Hauptunterschied zwischen den beiden Spezifikationsversionen von „Navigation Timing“ liegt in der Art des Zugriffs auf Zeiterfassungsdaten und in der Art der Zeitmessung. Die L1-Schnittstelle definiert diese Attribute im performance.timing-Objekt und in Millisekunden ab dem 1. Januar 1970. Mit der L2-Schnittstelle können die gleichen Attribute mithilfe der „Performance Timeline“-Methoden abgerufen werden, sodass sie einfacher in eine Zeitachsenansicht integriert und mit „High Resolution“-Timern aufgezeichnet werden können.

Normalerweise messen Entwickler vor der Navigationszeit zunächst die Seitenladezeit. Hierbei wird, wie im folgenden Codebeispiel aufgeführt, JavaScript in den Dokumentenkopf geschrieben. Sehen Sie sich eine Demo dieser Methode auf der IE Test Drive-Website an.

<!DOCTYPE html>

<html>

<head>

<script>

    var start = Date.now();

 

    function sendPageLoad() {

        var now = Date.now();

        var latency = now - start;

        sendAnalytics('Page Load Time: ' + latency);

    }

 

</script>

</head>

<body onload='sendPageLoad()'>

</body>

</html>

Mit dieser Methode wird die Seitenladezeit jedoch nicht präzise gemessen, da die Zeit zum Abrufen der Seite vom Server nicht berücksichtigt wird. Außerdem verschlechtert das Ausführen von JavaScript im Dokumentenkopf in der Regel die Leistung.

Resource Timing

„Resource Timing“ stellt präzise Timing-Informationen zum Abrufen von Ressourcen auf der Seite bereit. Ähnlich wie „Navigation Timing“ bietet „Resource Timing“ detaillierte Informationen über folgende Phasen der abgerufenen Ressourcen: Umleiten, DNS, TCP, Anforderung und Antwort. Die Spezifikation „Resource Timing“ wurde als eine „Candidate Recommendation“ des W3C mit Unterstützung für Versionen ab IE10 und Chrome 30 veröffentlicht.

Im folgenden Beispielcode wird die getEntriesByType-Methode verwendet, um sämtliche vom <img>-Element eingeleiteten Ressourcen zu erhalten. Der Eintragstyp für Ressourcen ist „resource“, und der Name ist die aufgelöste URL der Ressource. Sehen Sie sich eine Demo von „Resource Timing“ auf der IE Test Drive-Website an.

<!DOCTYPE html>

<html>

  <head>

  </head>

  <body onload='sendResourceTiming()'>

    <img src='http://some-server/image1.png'>

    <img src='http://some-server/image2.png'>

 

    <script>

        function sendResourceTiming()

        {

            var resourceList = window.performance.getEntriesByType('resource');

            for (i = 0; i < resourceList.length; i++)

            {

                if (resourceList[i].initiatorType == 'img')

                {

                    sendAnalytics('Image Fetch Time: ' + resourceList[i].duration);

                }

            }

        }

    </script>

  </body>

</html>

Aus Sicherheitsgründen wird bei ursprungsübergreifenden Ressourcen nur die Startzeit und Dauer angezeigt. Die ausführlichen Timing-Attribute werden auf Null gesetzt. So werden Probleme in Zusammenhang mit einem statistischen Fingerabdruck vermieden, durch die Ihre Mitgliedschaft in einer Organisation über die Netzwerkzeiten einer im Cache gespeicherten Ressource ermittelt werden könnte. Der ursprungsübergreifende Server kann den timing-allow-origin-HTTP-Header senden, wenn die Freigabe von Zeiterfassungsdaten erlaubt ist.

User Timing

„User Timing“ stellt ausführliche Timing-Informationen über das Ausführen von Skripten in Ihrer Anwendung bereit. Die Methode ist eine Ergänzung zu „Navigation Timing“ und „Resource Timing“, die ausführliche Netzwerkzeitinformationen bieten. Mithilfe von „User Timing“ können Sie ausführliche Informationen zum Skript-Timing in der gleichen Zeitachsenansicht anzeigen, die Sie für die Zeiterfassungsdaten Ihres Netzwerks verwenden. So erhalten Sie vollständige Leistungsinformationen über Ihre App. Die Spezifikation User Timing wurde als „W3C Recommendation“ veröffentlicht und wird ab IE10 und Chrome 30 unterstützt.

Die „User Timing“-Schnittstelle definiert zwei Metriken für die Messung von Skript-Timing: Markierungen und Messungen. Eine Markierung ist ein genauer Zeitstempel zu einem bestimmten Zeitpunkt innerhalb der Skriptausführung. Eine Messung ist der Unterschied zwischen zwei Markierungen.

Zum Erstellen von Markierungen und Messungen können die folgenden Methoden verwendet werden:

void mark(DOMString markName);

void measure(DOMString measureName, optional DOMString startMark, optional DOMString endMark);

Wenn Sie dem Skript Markierungen und Messungen hinzugefügt haben, können Sie die Zeiterfassungsdaten mithilfe der getEntry-, getEntryByType- oder getEntryByName-Methode abrufen. Der Eintragstyp für Markierungen ist „mark“ und der für Messungen „measure“.

Im folgenden Beispielcode wird mit den Markierungs- und Messungsmethoden die Zeit gemessen, die zum Ausführen der „doTask1()“- und „doTask2()“-Methoden benötigt wird. Sehen Sie sich eine Demo von „User Timing“ auf der IE Test Drive-Website an.

<!DOCTYPE html>

<html>

  <head>

  </head>

  <body onload='doWork()'>

    <script>

        function doWork()

        {

            performance.mark('markStartTask1');

            doTask1();

            performance.mark('markEndTask1');

           

            performance.mark('markStartTask2');

            doTask2();

            performance.mark('markEndTask2');

 

            performance.measure('measureTask1', 'markStartTask1', 'markEndTask1');

            performance.measure('measureTask2', 'markStartTask2', 'markEndTask2');

 

            sendUserTiming(performance.getEntries());

        }

    </script>

  </body>

</html>

Vielen Dank an alle Mitarbeiter der Arbeitsgruppe Web Performance des W3C für die Unterstützung bei der Entwicklung dieser Schnittstellen und an alle Browserhersteller, die diese Schnittstellen implementieren und so die Interoperabilität verbessern. Mit diesen Schnittstellen können Webentwickler aussagekräftigere Messungen durchführen und herausfinden, wie sie die Leistung der eigenen Anwendungen verbessern können.

Testen Sie die Schnittstellen zur Leistungsmessung mit Ihren Web-Apps in IE11. Selbstverständlich freuen wir uns wie immer auf Ihr Feedback über Connect.

Vielen Dank!

Jatinder Mann, Internet Explorer, Program Manager