-
Notifications
You must be signed in to change notification settings - Fork 0
/
Masterarbeit Iuliia Poberezhnaia.html
9331 lines (6913 loc) · 411 KB
/
Masterarbeit Iuliia Poberezhnaia.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<!-- Created from PDF via Acrobat SaveAsXML -->
<!-- Mapping table version: 28-February-2003 -->
<HTML>
<HEAD>
<META
name="dc.creator"
content="Julia" >
<META
name="dc.date"
content="2016-10-31T17:58:26+01:00" >
<META
name="dc.date.modified"
content="2016-10-31T17:58:26+01:00" >
<META
name="generator"
content="Adobe Acrobat Exchange-Pro 9.0.0" >
</HEAD>
<BODY bgcolor=white text=black link=blue vlink=purple alink=fushia >
<DIV class="Part"
><P
><FONT size="+1" color="#000000"></B> </P
><P
> </P
><P
><FONT size="+2">Evaluation von Frontend – Optimierungstechniken für das HTTP/2 – Protokoll unter besonderer Beachtung von Server Push <FONT size="+1"> </P
><P
><FONT size="+1"><B> <FONT size="+1"></B> </P
><P
><FONT size="+1"><B>Masterthesis <FONT size="+1"></B> </P
><P
> </P
><P
> </P
><P
><FONT size="+1">zur Erlangung des akademischen Grades Master of Arts im Studiengang Elektronische Medien<FONT size="+1"> </P
><P
><FONT size="+1">im Schwerpunkt Audiovisuelle Medien an der Hochschule der Medien Stuttgart<FONT size="+1"> </P
><P
><FONT size="+1"> <FONT size="+1"> </P
><P
><FONT size="+1">vorgelegt von <FONT size="+1"> </P
><P
><FONT size="+1"><B>Iuliia Poberezhnaia <FONT size="+1"></B> </P
><IMG width="192" height="45"
src="images/Masterarbeit Iuliia Poberezhnaia_img_0.jpg" ><P
><FONT size="+1"><B> <FONT size="+1"></B> </P
><P
><FONT size="+1"><B>Erstprüfer: </B>Prof. Walter Kriha <FONT size="+1"> </P
><P
><FONT size="+1"><B>Zweitprüfer:</B> Prof. Dipl.-Ing. Uwe Schulz <FONT size="+1"> </P
><P
><FONT size="+1"> <FONT size="+1"> </P
><P
><FONT size="+1">Bearbeitungszeitraum: 10. Juli 2016 bis 09. November 2016 <FONT size="+1"> </P
><P
><FONT size="+1">Stuttgart, November 2016<FONT size="+1"> </P
><P
> </P
><P
>Hiermit versichere ich, Iuliia Poberezhnaia, ehrenwörtlich, dass ich die vorliegende Masterarbeit mit dem Titel: „Evaluation von Frontend – Optimierungstechniken für das HTTP2 – Protokoll unter besonderer Beachtung von Server Push“ selbstständig und ohne fremde Hilfe verfasst und keine anderen als die angegebenen Hilfsmittel benutzt habe. Die Stellen der Arbeit, die dem Wortlaut oder dem Sinn nach anderen Werken entnommen wurden, sind in jedem Fall unter Angabe der Quelle kenntlich gemacht. Die Arbeit ist noch nicht veröffentlicht oder in anderer Form als Prüfungsleistung vorgelegt worden. </P
><P
>Ich habe die Bedeutung der ehrenwörtlichen Versicherung und die prüfungsrechtlichen Folgen § 19 Abs. 2 Master-SPO der HdM einer unrichtigen oder unvollständigen ehrenwörtlichen Ver-sicherung zur Kenntnis genommen. </P
><P
><FONT size="+1">Danksagung </P
><P
><FONT size="+1">Diese Arbeit wäre nicht ohne die Hilfe verschiedener Personen möglich gewesen. An dieser Stelle möchte ich mich zuerst bei Herrn Walter Kriha bedanken, der mich bei der Ideenfindung unterstützte, sowie für neue Ansätze sorgte und die Arbeit so in die richtige Richtung lenkte. Außerdem möchte ich mich bei Herrn Prof. Dipl.-Ing. Uwe Schulz bedanken, der mir in der Vorlesung relevante praktische Kenntnisse beigebracht hat, ohne die diese Arbeit nicht ent-standen wäre. Außerdem bin ich für neue Anregungen und Denkanstöße sehr dankbar. </P
><P
>Daneben gilt mein besonderer Dank Herrn Robin Schulte, der mir sowohl in der Vorlesung als auch im persönlichen Gespräch viel zum Thema Linux und Serverkonfiguration beigebracht hat. Herrn Jakob Schröter danke ich für die Unterstützung beim Thema Webperformance – Op-timierung, hilfreiche Tipps, mögliche Ansätze und Ideen zum Aufbau der Arbeit. </P
><P
>Für die Korrektur der Arbeit und die persönliche Unterstützung gebührt mein herzlicher Dank Herrn David Kirschenheuter. </P
><P
>Mein abschließender Dank gilt der Fakultät Elektronische Medien und der Hochschule der Me-dien für die Ermöglichung eines außergewöhnlichen Masterstudiums! </P
><P
> </P
><P
> </P
><P
> </P
><DIV class="TOC"
><DIV class="TOCI"
><FONT size="+1">Inhaltsverzeichnis </DIV
><DIV class="TOCI"
><A href="#LinkTarget_1048" href="#">
<FONT size="+1">1. Einleitung ................................................................................................................................................................ 1</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_1050" href="#">
1.1. Motivation und Problemstellung ........................................................................................................... 1</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_1077" href="#">
1.2. Zielsetzung ..................................................................................................................................................... 3</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_1084" href="#">
1.3. Aufbau der Arbeit ........................................................................................................................................ 4</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_1092" href="#">
2. Der kritische Rendering – Pfad und seine wichtigsten Komponenten ............................................ 5</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_1109" href="#">
2.1. Aufbau des Document Object Model .................................................................................................. 6</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_1118" href="#">
2.2. Aufbau des CSS Object Model................................................................................................................ 7</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_1123" href="#">
2.3. Render – Baumstruktur .............................................................................................................................. 7</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_1157" href="#">
2.4. „Navigation Timing API“ .......................................................................................................................... 10</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_1274" href="#">
2.5. „Resource Timing API“ ............................................................................................................................. 13</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_1310" href="#">
2.6. Zwischenfazit ............................................................................................................................................... 15</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_1333" href="#">
3. Die Probleme des HTTP/1.1 – Protokolls, das HTTP/2 – Protokoll und deren Optimierungsmöglichkeiten. .............................................................................................................................. 16</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_1335" href="#">
3.1. HTTP/1.1 – Optimierungstechniken, Stand bisher ........................................................................ 16</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_1366" href="#">
3.1.1. Nutzung von mehreren TCP – Verbindungen......................................................................... 18</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_1384" href="#">
3.1.2. Aufteilung von Ressourcen auf mehrere Domains („Domain Sharding“) ..................... 20</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_1388" href="#">
3.1.3. Zusammenfassung von Ressourcen und „Spriting“ von Bildern ...................................... 21</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_1405" href="#">
3.1.4. Ergänzung des Codes in der HTML Datei („Ressource Inlining“)..................................... 22</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_1422" href="#">
3.2. „Evergreen“ Frontend – Optimierungsmöglichkeiten .................................................................. 23</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_1473" href="#">
3.2.1. Browser Caching für statische Ressourcen ............................................................................... 24</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_1483" href="#">
3.2.2. Datenkompression während des Transports ........................................................................... 25</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_1486" href="#">
3.2.3. Reduzierung der Datenmenge der Ressourcen ..................................................................... 25</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_1494" href="#">
3.2.4. Bildoptimierung .................................................................................................................................. 26</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_1535" href="#">
3.3. Vorstellung des HTTP/2 – Protokolls .................................................................................................. 28</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_1583" href="#">
3.3.1. Wichtigste Bestandteile des HTTP/2 – Protokolls ................................................................. 30</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_1723" href="#">
3.3.2. Request und Response Multiplexierung ................................................................................... 34</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_1744" href="#">
3.3.3. Stream Priorisierung ......................................................................................................................... 35</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_1817" href="#">
3.3.4. Header Kompression ........................................................................................................................ 37</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_1831" href="#">
3.3.5. Eine TCP – Verbindung pro Domain ........................................................................................... 38</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_1854" href="#">
3.3.6. Flow Control ......................................................................................................................................... 40</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_1859" href="#">
3.3.7. Server Push ........................................................................................................................................... 40</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_1885" href="#">
3.3.8. Verbindungsaufbau unter dem HTTP/2 – Protokoll ............................................................. 42</A>
<FONT color="#0462C1"> </DIV
><DIV class="TOCI"
> </DIV
></DIV
><DIV class="TOC"
><DIV class="TOCI"
><A href="#LinkTarget_1919" href="#">
<FONT color="#000000">3.4. Mögliche Optimierungstechniken für das HTTP/2 – Protokoll ................................................ 44</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_1961" href="#">
4. Vorbereitung der Tests und zur Testevaluation ..................................................................................... 48</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_1963" href="#">
4.1. Vorbereitung der Tests ............................................................................................................................ 48</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_2056" href="#">
4.2. Vorbereitung zur Testevaluation.......................................................................................................... 54</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_2213" href="#">
5. Tests und Testevaluation ................................................................................................................................ 63</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_2216" href="#">
5.1. Wie funktioniert „Server Push“? ........................................................................................................... 63</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_2275" href="#">
5.2. Zwischenfazit ............................................................................................................................................... 67</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_2294" href="#">
5.3. Serverseitige Priorisierung von per „Server Push“ übergebenen Ressourcen ................... 69</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_2296" href="#">
5.3.1. Test 1: Priorisierung von per „Server Push“ übergebenen CSS Dateien und Schriften ............................................................................................................................................................ 69</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_2317" href="#">
5.3.2. Test 2: Priorisierung von per „Server Push“ übergebenen CSS Dateien und Bildern .............................................................................................................................................................................. 71</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_2334" href="#">
5.4. Zwischenfazit ............................................................................................................................................... 72</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_2340" href="#">
5.5. Untersuchungen zum „Server Push“ ................................................................................................... 73</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_2372" href="#">
5.5.1. Test 1: „Server Push“ – Einsatz für kritische CSS Ressourcen ............................................ 74</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_2654" href="#">
5.5.2. Zwischenfazit ....................................................................................................................................... 80</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_2657" href="#">
5.5.3. Test 2: „Server Push“ – Einsatz für nicht kritische JavaScript Ressourcen ..................... 80</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_2662" href="#">
5.5.4. Test 3: „Server Push“ – Einsatz für kritische CSS Ressourcen und nicht kritische Ressourcen (Schriften) ................................................................................................................................. 81</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_2949" href="#">
5.5.5. Zwischenfazit ....................................................................................................................................... 88</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_2953" href="#">
5.5.6. Test 4: „Server Push“ – Einsatz für kritische CSS Ressourcen und nicht kritische Ressourcen (Bilder) ....................................................................................................................................... 89</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_3147" href="#">
5.5.7. Zwischenfazit ....................................................................................................................................... 94</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_3151" href="#">
5.6. Zwischenfazit ............................................................................................................................................... 94</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_3162" href="#">
5.7. Vergleich des HTTP/1.1 mit dem HTTP/2 – Protokoll .................................................................. 95</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_3301" href="#">
5.7.1. Test 1: Untersuchung der Startseite der Webapplikation unter dem HTTP/1.1- und dem HTTP/2 – Protokoll. ............................................................................................................................. 99</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_3608" href="#">
5.7.2. Zwischenfazit .................................................................................................................................... 104</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_3614" href="#">
5.7.3. Test 2: Untersuchung der Dozenten-Seite unter den Protokollen HTTP/1.1- und HTTP/2. ........................................................................................................................................................... 105</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_3922" href="#">
5.7.4. Zwischenfazit .................................................................................................................................... 111</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_3931" href="#">
5.8. Spielt die Ressourcenaufteilung eine Rolle für das HTTP/2 – Protokoll? .......................... 111</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_4039" href="#">
5.8.1. Zwischenfazit .................................................................................................................................... 114</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_4060" href="#">
5.9. Wie funktioniert das HTTP/2 – Protokoll in anderen Browsern? .......................................... 117</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_4063" href="#">
5.9.1. Test 1: Gibt es deutliche Unterschiede in der Bearbeitungsart des neuen Protokolls zwischen den drei populärsten Desktop-Browsern? ..................................................................... 117</A>
</DIV
></DIV
><DIV class="TOC"
><DIV class="TOCI"
><A href="#LinkTarget_4086" href="#">
5.9.2. Zwischenfazit .................................................................................................................................... 119</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_4090" href="#">
5.9.3. Test2: Wie wird der Browser „Google Chrome“ per „Server Push“ übergebene Ressourcen interpretieren? ..................................................................................................................... 120</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_4107" href="#">
5.9.4. Zwischenfazit .................................................................................................................................... 122</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_4110" href="#">
5.10. Angetroffene Schwierigkeiten während der Testdurchführung und der Testevaluation ............................................................................................................................................................................... 122</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_4133" href="#">
6. Fazit und Ausblick ........................................................................................................................................... 125</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_4161" href="#">
7. Literaturverzeichnis ........................................................................................................................................ 128</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_4973" href="#">
8. Kurzfassung / Abstract .................................................................................................................................. 138</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_4979" href="#">
9. Anhang................................................................................................................................................................ 139</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_4981" href="#">
9.1. Upgrade HTTP/2...................................................................................................................................... 139</A>
</DIV
><DIV class="TOCI"
><A href="#LinkTarget_5062" href="#">
9.2. Browserstatistik ........................................................................................................................................ 141</A>
</DIV
><DIV class="TOCI"
> </DIV
></DIV
><P
> </P
><P
> </P
><P
> </P
><P
> </P
><P
> </P
><P
> </P
><P
> </P
><P
> </P
><H1
><FONT size="+1">1. Einleitung </H1
><H2
><FONT size="+1">1.1. Motivation und Problemstellung </H2
><P
><FONT size="+1">In den letzten Jahren sind Internetverbindungen deutlich schneller geworden. Allerdings ist die Ladezeit einer Webseite im Vergleich zu früheren Jahren fast gleich geblieben. Der Grund dafür ist, dass die verfügbare Bandbreite im Vergleich zur Menge der Daten einer Webseite fast linear wächst. In den ersten Jahren des Internets lagen die Bandbreiten zwischen 9,6 und 56 kBit/s, deshalb wurde in diesen Zeiten sehr auf die Reduzierung der Datenmenge geachtet. Heutzu-tage hat sich die Bandbreite deutlich vergrößert und aufgrund dessen werden auch viele Res-sourcen innerhalb einer Webapplikation genutzt (Kuhn/Raith 2013, 5). Abb. 1 veranschaulicht, wie mit der zunehmenden Größe aller Responses während des Transports die Anzahl von Re-quests steigt. Die Messungen wurden pro einer Webseite gemacht. </P
><P
> </P
><IMG width="607" height="303"
src="images/Masterarbeit Iuliia Poberezhnaia_img_1.jpg" ><DL
><DD
><I>Abb. 1:</I><I> </I><I>Vergleich der durchschnittlichen Größe aller Responses während des Transports mit der durchschnittlichen Anzahl von Requests pro einer Webseite. Die Daten wurden zwischen Januar 2012 und August 2016 gemessen (<</I><A href="http://httparchive.org/">
<I>http://httparchive.org/</I></A>
<I>>). </I></DD
></DL
><P
>Mit der oben dargestellten Grafik kann man sagen, dass die Webapplikationen selbst immer komplexer werden und die Dateivolumen zunehmen werden. Deshalb kann gesagt werden, dass das Internet bis heute nicht schneller geworden ist, es können nur mehr Daten übertragen werden (Kuhn/Raith 2013, 5). </P
><P
> </P
><P
>In diesem Zusammenhang ist die Webperformance – Optimierung sehr wichtig. Es werden ein paar Beispiele dafür genannt. Die Geschwindigkeit einer Webapplikation beeinflusst z.B. den Onlinehandel sehr. „Amazon“ hat herausgefunden, dass jede 100 ms Verzögerung beim Laden der Webseite die Verkäufe um 1% verringert. „Google“ und „Microsoft Bing“ haben herausge-funden, dass 2 Sekunden Verzögerung beim Laden der Webseite das Einkommen um 4.3% </P
><P
>verringert. Die Untersuchungen der „Aberdeen Group“ zeigen, dass ein Viertel aller Nutzer nur drei Sekunden wartet, bis eine Webapplikation geladen hat. „Akamai“ hat ähnliche Untersu-chungen gemacht und es hat sich herausgestellt, dass 57% aller Nutzer einer Webseite nach einer 4 Sekunden dauernden Wartezeit die Interaktion mit der Webseite beenden werden (Ri-gor, Inc. 2016). Außerdem kommt dazu, dass unabhängig von den Datenraten in mobilen End-geräten, 71% der mobilen Nutzer erwarten, dass die Webapplikation nicht langsamer als am Desktop PC geladen wird (Equation Research 2011). </P
><P
> </P
><P
>Etwa 80-90% der gesamten Geschwindigkeit der Webapplikation macht das Frontend aus. Diese Zahlen hat Steve Sounders, leitender Chefingenieur für Webperformance bei „Google“ herausgefunden. In seinen Forschungen konnte er zeigen, dass die große Mehrheit der Perfor-mance – Problemstellen, welche von den Websitenutzern gesehen werden, das Laden und Rendern von CSS, JavaScript Dateien und Bildern betrifft (Rigor, Inc. 2016). Deshalb sind die clientseitigen Techniken zur Performance – Optimierung sehr wichtig. In der aktuellen Master-arbeit wird der Fokus auf diese Techniken gelegt. </P
><P
> </P
><P
>Man darf auch nicht vergessen, dass seit Juni 1999 für das Hypertext – Übertragungsprotokoll die Version HTTP/1.1 (Fielding et al. 1999) verwendet wurde. Wie zuvor gesagt wurde, sind die Webapplikationen mit deren vielfältigen Medieninhalten immer größer und komplexer gewor-den (Grigorik 2013, 161). Mit täglich zunehmenden Interaktionen im Web und der geforderten Ansprechbarkeit der Webapplikationen in Echtzeit, konnte die Leistung des zuvor verwendeten HTTP/1.1 – Protokolls kaum der benötigten Leistung entsprechen. Deshalb bestand ein Bedarf an zusätzlichen Modifikationen (Grigorik 2013, 162). </P
><P
>Im Januar 2012 wurde von der „HTTPbis Working Group“ eine Nachricht publiziert, dass sie eine neue Spezifikation des HTTP – Protokolls entwickeln werden. Die neue Version soll die Übertragungsleistung beschleunigen und gleichzeitig sollen weniger Latenz und eine größere Durchflussleistung entstehen. Gleichzeitig werden die Semantiken der höheren Ebene wie Me-thoden, Statuscodes, URIs und Headerfelder unverändert bleiben. Dies bedeutet, dass man die neue Version des Protokolls ohne zusätzliche Änderungen in der Webapplikation verwenden kann. (Grigorik 2013, 162) </P
><P
>Im Februar 2015 wurde die neue Version des HTTP – Protokolls: HTTP/2 von der IESG („The Internet Engineering Steering Group“) genehmigt (Grigorik 2015, 4). Im Mai des gleichen Jahres ist die offizielle Dokumentation des Protokolls erschienen: RFC – 7540 (Belshe et al. 2015) und RFC – 7541 (Peon/Ruellan 2015). Um den Ressourcenaustausch zwischen Client und Server un-ter dem bisher verwendeten HTTP/1 – Protokoll etwas zu beschleunigen, werden bestimmte Frontend – Optimierungsmaßnahmen für die Webapplikation angewendet. Diese werden oft als „Workarounds“ bezeichnet, weil diese viele Nachteile haben (Grigorik 2013, 162). Bei der Verwendung des neuen Protokolls sind die im HTTP/1-Protokoll beliebten „Workarounds“ </P
><P
>nicht mehr nötig (Grigorik 2013, 242). Dies bedeutet, dass der Entwicklungsprozess einer Webapplikation unter dem HTTP/2 – Protokoll unkomplizierter sein sollte. </P
><P
> </P
><P
>Mithilfe des HTTP/2 – Protokolls können existierende Problemstellen des HTTP/1 – Protokolls limitiert werden. Hinsichtlich der technologischen Möglichkeiten des HTTP/2 – Protokolls kann der Austausch zwischen dem Client und dem Server deutlich beschleunigt werden (Buch, Excerpt HTTP/2 IG, 5). Aus diesem Grund entstand die Hauptmotivation für die Untersuchung des neuen Protokolls, die in der aktuellen Masterarbeit schrittweise ausgearbeitet wird. </P
><H2
><FONT size="+1">1.2. Zielsetzung </H2
><P
><FONT size="+1">Das HTTP/2 – Protokoll verfügt über viele neue Funktionen, die die Ladezeit der Webapplika-tion rasant beschleunigen können (Buch, Excerpt HTTP/2 IG, 5).<FONT color="#FF0000"> <FONT color="#000000">Einige Funktionen werden in-nerhalb der Benutzung dieses Protokolls automatisch angewendet. Bei anderen Funktionen besteht die Möglichkeit, diese für jede einzelne Webapplikation individuell anzupassen. Dazu gehört die Funktion „Server Push“, die in zahlreichen Quellen (Grigorik 2015, 17), (Jayaprakash 2016), (Krasnov 2016), (Ross, 2016) als sehr leistungsfähig für die Beschleunigung der Ladezeit der Webapplikation erachtet wird. Wie zuvor erwähnt wurde, liegt der Fokus der aktuellen Masterarbeit auf den Untersuchungen der Frontend Performance – Optimierungstechniken. In diesem Zusammenhang ist es interessant, zu beobachten, wie groß die Einflüsse des „Server Pushs“ auf die Ladezeit der Webapplikation sind. Welche Techniken müssen angewendet wer-den, um diese Funktion möglichst vorteilhaft nutzen zu können? Aufgrund dessen, liegt das erste Ziel dieser Masterarbeit auf der Untersuchung der Ladezeit der Webapplikation mithilfe des HTTP/2 – Protokolls und dessen Funktion „Server Push“ in unterschiedlichen Einsätzen. Besonders wird dabei auf die clientseitigen Frontend Performance – Optimierungstechniken geachtet. </P
><P
>Das zweite Ziel ist der Vergleich der Unterschiede der Ladezeit der Webapplikation zwischen dem HTTP/1.1- und dem HTTP/2 – Protokoll, wenn die Webapplikation gesondert für jede Ver-sion des HTTP – Protokolls optimal angepasst wird. Es ist interessant zu untersuchen, wie groß die Vorteile des neuen Protokolls sind. </P
><P
>Das dritte Ziel, das in der aktuellen Arbeit verfolgt wird, ist die Auseinandersetzung mit der Konfiguration des Webservers für das HTTP/2 – Protokoll im Hinblick auf den „Server Push“. Zum anderen sollen die wichtigsten Schritte und Metriken des kompletten Ladezeitprozesses einer Webapplikation ausgewählt werden, die sowohl für die Erstdarstellung, als auch für die Gesamtladezeit im Webbrowser wichtig sind. </P
><P
>Die Ergebnisse der aktuellen Arbeit sollen den Stand der aktuellen Implementierung des HTTP/2 – Protokolls zeigen. Dadurch sollen Frontend – Webentwicklern Hinweise gegeben werden, welche Maßnahmen unternommen werden müssen, um perfomante Webanwendun-</P
><P
>gen unter dem neuen Protokoll zu erstellen. Zum anderen werden angetroffene Schwierigkei-ten und Schwachstellen aufgezeigt, die während des Testverlaufs oder der Testauswertung er-kannt wurden. </P
><H2
><FONT size="+1">1.3. Aufbau der Arbeit </H2
><P
><FONT size="+1">Um die gesetzten Ziele zu erreichen, wurde die vorliegende Arbeit in mehrere Kapitel aufgeteilt: Theoretische Grundlagen, Vorbereitung der Tests und Testevaluation, Testdurchführung, sowie Evaluation und abschließende Betrachtung. </P
><P
>In ersten theoretischen Kapitel wird der kritische Rendering – Pfad und dessen Rolle in der Webperformance – Optimierung dargestellt. Es werden die Modelle der „Navigation Timing API“ und der „Ressource Timing API“ vorgestellt. </P
><P
>In einem weiteren theoretischen Kapitel wird zunächst analysiert, welche Problemstellen unter dem HTTP/1 – Protokoll existieren und mit welchen clientseitigen Techniken zur Perfor-mance – Optimierung diese gelöst werden können. Anschließend werden die wichtigsten Frontend – Optimierungstechniken beschrieben, die unabhängig von der Version des verwen-deten HTTP – Protokolls für die Erstellung performanter Webapplikationen geeignet sind (sog. „Evergreen“-Techniken). Zuletzt wird als theoretische Grundlage das HTTP/2 – Protokoll und dessen Funktionen dargestellt. Ebenso werden die Frontend – Optimierungstechniken be-schrieben, die für das neue Protokoll geeignet sein können. </P
><P
>Im Rahmen der Testvorbereitungen wird eine Webapplikation entwickelt, die für die Fragestel-lung dieser Masterarbeit interessant zum Untersuchen ist. Es werden jeweils für das HTTP/1.1- und HTTP/2 – Protokoll spezifische Frontend – Optimierungsmaßnahmen ausgewählt und auf die Webapplikation angewendet. Dadurch sollen optimale Bedingungen für die Webapplika-tion unter beiden Protokollen erreicht werden. Als nächstes wird erörtert, wie der passende Webserver ausgewählt und konfiguriert werden soll, damit er die Implementierung des HTTP/2 – Protokolls mit der Funktion „Server Push“ unterstützt. Als letzten Schritt zur Testvor-bereitung werden hilfreiche Tools für die Durchführung der Tests vorgestellt. Außerdem wird eine geeignete Auswertungsmethode vorgestellt. </P
><P
>Im nächsten Kapitel wird die entwickelte Webapplikation unter unterschiedlichen Bedingungen getestet und die Ergebnisse evaluiert. Da der Fokus dieser Arbeit auf der Untersuchung der Funktion „Server Push“ liegt, werden dafür unterschiedliche Einsätze simuliert, um herauszufin-den, welche dieser Einsätze für die Performanz vorteilhaft sein können. </P
><P
>Im zweiten Test-Teil wird untersucht, wie groß die Unterschiede der Ladezeit zwischen dem HTTP/1- und dem HTTP/2 – Protokoll sind. Während der Testevaluation werden die theoreti-schen Ergebnisse mit den erzielten Testergebnissen verglichen, um zu sehen, ob die theoreti-schen Annahmen zu den erzielten Ergebnissen passen. </P
><P
>Abschließend werden sämtliche Ergebnisse zusammengefasst und ein Ausblick gegeben. </P
><H1
><FONT size="+1">2. Der kritische Rendering – Pfad und seine wichtigsten Komponenten </H1
><P
><FONT size="+1">In der Einleitung wurde kurz erläutert, was die Web Performance für kommerzielle Webauftritte ausmacht und warum clientseitige Techniken zur Performance – Optimierung so wichtig sind. Performance – Optimierung ist ein Prozess, der zur Verbesserung der Ausliefergeschwindigkeit von Webdiensten führt, um so die Nutzererwartung (geringe Ladezeit) zu erfüllen (Mishunov 2015). Wie lange darf eine Webseite geladen werden? Nach dem „Platform Success Model“, das von Google erstellt wurde (Duca/Glazkov 2016), ist das Limit der Ladezeit einer Webseite auf eine Sekunde begrenzt. Diese Reaktionszeit hängt mit psychologischen Aspekten der menschlichen Kommunikation zusammen. Normalerweise gibt es in einem persönlichen Dialog zwischen zwei Menschen eine kurze Reaktionszeit auf eine Frage. Nutzer wollen von einer Web-seite die gleiche Reaktionszeit haben, wie bei zwischenmenschlicher Kommunikation. Aus die-sem Grund muss man bei der Performance – Optimierung wichtige Zeitstufen aus der Psycho-logie im Kopf behalten (Mishunov 2015). Diese Stufen sind: </P
><DL
><DD
> „Augenblicklich“: 0,1-0,2 Sekunden. </DD
><DD
> „Unmittelbar“: 0,5-1 Sekunde. </DD
><DD
> „Phase der Absorption“: 2 bis 5 Sekunden. </DD
><DD
> „Endzeit der Aufmerksamkeit “: 5 bis 10 Sekunden. </DD
></DL
><P
>(Mishunov 2015). </P
><P
>Wenn man diese Stufen auf das „Platform Success Model“ anwendet, bekommt man Ladezei-ten einer Webseite, die der Reaktionszeit zwischenmenschlicher Kommunikation ähnlich sind: der Ladevorgang der Webseite soll unmittelbar beginnen und die Nutzer sollen augenblickli-che Rückmeldungen von der Webapplikation bekommen. Deshalb liegt das Ziel der Perfor-mance – Optimierung im Erreichen von Ladezeiten, die im Rahmen der Reaktionszeiten zwi-schenmenschlicher Kommunikation liegen (Mishunov 2015). </P
><P
>Allerdings zählen nicht nur die Zahlen, die beim Laden einer Webseite gemessen werden kön-nen. Wichtig ist auch die von Nutzern wahrgenommene Ladezeit. Diese besagt, was der Nutzer denkt, wie lange die Webseite geladen wurde. Um diese wahrgenommene Ladezeit optimieren zu können, müssen zuerst alle wichtigen (als erste sichtbare) Komponenten geladen werden. Wenn die Webseite z.B. einen Footer beinhaltet, deren Komponenten sich nicht im Viewport befinden, sind diese Informationen nur nebensächlich und können später geladen werden. Des Weiteren ist es auch wichtig, die Inhalte zu übergeben, mit denen der Nutzer interagieren kann. Man muss darauf achten, dass diese Inhalte auch eine Interaktionskomponente haben (z.B. klickbare Buttons). Der Schwerpunkt der Performance – Optimierung muss auf der wahrge-nommenen Ladezeit liegen (Mishunov 2015). </P
><P
>In diesem Kapitel wird beschrieben, welche Schritte im Browser passieren, um eine Webappli-kation darstellen zu können. Dazu wird erklärt, was der kritische Rendering – Pfad ist und wa-rum es wichtig ist, diesen zu optimieren. Außerdem wird erläutert, wie eigentlich die Perfor-mance gemessen werden kann und welche Parameter dazu benötigt werden. </P
><H2
><FONT size="+1">2.1. Aufbau des Document Object Model </H2
><P
><FONT size="+1">Bevor der Browser erste Pixel der Webapplikation im Viewport darstellt, müssen einige Schritte stattgefunden haben. Das Document Object Model (DOM) der HTML Datei und das CSS Object Model (CSSOM) von allen CSS Dateien müssen aufgebaut und in einem Render – Baum zu-sammengefügt werden (Abb. 2) (Grigorik 2013, 168). Nachdem die ersten Bytes des HTML Do-kuments den Browser erreichen, fängt er an, das HTML Dokument zu parsen (Grigorik 2016a). </P
><P
>Die DOM-Erstellung besteht aus mehreren Phasen: zuerst wird der Browser die Rohbytes mit-hilfe der Dateicodierung (z.B. UTF-8) in einzelne Zeichen übersetzen. Im nächsten Schritt wer-den die Zeichenfolgen, die sich in spitzen Klammern befinden, in eindeutige Token konvertiert, wie z.B. <html>, <head> u.s.w. Jedes Token hat gemäß dem „W3C“ HTML5-Standard (W3C 2014a) eine spezielle Bedeutung und Satzregeln. Im dritten Schritt werden die Token in Objekte umgebaut, die eigene Merkmale und Eigenschaften haben. Im letzten Schritt werden die zuvor hergestellten Objekte für die Erstellung einer hierarchischen Baumstruktur verwendet (Grigorik 2016c). </P
><P
> </P
><IMG width="610" height="285"
src="images/Masterarbeit Iuliia Poberezhnaia_img_2.jpg" ><DL
><DD
><I>Abb. 2:</I><I> </I><I>Aufbau des Render - Baumes, (Grigorik 2016d). </I></DD
></DL
><P
> </P
><H2
><FONT size="+1">2.2. Aufbau des CSS Object Model </H2
><P
><FONT size="+1">Falls während dem HTML-Parsing ein Link-Tag auf eine externe CSS Datei gefunden wird, wird sie sofort am Server angefordert (Grigorik 2016c). Parallel zur DOM Erstellung wird das CSS Object Model (CSSOM) aufgebaut (Grigorik 2013, 168). </P
><P
>CSS Dateien sind auch für die Erstdarstellung der Webapplikation wichtig. Sie beschreiben die Formatierungsregeln, die für eine HTML Datei angewendet werden (Grigorik 2016d). Deshalb wird der Browser, wenn die CSS Datei vom Parser heruntergeladen wird, sofort anfangen, die CSS Datei zu bearbeiten. Die visuelle Darstellung wird dadurch blockiert werden (Grigorik 2016e).<FONT color="#FF0000"> </P
><P
><FONT color="#000000">Die CSSOM Erstellung besteht auch aus mehreren Phasen, die der DOM Erstellung sehr ähnlich sind (Abb. 2). Zuerst wird der Browser die Rohbytes in einzelne Zeichen mithilfe der Dateico-dierung (z.B. UTF-8) übersetzen. Im nächsten Schritt werden die Zeichenfolgen in eindeutige Token konvertiert. Danach werden die Token in Objekte umgebaut, die eigene Merkmale und Eigenschaften von CSS Spezifikationen haben. Im letzten Schritt werden diese Objekte in einer Baumstruktur verbunden. CSSOM hat eine Baumstruktur, weil die CSS-Regeln zuerst auf ein Eltern-Element eines Objektes angewendet werden. Erst danach werden die CSS-Regeln auf das Objekt selbst angewendet (Grigorik 2016c). </P
><H2
><FONT size="+1">2.3. Render – Baumstruktur </H2
><P
><FONT size="+1">Auf der Basis der DOM- und CSSOM-Baumstrukturen wird eine Render – Baumstruktur erstellt (Abb. 2). Mithilfe der Render – Baumstruktur wird der Browser aus allen auf der Seite sichtbaren Elementen ein Layout erstellen. Nach diesem Schritt werden die ersten Pixel im Viewport er-scheinen (Abb. 3) (Grigorik 2016c). </P
><P
>Der Prozess der Erstellung der Render – Baumstruktur besteht aus mehreren Etappen, die in Abb. 3 dargestellt werden: </P
><DL
><DD
>1. Jeder sichtbare Knoten in der DOM – Baumstruktur wird gefunden. Dieser Schritt be-trifft nicht alle Elemente, z.B. Script-Tags oder Metatags werden auf der Seite unsichtbar sein und werden weggelassen. Außerdem werden manche Elemente mithilfe der CSS-Regeln versteckt. Diese Elemente werden auch nicht in der Render – Baumstruktur er-scheinen. </DD
><DD
>2. Für jeden Knoten, der sichtbar ist, werden entsprechende CSS-Regeln gesucht und an-gewendet. </DD
><DD
>3. Im letzten Schritt werden die sichtbaren Knoten mit den entsprechenden CSS-Regeln ausgegeben und die Render – Baumstruktur wird fertiggestellt. </DD
></DL
><P
>(Grigorik 2016d). </P
><P
><I> </I></P
><P
><I>Einfluss von JavaScript </I></P
><P
>JavaScript spielt auch eine große Rolle bei der Erstellung des DOMs und CSSOMs. JavaScript kann sowohl die Inhalte der HTML Seite als auch CSS-Regeln ändern und manipulieren (Abb. 3). Die DOM-Erstellung wird angehalten, bevor JavaScript nicht komplett heruntergeladen und ausgeführt wurde. Falls eine JavaScript Datei oder ein JavaScript-Code in der HTML Seite ent-deckt wird, bevor der Aufbau des CSSOM fertig ist, wird der Browser warten, bis CSSOM kom-plett aufgebaut wird. Erst danach wird die JavaScript Datei ausgeführt. Dann kann das DOM fertig gestellt werden und der Browser kann mit dem Aufbau der Render – Baumstruktur an-fangen (Grigorik 2016f), (Grigorik 2016h). </P
><P
> </P
><IMG width="463" height="144"
src="images/Masterarbeit Iuliia Poberezhnaia_img_3.jpg" ><DL
><DD
><I>Abb. 3:</I><I> </I><I>Bearbeitungskette der HTML-, CSS- und JavaScript Dateien im Browser (Grigorik 2013, 168). </I></DD
></DL
><P
>Für die Erstdarstellung auf dem Viewport sind nur HTML, CSS und JavaScript Dateien wichtig (Grigorik 2016h). Alle andere Dateien (z.B. Bilder oder Schriften) spielen hier keine Rolle. Die Ladereihenfolge von diesen Dateien ist wichtig: JavaScript muss so wenig wie möglich die Ren-der – Baumstruktur verzögern. Falls die JavaScript Dateien synchron geladen werden, wird die DOM-Erstellung während des Ladens und der Ausführung der JavaScript Dateien angehalten (Grigorik, 2012). Gleichzeitig müssen CSS Dateien so schnell wie möglich dem Client übergeben werden, damit das CSSOM möglichst früh aufgebaut wird (Grigorik 2016h). Um dies zu errei-chen, ist es empfehlenswert, CSS Dateien am Anfang der HTML Seite zu platzieren, damit der Browser gleich anfangen wird, diese herunterzuladen. Außerdem ist es hilfreich, Medienabfra-gen zu benutzen, in der bestimmte Merkmale zur CSS Datei stehen (z.B. media="print" für die Druckansicht). Mithilfe von diesen Merkmalen werden alle eingebundenen CSS Dateien herun-tergeladen, aber die Ausführungszeit wird verkürzt (Grigorik 2016e). </P
><P
>JavaScript kann auf die DOM-Elemente zugreifen, deshalb müssen die DOM-Knoten zuerst er-stellt werden. Außerdem müssen die DOM-Elemente im Baum gefunden werden, bevor Ja-vaScript ausgeführt wird. Da JavaScript den weiteren DOM-Aufbau blockiert und gleichzeitig auf CSSOM wartet, ist es empfehlenswert, die JavaScript Dateien am Ende des HTML Doku-ments einzubinden (Grigorik, 2012). </P
><P
>Wenn die JavaScript Datei für die DOM-Struktur und die Erstdarstellung nicht wichtig ist, ist es empfehlenswert, die Skripte asynchron zu laden oder dann zu laden, wenn das DOM fertig </P
><P
>gebaut ist. „Async“ und „defer“ Attribute sind boolean Attribute, die zeigen, wie die JavaScript Dateien ausgeführt werden sollen (W3C 2014b). </P
><P
>Wenn asynchrone JavaScript Dateien gefunden werden, werden sie sofort während dem HTML-Parsing heruntergeladen, und asynchron ausgeführt, sobald sie zur Verfügung stehen. Dies passiert unabhängig davon, in welcher Reihenfolge sie in der HTML Datei aufgelistet sind. Dafür ist ein „async“ Attribut verantwortlich (W3C 2014b), (Souders 2010). </P
><P
>Eine andere Möglichkeit ist es, das Attribut „defer“ zu verwenden. Dieses signalisiert dem Brow-ser, dass er die JavaScript Datei erst ausführen muss, wenn das HTML Dokument fertig gepar-sed ist (W3C 2014b). JavaScript Dateien mit dem Attribut „defer“ werden parallel herunterge-laden, aber werden genau in der Reihenfolge ausgeführt, in welcher sie im HTML-Dokument aufgelistet sind. Dies passiert unabhängig davon, in welcher Reihenfolge sie angekommen sind (Souders 2010). </P
><P
>Bei der Verwendung von sowohl „defer“ als auch „async“ Attributen, wird die DOM-Erstellung nicht mehr blockiert (Grigorik, 2012).<FONT color="#FF0000"> </P
><P
><FONT color="#000000">Diese beiden Attribute werden von populären modernen Browsern unterstützt (Mozilla Deve-loper Network and individual contributors 2016a). </P
><P
>Die Anwendung sowohl von „defer“ als auch von „async“ Attributen für Skripte, die im HTML-Code eingefügt sind, hat keinen Effekt (Mozilla Developer Network and individual contributors 2016a). </P
><P
>Nachdem die Render – Baumstruktur fertiggestellt ist, wird das Layout berechnet (Abb. 3). Je nachdem, wie komplex die HTML und CSS Dateien sind, ob JavaScript DOM-Elemente anders platzieren wird oder CSSOM-Elemente ändern wird, wird die Berechnung des Seitenlayouts einige Zeit brauchen. Nachdem das Layout fertig gestellt wurde, wird der Browser auf den je-weiligen Ebenen Teile der visuellen Elemente zeichnen. Dazu gehören z.B. Farben, Schriften, Bilder u.s.w. Im letzten Schritt werden alle Ebenen mit dem darauf gezeichneten Content zu-sammengesetzt. Dieser Schritt ist wichtig, damit die Elemente, die im Viewport angezeigt wer-den, ihre Richtige Stelle haben werden und nicht überlappen werden (Lewis 2016). </P
><P
>Die Produktivität dieser letzten Schritte hängt oftmals von der Entwicklungsqualität der einzel-nen Bestandteile ab: HTML, CSS und JavaScript. Es gibt viele Optimierungsmöglichkeiten, die die Ausführung dieser Schritte beschleunigen können. Allerdings werden Optimierungsmög-lichkeiten ab der Erstellung des Render – Baumes im Rahmen dieser Masterarbeit nicht be-trachtet, weil diese Art von Optimierungen zur Optimierung einzelner Dateien der Webanwen-dung gehören und nicht direkt mit der Optimierung der Dateiauslieferung zusammenhängen. </P
><P
>Alle diese Schritte, die zwischen dem Empfang der HTML, CSS und JavaScript Dateien passie-ren, wie schnell diese verarbeitet werden, und bis diese als gerenderte Pixel im Viewport er-scheinen, ist der kritische Rendering – Pfad (Grigorik 2016g). </P
><H2
><FONT size="+1">2.4. „Navigation Timing API“ </H2
><P
><FONT size="+1">Für die detaillierte Analyse des kritischen Rendering – Pfades einer Webapplikation im Webbrowser steht das „Navigation Timing API“ Tool zur Verfügung (Grigorik 2016a). Die „Na-vigation Timing API“ wurde vom „W3C“ (World Wide Web Consortium) (W3C 2016a) spezifi-ziert und dokumentiert.<FONT color="#FF0000"> </P
><P
><FONT color="#000000">„Navigation Timing API“ definiert ein Interface für Webapplikationen, das Messdaten zum kom-pletten Zeitraum, der für die Navigation über das komplette Dokument (HTML Datei) benötigt wird, sammelt und diese Daten zur Verfügung stellt (W3C 2016b). Die „Navigation Timing API“ wurde in allen populären mobilen und Desktopbrowsern implementiert (Mozilla Developer Network and individual contributors 2016b). Mithilfe dieser API kann der Browser die gesam-melten Messdaten der verschiedenen Phasen des kritischen Rendering – Pfades zur Verfügung stellen (W3C 2016b), (Grigorik 2016a). </P
><P
>„Navigation Timing API“ wird vom „W3C“ als „Performance Navigation Timing“ Interface be-zeichnet. Abb. 4 illustriert die Attribute des „Performance Navigation Timing“ Interfaces (W3C 2016b). Diese Attribute werden in Millisekunden ausgeliefert. </P
><P
> </P
><IMG width="612" height="313"
src="images/Masterarbeit Iuliia Poberezhnaia_img_4.jpg" ><DL
><DD
><I>Abb. 4:</I><I> </I><I>„Performance</I><I> </I><I>Navigation Timing“ Interface (</I><I><</I><A href="https://www.w3.org/TR/navigation-timing-2/">
<I>https://www.w3.org/TR/navigation-tim-ing-2/</I></A>
<I>>). </I></DD
></DL
><P
> </P
><P
>Das „Performance Timing Interface“ stellt eine komplette Kette der Navigation dar, die in jedem Browser passiert. Jedes Performance Timing Attribut hat einen Start- und Endpunkt. Dies er-öffnet die Möglichkeit, zu untersuchen, wie lange ein bestimmtes Event gedauert hat. Nach dem Aufruf einer Webapplikation wird zuerst die zuvor angezeigte Webapplikation vom Viewport gelöscht. Die Zeit dafür kann als Differenz zwischen „unloadEventEnd“ und „unloadE-ventStart“ berechnet werden. Falls es keine zuvor geladene Seite gibt, oder die frühere Seite oder einer der erforderlichen Redirects nicht die gleiche Domain haben, wird dieser Wert auf 0 gesetzt. Danach wird die Internetadresse vom Netzwerk aufgerufen (Mozilla Developer Net-work and individual contributors 2016c). </P
><TABLE
border=0 cellspacing=0 cellpadding=2
><TR
><TD
valign="top"
><P
>Attribute des „Performance Navigation Timing“ Inter-faces </P
></TD
><TD
valign="top"
><P
>Bedeutung </P
></TD
></TR
><TR
><TD
valign="top"
><P
>„redirect“ </P
></TD
><TD
valign="top"
><P
>Wird ausgegeben, wenn ein Redirect stattfindet. </P
></TD
></TR
><TR
><TD
valign="top"
><P
>„fetchStart“ </P
></TD
><TD
valign="top"
><P
>Registriert den Zeitpunkt, an dem der Client anfängt, nach der Ressource mithilfe des HTTP-Requests zu fragen. </P
></TD
></TR
><TR
><TD
valign="top"
><P
>„domainLookupEnd“ </P
></TD
><TD
valign="top"
><P
>Registriert den Zeitpunkt, an dem die IP-Adresse des Domain-namens bestimmt wird. Falls die IP-Adresse des Domainna-mens aus dem Cache der Anwendung aufgerufen wird, wird dieser Parameter den gleichen Zeitpunkt wie der des „fetchStart“ Attributs haben. </P
></TD
></TR
><TR
><TD
valign="top"
><P
>„connectEnd“ </P
></TD
><TD
valign="top"
><P
>Wird ausgegeben, wenn die Verbindung zum Server herge-stellt wurde. Falls es eine verschlüsselte Verbindung ist, wird ein TSL-Handshake zwischen den „connectStart“- und „connectEnd“ Attributen angezeigt. </P
></TD
></TR
><TR
><TD
valign="top"
><P
>„requestStart“ </P
></TD
><TD
valign="top"
><P
>Das HTML Dokument wird vom Server, dem Anwen-dungscache oder einer lokalen Ressource angefragt. </P
></TD
></TR
><TR
><TD
valign="top"
><P
>„responseStart“ </P
></TD
><TD
valign="top"
><P
>Wird dann ausgegeben, wenn das erste Byte der Anfrage den Client erreicht. </P
></TD
></TR
><TR
><TD
valign="top"
><P
>„responseEnd“ </P
></TD
><TD
valign="top"
><P
>Registriert den Zeitpunkt, an dem der Client alle Bytes der An-frage bekommen hat. </P
></TD
></TR
><TR
><TD
valign="top"
><P
>„domLoading“ </P
></TD
><TD
valign="top"
><P
>Zeigt den Zeitstempel, ab wann der Browser mit dem Parsen der empfangenen Bytes anfängt. Dieser Wert wurde in Abb. 4 nicht angezeigt, da alle existierenden Webbrowser auf unter-schiedliche Weise das DOM erstellen und die Zeitpunkte für das „domLoading“ Attribut sich je nach Implementierung un-terscheiden. Deshalb ist es nicht empfehlenswert, dieses Attri-but für die Messungen zu benutzen (Grigorik 2016a), (W3C 2016b). </P
></TD
></TR
></TABLE
><TABLE
border=0 cellspacing=0 cellpadding=2
><TR
><TD
valign="top"
><P
>„domInteractive“ </P
></TD
><TD
valign="top"
><P
>Das Attribut zeigt den Zeitstempel an, an dem das HTML-Do-kument fertig geparsed wurde und das DOM erstellt wurde (Mozilla Developer Network and individual contributors 2016c) (Grigorik, 2012). In diesem Moment ändert sich der Document.readyState auf „interactive“. Dies bedeutet, dass das Dokument mit dem Laden fertig ist und dass es fertig geparsed wurde. Alle anderen Ressourcen, wie z.B. Styles, Bilder u.s.w. sind noch am Laden (Mozilla Developer Network and indivi-dual contributors 2016d). </P
></TD
></TR
><TR
><TD
valign="top"
><P
>„domContentLoadedE-ventStart“ </P
></TD
><TD
valign="top"
><P
>Das Attribut markiert den Zeitpunkt kurz bevor der Parser das „domContentLoaded“-Event setzen wird. Dies passiert unmit-telbar nachdem alle Skripte die für das Parsing ausgeführt wer-den müssen, ausgeführt wurden (Mozilla Developer Network and individual contributors 2016c). „DomContentLoaded“ ist ein Event das dann erscheinen wird, wenn das HTML Doku-ment komplett heruntergeladen und geparsed wurde, ohne auf Styles, Bilder u.s.w. zu warten (Mozilla Developer Network and individual contri-butors 2016e). Dieses Attribut wird in der jQuery JavaScript-Bibliothek für den Startpunkt der Ausfüh-rung von JavaScript Dateien benutzt, die innerhalb der „$( document ).ready().“ geschrieben sind. In diesem Fall werden die Skripte ausgeführt, wenn das DOM komplett geladen wurde (The jQuery Foundation 2016a), (The jQuery Foundation 2016b). </P
></TD
></TR
><TR
><TD
valign="top"
><P
>„domContentLoadedEven-tEnd“ </P
></TD
><TD
valign="top"
><P
>Das Attribut wird den Zeitpunkt markieren, an dem alle Skripte, die ausgeführt werden müssen, ausgeführt sind. Deshalb ist die Zeit, die zwischen domContentLoadedEventStart und dom-ContentLoadedEventEnd benötigt wird – die Zeit für die Aus-führung von JavaScript Dateien, die nach dem domContent-LoadedEventStart Attribut ausgeführt werden müssen. </P
></TD
></TR
><TR
><TD
valign="top"
><P
>„domComplete“ </P
></TD
><TD
valign="top"
><P
>Das Attribut wird gesetzt, wenn der Parser das Dokument fertig bearbeitet hat. In diesem Moment wird sich der Document.readyState auf den Status „complete“ ändern. Dies bedeutet, dass das Hauptdokument und alle anderen Ressour-cen fertig geladen sind (Mozilla Developer Network and indi-vidual contributors 2016d). </P
></TD
></TR
><TR
><TD
valign="top"
><P
>„loadingEventStart“ und „loadingEventEnd“ </P
></TD
><TD
valign="top"
><P
>Registriert den Zeitpunkt, an dem das „load“-Event für das Do-kument gesetzt wurde. Das „load“-Event wird erscheinen, wenn das Dokument und alle davon abhängigen Ressourcen fertig </P
></TD
></TR
></TABLE
><TABLE
border=0 cellspacing=0 cellpadding=2
><TR
><TD