Per­for­mance im Web

Die Zeit, die Ih­re Web­sei­te bis zur An­zei­ge be­nö­tigt, ist ei­ne der kri­tischs­ten Kom­po­nen­ten in der Webent­wick­lung. Nicht nur, dass Be­nut­zer lie­ber zur Kon­kur­renz wech­seln, statt zu war­ten, auch Such­ma­schi­nen­be­trei­ber be­stra­fen lang­sa­me Sei­ten. Ge­nug Gründ

SCREENGUIDE - - Inneres - TexT: Se­bas­ti­an Sprin­ger

So op­ti­mie­ren Sie Ih­re Web­site

Bis zu dem Zeit­punkt, an dem ein Be­nut­zer Ih­re Sei­te ver­wen­den kann, gibt es vie­le Stel­len, an de­nen Sie Ge­schwin­dig­keit ein­bü­ßen kön­nen. Es emp­fiehlt sich zu wis­sen, wie Ihr Brow­ser Web­sei­ten ver­ar­bei­tet, wie Sie die­sen Vor­gang ana­ly­sie­ren und an wel­chen Stel­len Sie ein­grei­fen kön­nen. Die­ses Ver­ständ­nis ist wich­tig, um an den rich­ti­gen Stell­schrau­ben zu dre­hen, da­mit Ih­re Web­site er­folg­rei­cher wird. Da­mit ver­mei­den Sie au­ßer­dem, Mi­kro­op­ti­mie­run­gen zu be­trei­ben, die we­nig Er­folg ver­spre­chen, da­für aber viel Auf­wand ver­ur­sa­chen.

PER­FOR­MANCE-GRUND­LA­GEN

Be­vor Sie mit der Ana­ly­se Ih­rer Web­site be­gin­nen, soll­ten Sie sich zu­nächst mit ei­ni­gen grund­le­gen­den Kon­zep­ten und Werk­zeu­gen ver­traut ma­chen. Ihr wich­tigs­tes Hilfs­mit­tel bei der Per­for­mance-Ana­ly­se ei­ner Web­sei­te ist Ihr Brow­ser, ge­nau­er ge­sagt sei­ne Ent­wick­ler­werk­zeu­ge. Al­le mo­der­nen Brow­ser ver­fü­gen über die­se Hilfs­mit­tel, mit de­nen Sie so­wohl die Struk­tur Ih­rer Sei­te als auch den Ja­vaS­cript-Qu­ell­code und den Netz­werk-Ver­kehr ana­ly­sie­ren kön­nen. Die­se Werk­zeu­ge se­hen je nach Brow­ser an­ders aus und wei­sen auch Un­ter­schie­de im Funk­ti­ons­um­fang auf. Die hier ge­zeig­ten Bei­spie­le ver­wen­den die Chro­me De­ve­l­oper Tools. Die vor­ge­stell­ten Fea­tu­res fin­den Sie in ähn­li­cher Au­s­prä­gung un­ter et­was an­de­ren Be­zeich­nun­gen je­doch auch in al­len an­de­ren Brow­sern. Auf Win­dows-Sys­te­men er­rei­chen Sie die Ent­wick­lerTools im Fi­re­fox, Chro­me und In­ter­net Ex­plo­rer über die F12-Tas­te und in Ope­ra über STR + Shift + I. Auf ei­nem MAC funk­tio­niert das über die Tas­ten­kom­bi­na­ti­on Cmd + Opt + I. Ein wei­te­res hilf­rei­ches Werk­zeug, das Ih­nen Ihr Brow­ser zur Ver­fü­gung stellt, ist die Na­vi­ga­ti­on Ti­ming API. Hier­bei han­delt es sich um ei­ne Ob­jekt­struk­tur, die ex­ak­te Zeits­tem­pel für ver­schie­de­ne Sta­tio­nen im La­de­zy­klus ei­ner Web­sei­te lie­fert. Um bei­spiels­wei­se den Zeit­punkt her­aus­zu­fin­den, an dem der Brow­ser be­ginnt, die Res­sour­cen Ih­rer Sei­te her­un­ter­zu­la­den, nut­zen Sie die na­vi­ga­ti­onStart-Ei­gen­schaft des per­for­mance. ti­ming-Ob­jekts. Der Wert die­ses Ob­jekts ist ei­ne Ganz­zahl, die den UNIX-Ti­mestamp die­ses Er­eig­nis­ses an­gibt. Ana­ly­se­werk­zeu­ge wie bei­spiels­wei­se Goog­le Ana­ly­tics nut­zen die Na­vi­ga­ti­on Ti­ming API, um die La­de­zei­ten Ih­rer Sei­te auf­zu­zeich­nen. Mit die­ser Kom­bi­na­ti­on von Werk­zeu­gen er­hal­ten Sie nicht nur die Zei­ten Ih­rer lo­ka­len Um­ge­bung, son­dern die Sta­tis­ti­ken von rea­len Nut­zern auf Ih­rer Pro­duk­ti­v­um­ge­bung. Die­se Wer­te sind we­sent­lich aus­sa­ge­kräf­ti­ger als Ih­re lo­ka­le Te­st­um­ge­bung. Hier kom­men die Netz­werk­ge­schwin­dig­keit und die Leis­tungs­fä­hig­keit der End­ge­rä­te viel deut­li­cher zum Tra­gen. Au­ßer­dem gibt es bei der Ana­ly­se von Soft­ware kei­ne bes­se­re Da­ten­quel­le als rea­le Nut­zer­da­ten. Ha­ben Sie al­so die Mög­lich­keit, in Ih­rer Ap­pli­ka­ti­on Werk­zeu­ge wie Goog­le Ana­ly­tics zu ver­wen­den, soll­ten Sie die­se auch für die Per­for­mance-Ana­ly­se nut­zen. Werk­zeu­ge wie zum Bei­spiel Pa­geSpeed In­sights von Goog­le ge­ben Ih­nen wei­te­re Ein­bli­cke in die Per­for­mance Ih­rer Ap­pli­ka­ti­on (Abb. 1). Pa­geSpeed In­sights ver­gibt bei­spiels­wei­se Punk­te für die Um­set­zung Ih­rer Sei­te [goo.gl/S80a­jQ]. Sie kön­nen ins­ge­samt 100 Punk­te er­rei­chen. Für je­den Aspekt, der die Be­nutz­bar­keit oder Per­for­mance Ih­rer Web­sei­te ein­schränkt, sam­meln Sie Mi­nus­punk­te. Die Pro­blem­fel­der wer­den je nach Ein­fluss in un­ter­schied­li­che Ka­te­go­ri­en wie „Be­he­bung er­for­der­lich” oder „Be­he­bung emp­foh­len” ein­ge­ord­net. Zu vie­len die­ser Emp­feh­lun­gen er­hal­ten Sie auf den fol­gen­den Sei­ten wei­te­re Hin­ter­grund­in­for­ma­tio­nen. Zu­sätz­lich zur Pa­geSpeed-In­sights-Web­sei­te kön­nen Sie sich auch ei­ne Chro­me Ex­ten­si­on in­stal­lie­ren, mit der Sie die Ana­ly­se Ih­rer Web­sei­te lo­kal durch­füh­ren kön­nen. Die­se Va­ri­an­te ist be­son­ders in­ter­es­sant, wenn Sie an ei­nem nicht öf­fent­li­chen Pro­jekt ar­bei­ten.

DIE REI­SE BE­GINNT – DER DOWN­LOAD DER RES­SOUR­CEN

Da­mit ei­ne Web­sei­te dar­ge­stellt wer­den kann, müs­sen ver­schie­de­ne Res­sour­cen wie HTML-, CSS-, Ja­vaS­cript- und Me­di­en­da­tei­en her­un­ter­ge­la­den wer­den. Die­se wer­den an­schlie­ßend der Rei­he nach vom Brow­ser ver­ar­bei­tet. Je nach Netz­werk­ver­bin­dung des Be­nut­zers kann die­se Pha­se ent­schei­dend zum Er­folg oder Miss­er­folg ei­ner Web­sei­te bei­tra­gen. Die Per­for­mance des Down­loads hängt von zahl­rei­chen Fak­to­ren ab, die sich auch ge­gen­sei­tig be­ein­flus­sen. Al­len vor­an steht die Band­brei­te des an­ge­schlos­se­nen End­ge­räts. Des­halb ist es wich­tig, dass Sie die Ziel­grup­pe der Web­site mög­lichst ge­nau ken­nen. Wird Ih­re Si­te von vie­len mo­bi­len Be­nut­zern ver­wen­det, oder wird sie eher auf Desk­top-Rech­nern an­ge­zeigt? Sie soll­ten Ihr Pro­jekt mit ei­ner Vor­stel­lung da­zu be­gin­nen, auf wel­chen Kun­den­kreis es ab­zielt und auf wel­chen Ge­rä­ten es ver­wen­det wird. Die­se Hy­po­the­se kön­nen Sie dann über­prü­fen, nach­dem Sie das Pro­jekt ver­öf­fent­licht ha­ben, in­dem Sie ein Ana­ly­se-Tool ein­set­zen. Je nach­dem, wel­chen Kun­den­kreis Sie kon­kret an­spre­chen wol­len, müs­sen Sie un­ter­schied­li­chen Aspek­ten mehr Auf­merk­sam­keit wid­men. Ei­ni­ge Best Prac­tices gel­ten je­doch für al­le Um­ge­bun­gen. Beim Down­load von Res­sour­cen wird zwi­schen blo­ckie­ren­den und nicht blo­ckie­ren­den In­hal­ten un­ter­schie­den. So lan­ge nicht al­le blo­ckie­ren­den In­hal­te her­un­ter­ge­la­den und ver­ar­bei­tet wur­den, stellt der Brow­ser nichts dar. Hier­zu zäh­len die HTML-, CSS- und man­che Ja­vaS­cript-Da­tei­en. Das be­deu­tet: Je schnel­ler die­se Da­tei­en zur Ver­fü­gung ste­hen, des­to schnel­ler wird die Sei­te an­ge­zeigt. Mo­der­ne Brow­ser sind in der La­ge, meh­re­re Da­tei­en par­al­lel her­un­ter­zu­la­den. Die An­zahl der par­al­le­len An­fra­gen ist je­doch pro Do­main je nach Brow­ser li­mi­tiert. Meist liegt die­se Be­schrän­kung zwi­schen 6 und 8 Ver­bin­dun­gen. Aber nicht nur pro Do­main, son­dern auch die An­zahl der ge­sam­ten An­fra­gen ist be­schränkt. Die­se Li­mi­tie­rung liegt meist zwi­schen 15 und 20. Kon­kret be­deu­tet das, dass sich die Ver­bin­dun­gen zu ei­nem Web­ser­ver ge­gen­sei­tig aus­brem­sen, so­bald die­ses Li­mit über­schrit­ten wird. Er­laubt Ihr Brow­ser ma­xi­mal 6 Ver­bin­dun­gen, muss der Down­load der sieb­ten Res­sour­ce so lan­ge war­ten, bis ein an­de­rer Down­load ab­ge­schlos­sen ist. Bei ei­ner grö­ße­ren Web­sei­te kön­nen hier schon 50 bis über 100 An­fra­gen zu­sam­men­kom­men. Ei­nen ers­ten Über­blick bie­ten Ih­nen die Ge­samt­zahl der aus­ge­führ­ten An­fra­gen und die über­tra­ge­ne Da­ten­men­ge. Die­se In­for­ma­tio­nen fin­den Sie in den Chro­me De­ve­l­oper Tools in der Fuß­zei­le des Net­work-Tabs. Ab­hän­gig da­von, wie vie­le Me­di­en­da­tei­en Sie mit Ih­rer Sei­te aus­lie­fern, kann die Grö­ße und auch die An­zahl der Re­quests stark va­ri­ie­ren. Er­war­ten Sie je­doch mo­bi­le Be­nut­zer, soll­ten Sie dar­auf ach­ten, dass sich die zu über­tra­gen­de Da­ten­men­ge ma­xi­mal auf we­ni­ge Me­ga­byte oder dar­un­ter be­schränkt. Die An­zahl der Re­quests soll­te im un­te­ren zwei­stel­li­gen Be­reich lie­gen. Nach­dem Sie sich nun ei­nen ers­ten Über­blick ver­schafft ha­ben, geht es an die de­tail­lier­te Ana­ly­se der An­fra­gen. Im Netz­wer­kTab Ih­rer Ent­wick­ler-Tools er­hal­ten Sie für je­de An­fra­ge de­tail­lier­te In­for­ma­tio­nen in ei­ner ta­bel­la­ri­schen Form. Hier se­hen Sie bei­spiels­wei­se den Sta­tus­code der Ant­wort, das ver­wen­de­te Protokoll, von wem die An­fra­ge aus­ging, die Grö­ße und die Zeit (Abb. 2). Zu­sätz­lich da­zu se­hen Sie am Zei­len­en­de ei­ne gra­fi­sche Darstel­lung der An­fra­ge in zeit­li­cher Re­la­ti­on zu den üb­ri­gen An­fra­gen. Für ei­ne ge­naue­re Be­trach­tung kom­men hier vor al­lem die An­fra­gen in­fra­ge, die viel Zeit in An­spruch ge­nom­men ha­ben, al­so mit ei­nem lan­gen Bal­ken dar­ge­stellt wer­den. Zu den wich­tigs­ten In­for­ma­tio­nen ge­hört hier vor al­lem die Grö­ße der An­fra­ge. Die­se wird in der Si­ze-Spal­te mit zwei Zah­len an­ge­ge­ben (je nach Brow­ser und Ver­si­on wird ge­ge­be­nen­falls auch nur ei­ne Zahl dar­ge­stellt). Die ers­te steht für die Da­t­ei­grö­ße, die über­mit­telt wur­de. Die zwei­te steht für die Grö­ße des In­halts. Bei­de Zah­len kön­nen aus ver­schie­de­nen Grün­den von­ein­an­der ab­wei­chen. So ist die Grö­ße ei­ner An­fra­ge, die aus dem Ca­che Ih­res Brow­sers aus­ge­lie­fert wur­de, klei­ner als ihr In­halt. Glei­ches gilt, wenn die Da­tei vom Ser­ver kom­pri­miert über­tra­gen wur­de. Auch bei der Zeit, die ei­ne An­fra­ge ge­dau­ert hat, er­hal­ten Sie zwei Zah­len (wie­der­um ab­hän­gig vom Brow­ser und von der Ver­si­on). Der ers­te Wert steht für die Ge­samt­zeit, die die An­fra­ge in An­spruch ge­nom­men hat. Die zwei­te Zahl, die La­tenz, be­zeich­net die Zeit zwi­schen dem Start der An­fra­ge und der Ant­wort des Ser­vers. Ei­ne An­fra­ge an ei­nen Ser­ver glie­dert sich in un­ter­schied­li­che Pha­sen, die Ih­nen Ihr Brow­ser ein­zeln auf­schlüs­selt und mit den ent­spre­chen­den Zei­ten ver­sieht. Die ein­zel­nen Schrit­te ei­nes sol­chen Down­loads sind (Abb. 3):

• Qu­eu­eing: Die An­fra­ge war­tet, da kein Down­load-Slot frei ist oder ih­re Prio­ri­tät als nied­rig ein­ge­stuft wur­de.

• Stal­led: Die­ser Schritt be­zeich­net die War­te­zeit, bis die An­fra­ge ge­sen­det wer­den konn­te.

• DNS Look­up: Die Auf­lö­sung des Do­main-Na­mens über ei­ne DNS-An­fra­ge be­nö­tigt eben­falls Zeit. Die­se An­fra­ge wird je­doch nur ein­mal pro Do­main durch­ge­führt.

• Initi­al Con­nec­tion: Die ge­sam­te Zeit, die be­nö­tigt wird, um die Ver­bin­dung auf­zu­bau­en. Dies be­inhal­tet die TCP-Hand­shakes und SSL-Hand­shakes.

• SSL: Da­mit ei­ne ver­schlüs­sel­te Ver­bin­dung zwi­schen Cli­ent und Ser­ver auf­ge­baut wer­den kann, muss ein so­ge­nann­ter SSLHand­shake durch­ge­führt wer­den. Die­ser dau­ert zwar et­was, weil ver­schie­de­ne Da­ten zwi­schen Ser­ver und Cli­ent hin und her ge­schickt wer­den, die Op­ti­on, kri­ti­sche Da­ten über ei­ne un­ver­schlüs­sel­te Ver­bin­dung zu sen­den, soll­ten Sie je­doch nicht er­wä­gen. • Pr­o­xy Ne­go­tia­ti­on: Falls der Cli­ent hin­ter ei­nem Pr­o­xy-Ser­ver liegt, wird zu­nächst zu die­sem ei­ne Ver­bin­dung auf­ge­baut. • Re­quest sent: Die­ser Ab­schnitt gibt an, wie lan­ge es ge­dau­ert hat, die An­fra­ge zu sen­den. • Ser­vice­Wor­ker Pre­pa­ra­ti­on: Chro­me und an­de­re mo­der­ne Brow­ser un­ter­stüt­zen mitt­ler­wei­le Ser­vice­Wor­ker. Das sind Pro­zes­se, die im Brow­ser ab­lau­fen und An­fra­gen ab­fan­gen und so­fort be­ant­wor­ten kön­nen. Die­ser Schritt gibt an, wie lan­ge es ge­dau­ert hat, den Ser­vice­Wor­ker-Pro­zess zu star­ten.

• Re­quest to Ser­vice­Wor­ker: Nach­dem der Ser­vice­Wor­ker ge­star­tet ist, gibt die­ser Ab­schnitt Aus­kunft dar­über, wie lan­ge es ge­dau­ert hat, die An­fra­ge an den Pro­zess zu sen­den.

• Wait­ing (TTFB): Die­se Zeit­an­ga­be be­zeich­net die War­te­zeit auf die Ant­wort des Ser­vers. Die Ab­kür­zung TTFB steht da­bei für „Ti­me To First By­te”.

• Con­tent Down­load: Der Con­tent Down­load steht für die Zeit, die es dau­ert, die kom­plet­te Ant­wort des Ser­vers her­un­ter­zu­la­den. Je nach Art der Ver­bin­dung müs­sen nicht sämt­li­che Schrit­te durch­ge­führt wer­den. Es kann al­so pas­sie­ren, dass Sie den ein oder an­de­ren Ein­trag nicht in Ih­rem Netz­werk-Dia­gramm fin­den. Die Na­vi­ga­ti­on Ti­ming API sieht zur Mes­sung der Netz­werk­per­for­mance zahl­rei­che Zeit­an­ga­ben vor. Die­se rei­chen vom na­vi­ga­ti­onStart über die An­ga­ben zum Un­load des vor­he­ri­gen Do­ku­ments über Re­di­rects bis zum fet­chStart, der an­gibt, wann mit dem ei­gent­li­chen Down­load be­gon­nen wird. Der in­itia­le Down­load glie­dert sich ana­log zu den An­ga­ben in den De­ve­l­oper Tools in ver­schie­de­ne Pha­sen wie do­mainLook­up, con­nect, se­cu­reCon­nec­tion, re­quest und re­s­pon­se. Für die meis­ten Pha­sen er­hal­ten Sie so­wohl den Start- als auch den End-Zeit­punkt für ei­ne ge­naue Mes­sung. Zur Ver­bes­se­rung der Netz­werk-Per­for­mance gibt es zahl­rei­che Best Prac­tices. Al­lem vor­an gilt es, die zu über­mit­teln­de Da­ten­men­ge zu re­du­zie­ren. Für die­sen Zweck kom­men Werk­zeu­ge wie ugil­fy [goo.gl/IN5WjD] für Ja­vaS­cript und cle­an-css [goo.gl/ M9fIPf] für CSS zum Ein­satz. Sie ve­rän­dern den Qu­ell­code, um Zei­chen ein­zu­spa­ren, und re­du­zie­ren so die Da­t­ei­grö­ße si­gni­fi­kant. Ug­li­fy löscht bei­spiels­wei­se al­le un­nö­ti­gen Whi­te­s­paceZei­chen wie Zei­len­um­brü­che oder Ein­rü­ckun­gen. Au­ßer­dem wer­den Kom­men­ta­re ent­fernt, da sie für das Aus­füh­ren des Ja­vaS­cript-Qu­ell­codes nicht er­for­der­lich sind. Schließ­lich ist Ug­li­fy auch in der La­ge, die Na­men von Va­ria­blen zu ver­kür­zen. So wird bei­spiels­wei­se aus der Va­ria­blen „user­na­me” ein „a”. Die­se Um­be­nen­nung fin­det kon­sis­tent statt, so­dass der Qu­ell­code nach dem Ein­griff im­mer noch lauf­fä­hig ist. Wei­te­re Mög­lich­kei­ten zur Per­for­man­ce­ver­bes­se­rung sind:

• Ver­wen­dung des Brow­ser-Ca­ches: Durch das Set­zen der kor­rek­ten He­a­der­infor­ma­tio­nen auf dem Ser­ver tei­len Sie dem Brow­ser mit, dass er be­stimm­te Da­tei­en lo­kal zwi­schen­spei­chern kann. Da­mit re­du­zie­ren Sie die An­zahl der Da­tei­en, die her­un­ter­ge­la­den wer­den müs­sen, wenn die Sei­te er­neut be­sucht wird. Ca­ches kom­men vor al­lem bei sta­ti­schen Da­ten zum Ein­satz, die sich ent­spre­chend sel­ten än­dern. Durch die Wahl der rich­ti­gen Le­bens­zeit ei­nes Ca­che-Ein­trags kön­nen je­doch auch Da­tei­en mit ei­ner hö­he­ren Än­de­rungs­fre­quenz zwi­schen­ge­spei­chert wer­den.

• Zu­sam­men­fas­sen von Da­tei­en: Werk­zeu­ge wie Ugil­fy oder Web­pack er­mög­li­chen es Ih­nen, meh­re­re Ja­vaS­cript-Da­tei­en zu ei­ner grö­ße­ren Da­tei zu kom­bi­nie­ren. Die Zu­sam­men­fas­sung hat vor al­lem bei HTTP/1 den Vor­teil, dass Sie sich den Over­head des mehr­ma­li­gen Ver­bin­dungs­auf­baus spa­ren. Bei HTTP in der Ver­si­on 2 kön­nen be­ste­hen­de Ver­bin­dun­gen wie­der­ver­wen­det wer­den, so­dass die Ver­bin­dun­gen hier we­ni­ger pro­ble­ma­tisch sind (sie­he In­fo­kas­ten). Ne­ben Ja­vaS­cript-Da­tei­en kön­nen Sie auch CSS-Da­tei­en auf ähn­li­che Wei­se kom­bi­nie­ren und aus Bil­dern so­ge­nann­te Spri­tes ge­ne­rie­ren. Ein Spri­te ent­hält meh­re­re Bil­der. Bei der An­zei­ge zeigt der Brow­ser mit CSS nur ei­nen be­stimm­ten Aus­schnitt des zu­sam­men­ge­fass­ten Bil­des, so­dass der Be­nut­zer von den üb­ri­gen nichts sieht.

• Kom­pri­mier­te Über­tra­gung ak­ti­vie­ren: Brow­ser so­wie Ser­ver un­ter­stüt­zen gzip-kom­pri­mier­te Über­tra­gung. Der Ser­ver kom­pri­miert die an­ge­frag­te Da­tei, be­vor er sie zum Cli­ent sen­det. Die­se Me­tho­de kos­tet zwar mehr CPU-Res­sour­cen durch die Kom­pri­mie­rung und De­kom­pri­mie­rung. Die ein­ge­spar­te Über­tra­gungs­band­brei­te über­wiegt in die­sem Fall je­doch. Im Fall ei­nes Apa­che-Web­ser­vers kön­nen Sie die Kom­pri­mie­rung ganz ein­fach über das mo­d_­de­fla­te-Mo­dul ak­ti­vie­ren. Für die Ver­ar­bei­tung von Ja­vaS­cript-, CSS- und HTML-Da­tei­en müs­sen Sie le­dig­lich in Ih­rer .htac­cess-Da­tei fol­gen­den Co­de ein­fü­gen:

“The le­vel of stress cau­sed by mo­bi­le de­lays was com­pa­ra­ble to watching a hor­ror mo­vie.” Erics­son Mo­bi­li­ty Re­port [goo.gl/KqZZe9]

.htac­cess <IfMo­du­le mo­d_­de­fla­te.c> <filesMatch "\.(js|css|html)$"> Se­tOut­pu­tFil­ter DEFLATE </filesMatch> </IfMo­du­le>

DER CRITICAL RENDERING PATH

Der Brow­ser lädt zu­nächst die in­itia­le HTML-Da­tei her­un­ter. Sie ent­hält die In­for­ma­tio­nen über den Auf­bau der Sei­te und die Ver­wei­se auf die üb­ri­gen Res­sour­cen. Al­le Ak­tio­nen, die zwi­schen dem Emp­fang der Res­sour­cen und der Darstel­lung auf dem Bild­schirm lie­gen, wer­den als Critical Rendering Path be­zeich­net. Schon die Darstel­lung ei­ner ein­fa­chen Web­sei­te be­deu­tet ei­ne Men­ge Ar­beit für den Brow­ser. Der Auf­wand, um die In­hal­te dar­zu­stel­len, wächst mit ih­rem Um­fang und der Kom­ple­xi­tät. Ne­ben dem Res­sour­cen-Down­load bie­tet der Critical Rendering Path das meis­te Op­ti­mie­rungs­po­ten­zi­al. Er be­steht aus ins­ge­samt fünf Schrit­ten: 1. Zu­nächst wird die DOM-Struk­tur er­zeugt. 2. Da­mit die In­hal­te kor­rekt dar­ge­stellt wer­den kön­nen, muss

au­ßer­dem das CSSOM auf­ge­baut wer­den. 3. Aus die­sen bei­den Struk­tu­ren ent­steht der Ren­der Tree. 4. An­hand der ge­sam­mel­ten In­for­ma­tio­nen be­rech­net der Brow­ser das Lay­out, al­so die Di­men­sio­nen und die Po­si­tio­nie­rung der ein­zel­nen Ele­men­te. 5. Nach­dem der Brow­ser al­le In­for­ma­tio­nen je­des Ele­ments be­sitzt, kann er mit der Darstel­lung be­gin­nen. Die­se Schrit­te durch­läuft der Brow­ser bei je­der Darstel­lung ei­ner Web­sei­te. Erst nach Ab­schluss al­ler Schrit­te sieht der Be­nut­zer et­was von der Sei­te. Da­bei nimmt je­der Schritt un­ter­schied­lich viel Zeit in An­spruch, die es zu mi­ni­mie­ren gilt. Für die Ana­ly­se des Critical Rendering Paths kommt in den Chro­me De­ve­l­oper Tools der Per­for­mance-Tab (auch Ti­me­li­ne-Tab) zum Ein­satz. Hier wer­den al­le re­le­van­ten Er­eig­nis­se und ihr zeit­li­cher Ablauf ge­sam­melt (Abb. 4).

AUF­BAU DES DO­CU­MENT OB­JECT MO­DELS (DOM)

Das DOM ist ei­ne Baum­struk­tur, die aus den Kno­ten ei­ner Web­sei­te er­zeugt wird. Es dient ne­ben der Vor­be­rei­tung zur Darstel­lung ei­ner Web­sei­te auch als Schnitt­stel­le für Ja­vaS­cript zur In­ter­ak­ti­on mit der Sei­ten­struk­tur. Der Brow­ser durch­läuft bei der Er­zeu­gung des DOMs ei­ne Rei­he von Schrit­ten: • Kon­ver­tie­rung: Der Brow­ser lädt den HTML-Qu­ell­code vom Ser­ver her­un­ter. Die­ser liegt zu­nächst in By­tes vor und wird vom Brow­ser in les­ba­re Zei­chen um­ge­wan­delt. • To­ke­ni­zing: Der Qu­ell­text der Sei­te wird vom Brow­ser auf ihn be­kann­te Zei­chen­fol­gen, die so­ge­nann­ten To­kens, durch­sucht. Die ver­füg­ba­ren To­kens wer­den vom W3C-Stan­dard für HTML vor­ge­ge­ben. • Lex­ing: Die ge­fun­de­nen To­kens wer­den in Kno­ten um­ge­wan­delt. Das sind Ob­jek­te, die je nach Art des To­kens be­stimm­te Ei­gen­schaf­ten be­sit­zen und ge­wis­sen Re­geln un­ter­wor­fen sind. • DOM-Er­stel­lung: Die noch fla­che To­ken-Struk­tur wird im letz­ten Schritt in ei­ne Baum­struk­tur, das DOM, um­ge­wan­delt. Den Auf­bau des DOMs kön­nen Sie so­wohl mit Ih­ren Ent­wick­lerWerk­zeu­gen als auch über die Na­vi­ga­ti­on Ti­ming API ana­ly­sie­ren. In den Chro­me De­ve­l­oper Tools fin­den Sie die­sen Schritt des Critical Rendering Paths un­ter dem Er­eig­nis Par­se HTML, das al­le vier Ver­ar­bei­tungs­schrit­te zu­sam­men­fasst. Die Na­vi­ga­ti­on Ti­ming API sieht zwei Zeits­tem­pel für die Ana­ly­se der DOM-Er­zeu­gung vor: • domLoa­ding: Die­ser Zeits­tem­pel be­zeich­net den Zeit­punkt, an dem der Brow­ser mit dem Par­sen der HTML-Struk­tur be­ginnt. • domIn­ter­ac­tive: Zu die­sem Zeit­punkt ist das DOM fer­tig­ge­stellt. Für die Per­for­mance der DOM-Er­stel­lung gibt es ei­ne ein­fa­che Re­gel: Je um­fang­rei­cher die zu ver­ar­bei­ten­de HTML-Struk­tur ist, des­to län­ger dau­ert ih­re Ver­ar­bei­tung. Für Sie be­deu­tet das, dass Sie ver­su­chen müs­sen, die Struk­tur so klein wie mög­lich zu hal­ten. Grund­sätz­lich soll­ten Sie ver­su­chen, in Ih­rer Struk­tur nicht un­nö­tig vie­le Con­tai­ner in­ein­an­der­zu­schach­teln. In den meis­ten Fäl­len kön­nen Sie Ihr Ziel auch mit ein we­nig CSS er­rei­chen. Ge­ra­de das Flex­box- und das Grid-Lay­out sind hier hilf­reich. Stel­len Sie sich die Fra­ge: Was be­nö­tigt ein Be­nut­zer initi­al auf der Sei­te, und was kann un­ter Um­stän­den dy­na­misch nach­ge­la­den wer­den? Al­les, was sich au­ßer­halb des sicht­ba­ren Be­reichs be­fin­det, ist ein po­ten­zi­el­ler Kan­di­dat für ein spä­te­res Nach­la­den. Per Ja­vaS­cript

kön­nen Sie den DOM-Baum nach dem initia­len La­de­vor­gang er­wei­tern und wei­te­re Be­rei­che Ih­rer Sei­te la­den. Ein be­kann­tes Bei­spiel ist La­zy Loa­ding bei Bil­dern. Hier­bei wer­den Bil­der auf ei­ner Web­sei­te erst dann dy­na­misch nach­ge­la­den, wenn der Be­nut­zer beim Scrol­len in die Nä­he des Bil­des kommt. Das DOM wird da­durch klei­ner ge­hal­ten und kann schnel­ler ver­ar­bei­tet und dar­ge­stellt wer­den. Das DOM ent­hält le­dig­lich die Struk­tur der Sei­te. Wür­den Sie die­se im Brow­ser dar­stel­len, wür­de sich für den Be­nut­zer ein recht un­an­sehn­li­ches Bild er­ge­ben. Aus die­sem Grund be­nö­tigt der Brow­ser das Sty­ling von CSS, das vor­gibt, wie die Kno­ten des DOM im Brow­ser dar­ge­stellt wer­den sol­len.

ER­ZEU­GUNG DES CSS OB­JECT MO­DELS (CSSOM)

Was für die HTML-Struk­tur gilt, trifft auch in ähn­li­cher Wei­se für die CSS-Struk­tur zu. Wie der Na­me schon an­deu­tet, han­delt es sich um ein Ob­ject Mo­del, al­so ei­ne Baum­struk­tur von Kno­ten. Die­se le­gen das Aus­se­hen der DOM-Struk­tur im Brow­ser fest. Fin­det der Brow­ser beim Par­sen des HTML-Co­des ei­nen Ver­weis auf ein Sty­le­s­heet, be­ginnt er mit dem Down­load der Res­sour­ce und ver­ar­bei­tet an­schlie­ßend den CSS-Qu­ell­code. Da­bei geht der Brow­ser in den­sel­ben Schrit­ten wie beim DOM vor. Al­so Kon­ver­tie­rung, To­ke­ni­zing, Lex­ing und schließ­lich Auf­bau der Baum­struk­tur. Wo im DOM der HTML-Kno­ten die Wur­zel bil­det, sind dies im CSSOM die all­ge­mein­gül­ti­gen Sty­les. Je wei­ter sich der Baum in sei­ne Äs­te ver­zweigt, des­to spe­zi­fi­scher wer­den die Sty­les. Die­se Struk­tur er­klärt auch die An­wen­dung der CSS-Re­geln von all­ge­mein­gül­tig bis ins De­tail, wo­bei die Re­geln der Kind­kno­ten die all­ge­mei­ne­ren Re­geln über­schrei­ben. In der Ti­me­li­ne des Per­for­mance-Tabs fin­den Sie den Auf­bau des CSSOM un­ter dem Er­eig­nis „Re­cal­cu­la­te Style”. Zur Ver­bes­se­rung der Per­for­mance gilt auch hier: we­ni­ger ist mehr. Je we­ni­ger CSS-Qu­ell­code Ihr Brow­ser zu ver­ar­bei­ten hat, des­to schnel­ler ist das CSSOM ein­satz­be­reit, und der Brow­ser kann mit der Darstel­lung der Sei­te be­gin­nen. Auch hier soll­ten Sie sich wie­der­um die Fra­ge stel­len: Wel­che CSS-Re­geln wer­den kon­kret für die Sei­te ge­braucht? Vie­le Web­sei­ten lie­fern nicht be­nö­tig­tes CSS mit aus. Die­ser Ef­fekt wird vor al­lem durch die Ver­wen­dung von Bi­blio­the­ken wie Boot­strap ver­stärkt. Bei die­sen han­delt es sich um all­ge­mei­ne Lö­sun­gen für Lay­out und Funk­tio­na­li­tät von Web­sei­ten. Das be­deu­tet, sie ver­fü­gen über sehr viel Qu­ell­code, den Sie auf Ih­rer Sei­te nicht nut­zen. Im Fall der Boot­strap-Li­bra­ry kön­nen Sie über get­boot­strap.com/cust­o­mi­ze Fea­tu­res ab­wäh­len, um das ge­ne­rier­te Pa­ket zu ver­klei­nern. Ein wei­te­res Mit­tel, um die Per­for­mance bei der CSSOM-Er­zeu­gung zu ver­bes­sern, ist die Ver­wen­dung von mög­lichst ein­fa­chen und prä­zi­sen Se­lek­to­ren. Ge­ra­de das Ver­schach­teln von vie­len Se­lek­to­ren kos­tet beim Er­zeu­gen des CSSOM un­nö­tig viel Zeit.

Ei­ne bes­se­re Lö­sung ist die Ver­ga­be von id- und class-At­tri­bu­ten an die je­wei­li­gen HTML-Ele­men­te und de­ren Ver­wen­dung im CSS-Co­de. Ei­ne wei­te­re Mög­lich­keit zur Per­for­man­ce­ver­bes­se­rung bie­ten Me­dia Que­ries und Me­dia Ty­pes. Sie kön­nen ein Sty­le­s­heet mit ei­nem Me­dia Type ver­se­hen, um fest­zu­le­gen, für wel­che Um­ge­bung die­ses an­ge­wen­det wer­den soll. So gibt der Typ Print bei­spiels­wei­se an, dass die Sty­les nur beim Aus­dru­cken der Web­sei­te zur An­wen­dung kom­men sol­len. Mit Me­dia Que­ries kön­nen Sie das Ver­hal­ten Ih­res Brow­sers noch ge­nau­er steu­ern, in­dem Sie bei­spiels­wei­se ei­ne mi­ni­ma­le An­zei­ge­brei­te an­ge­ben, bei der die Sty­les zum Ein­satz kom­men. Me­dia Que­ries und Me­dia Ty­pes schrän­ken nur die Ver­wen­dung der Sty­les ein. Die Res­sour­cen wer­den vom Brow­ser auch her­un­ter­ge­la­den, wenn das Sty­le­s­heet nicht ver­wen­det wird. Oh­ne ein fer­tig auf­ge­bau­tes CSSOM stellt der Brow­ser noch nichts auf dem Bild­schirm dar, da sich an­sons­ten wäh­rend der An­zei­ge das Aus­se­hen der Sei­te nach­träg­lich gra­vie­rend än­dern wür­de und der Brow­ser zwei­mal den In­halt be­rech­nen müss­te. CSS blo­ckiert al­so grund­sätz­lich das Rendering der Sei­te.

JA­VAS­CRIPT IM CRITICAL RENDERING PATH

Wäh­rend die Er­zeu­gung des CSSOM nur das Ren­dern der Sei­te im Brow­ser blo­ckiert, hält Ja­vaS­cript den HTML-Par­ser kom­plett an. Stößt der Par­ser auf ein Script-Tag, hängt es da­von ab, ob es sich um In­li­ne-Ja­vaS­cript oder um ei­nen Ver­weis auf ei­ne ex­ter­ne Da­tei han­delt. Im zwei­ten Fall wird die­se zu­nächst her­un­ter­ge­la­den. Nach­dem die Quel­len vor­han­den sind, über­gibt der Brow­ser die Kon­trol­le an die Ja­vaS­cript-En­gi­ne. Das be­deu­tet, dass der Par­ser so­wohl beim Down­load als auch bei der Aus­füh­rung des Scripts pau­siert ist. Die­se Par­ser-Blo­ckie­rung ver­hin­dert al­so auch gleich­zei­tig das Rendering der Sei­te im Brow­ser. Nach­dem Ja­vaS­cript auf ei­nem noch un­fer­ti­gen DOM aus­ge­führt wird, ha­ben Sie auch nur Zu­griff auf die Kno­ten, die bis­her ver­ar­bei­tet wur­den. Aus die­sem Grund wer­den ge­ra­de in äl­te­ren Web­sei­ten die Script-Tags am En­de der Web­sei­te, vor dem schlie­ßen­den </bo­dy>, ein­ge­bun­den. Der HTML-Stan­dard sieht je­doch zwei recht hilf­rei­che At­tri­bu­te für das Script-Tag vor, die den Auf­bau des DOMs er­heb­lich be­schleu­ni­gen kön­nen. Ge­ben Sie das async-At­tri­but an, wird der Par­ser wäh­rend des Down­loads des Ja­vaS­cript-Qu­ell­codes nicht an­ge­hal­ten. Erst, wenn die Da­tei kom­plett her­un­ter­ge­la­den ist, über­nimmt die Ja­vaS­cript-En­gi­ne die Kon­trol­le. Ist der Par­sin­gPro­zess zu die­sem Zeit­punkt noch nicht ab­ge­schlos­sen, wird er blo­ckiert. Das de­fer-At­tri­but wie­der­um sorgt da­für, dass die Ja­vaS­cript-Ver­ar­bei­tung erst nach Ab­schluss des HTML-Par­sings statt­fin­det. Bei­de At­tri­bu­te kön­nen nur in Ver­bin­dung mit dem src-At­tri­but für ex­ter­ne Ja­vaS­cript-Da­tei­en ver­wen­det wer­den. Häu­fig wird die Aus­füh­rung des Ja­vaS­cript-Qu­ell­codes an das DOMCon­ten­tLoa­ded-Event ge­bun­den. Die Na­vi­ga­ti­on Ti­ming API sieht hier­für so­wohl den Start- als auch den End-Zeit­punkt für die­ses Er­eig­nis vor. Die Zeit­dif­fe­renz gibt an, wie lan­ge die Aus­füh­rung des Ja­vaS­cript-Qu­ell­codes ge­dau­ert hat.

ZU­SAM­MEN­FÜH­REN VON DOM UND CSSOM ZUM REN­DER TREE

DOM und CSSOM sind zu­nächst un­ab­hän­gig von­ein­an­der. Das DOM gibt die Struk­tur vor, das CSSOM die Sty­ling-Re­geln. Im Ren­der Tree wer­den bei­de Struk­tu­ren schließ­lich zu­sam­men­ge­führt. Der Ren­der Tree dient zur Darstel­lung auf dem Bild­schirm, muss al­so auch nur die Ele­men­te ent­hal­ten, die dem Be­nut­zer an­ge­zeigt wer­den. Nicht sicht­ba­re Ele­men­te wie me­ta-, link- oder script-Tags tau­chen im Ren­der Tree nicht auf. Für je­den Kno­ten im DOM wer­den die ent­spre­chen­den CSS-Re­geln ge­sucht und fest­ge­hal­ten, so­dass je­des Ele­ment im Ren­der Tree al­le er­for­der­li­chen Style-An­ga­ben be­sitzt. Zu den von Ih­nen de­fi­nier­ten CSS-Re­geln kom­men au­ßer­dem die vom Brow­ser vor­ge­ge­be­nen Stan­dard Sty­les. Die Er­zeu­gung des Ren­der Trees taucht nicht als se­pa­ra­tes Er­eig­nis in den De­ve­l­oper Tools auf, son­dern wird mit dem nächs­ten Schritt, der Lay­out-Be­rech­nung, zu­sam­men­ge­fasst. Für die Be­schleu­ni­gung des Ren­der Trees wer­den op­ti­mier­te DOM- und CSSOM-Struk­tu­ren be­nö­tigt. Schnel­le Ob­ject Mo­dels re­sul­tie­ren in ei­nem schnell auf­ge­bau­ten Ren­der Tree. Es gel­ten hier al­so die be­reits er­wähn­ten Op­ti­mie­rungs­hin­wei­se für HTML und CSS.

BE­RECH­NUNG DER LAY­OUT-AN­GA­BEN DER EIN­ZEL­NEN ELE­MEN­TE

Da­mit Ihr Brow­ser die gra­fi­sche Re­prä­sen­ta­ti­on Ih­rer Web­sei­te er­zeu­gen kann, be­nö­tigt er ge­naue In­for­ma­tio­nen dar­über, wie groß die ein­zel­nen Ele­men­te sein sol­len und wo sie zu po­si­tio­nie­ren sind. Die­se In­for­ma­tio­nen er­hält der Brow­ser aus dem Ren­der Tree. Für die Lay­out-Be­rech­nung sind nicht nur die Re­geln der ein­zel­nen Kno­ten re­le­vant, son­dern auch die Ab­hän­gig­keit

zu ih­ren El­tern­ele­men­ten. So wird bei­spiels­wei­se die Po­si­tio­nie­rung ei­nes Ele­ments von der Po­si­tio­nie­rungs­an­ga­be des El­tern­ele­ments be­ein­flusst; das kann sich dem­ent­spre­chend über meh­re­re Ebe­nen hin­weg aus­wir­ken. Die Dau­er der Er­zeu­gung des Ren­der Trees und die Lay­out-Be­rech­nung fin­den Sie zu­sam­men­ge­fasst im Lay­out-Er­eig­nis in Ih­ren De­ve­l­oper Tools.

DARSTEL­LUNG DER WEB­SEI­TE

Nach­dem der Brow­ser al­le Baum­struk­tu­ren er­zeugt und die er­for­der­li­chen Be­rech­nun­gen durch­ge­führt hat, kann er mit der ei­gent­li­chen Darstel­lung der Web­sei­te be­gin­nen. Die­se wird durch die ge­leis­te­te Vor­ar­beit er­heb­lich be­schleu­nigt. Der Brow­ser er­hält durch die Style-An­ga­ben und die Lay­out-Wer­te ge­naue An­ga­ben, wie und wo er wel­che Ele­men­te an­zu­zei­gen hat. Die Dau­er des letz­ten Schritts im Critical Rendering Path gibt das Paint-Event in Ih­ren De­ve­l­oper Tools an. Die Na­vi­ga­ti­on Ti­ming API gibt mit den Zeits­tem­peln domCom­ple­ted, loadE­ven­tStart und loadE­ven­tEnd je­weils die Zeits­tem­pel für die Zeit­punk­te an, zu de­nen die Ar­beit am Do­ku­ment be­en­det wur­de, das load-Event aus­ge­löst wur­de und al­le Event-Hand­ler auf die­ses Event ab­ge­schlos­sen wur­den. Zu die­sem Zeit­punkt kann der Be­nut­zer mit Ih­rer Sei­te in­ter­agie­ren.

REPAINTS UND REFLOWS

Da­mit ist je­doch die Ar­beit des Brow­sers nicht ge­tan. Die Schrit­te des Critical Rendering Paths wer­den wäh­rend der An­zei­ge ei­ner Web­sei­te häu­fi­ger durch­lau­fen, als es zu­nächst den An­schein er­weckt. Das Be­rech­nen des Lay­outs wird als Re­flow be­zeich­net. Die Darstel­lung der Ele­men­te als Re­paint. So­wohl ein Be­nut­zer als auch Ja­vaS­cript-Lo­gik kön­nen ei­ne Kom­bi­na­ti­on aus Re­flow und Re­paint aus­lö­sen. So sorgt das Scrol­len ei­ner Web­sei­te oder die Ve­rän­de­rung der Fens­ter­grö­ße da­für, dass an­de­re Ele­men­te in den View­port rü­cken oder aber an­de­re CSS-An­wei­sun­gen grei­fen. Der Brow­ser muss das Lay­out al­so neu be­rech­nen und die Ele­men­te neu dar­stel­len. Grei­fen Sie mit Ja­vaS­cript in Ih­re Sei­ten­struk­tur ein, ver­ur­sacht dies eben­falls Reflows und Repaints. Das gilt be­son­ders für das Ein­fü­gen, Ent­fer­nen und Ver­schie­ben von Ele­men­ten. Die Ve­rän­de­rung von Grö­ße und Po­si­ti­on sorgt eben­falls für ei­nen Re­paint ge­folgt von ei­nem Re­flow. Aber auch schein­bar un­kri­ti­sche Ope­ra­tio­nen wie das Aus­le­sen von Ab­mes­sun­gen zie­hen ei­nen Re­flow nach sich. In Ab­bil­dung 6 se­hen Sie, wie sich das Scrol­len ei­ner Web­site auf die Per­for­mance aus­wirkt. Zu die­sem Zweck ak­ti­vie­ren Sie die Auf­nah­me im Per­for­mance-Tab der De­ve­l­oper Tools. An­schlie­ßend füh­ren Sie die Ope­ra­ti­on durch. Da­nach be­en­den Sie die Auf­nah­me. In der Aus­ga­be der Per­for­mance-Ana­ly­se kön­nen Sie das Auf­tre­ten von Paint-Events be­ob­ach­ten. Neue­re Chro­me-Ver­sio­nen ver­se­hen die­sen Zei­t­raum au­ßer­dem mit der In­for­ma­ti­on, dass es sich da­bei um ein Scroll-Event ge­han­delt hat. Um die ne­ga­ti­ven Aus­wir­kun­gen von Reflows und Repaints zu mi­ni­mie­ren, soll­ten Sie ei­ni­ge Din­ge be­ach­ten: • Fol­gen ein­zel­ner Style-Än­de­run­gen ver­mei­den: Än­dern Sie meh­re­re Sty­les nach­ein­an­der, sorgt je­de die­ser Än­de­run­gen für ei­nen se­pa­ra­ten Re­flow. • Style-Än­de­run­gen in Klas­sen zu­sam­men­fas­sen: Wann im­mer Sie die Mög­lich­keit ha­ben, Än­de­run­gen ge­bün­delt in ei­ner CSSKlas­se zu­sam­men­zu­fas­sen, soll­ten Sie dies tun. Der Brow­ser wen­det die neu­en Sty­les in ei­ner Ak­ti­on an. • Ope­ra­tio­nen au­ßer­halb des DOM aus­füh­ren: Mit Ja­vaS­cript kön­nen Sie Teil­bäu­me des DOM aus­hän­gen. So­bald ein Ele­ment nicht mehr im DOM hängt, ha­ben Än­de­run­gen kei­ne Aus­wir­kun­gen mehr auf den Brow­ser, da die­ser die Ele­men­te nicht mehr dar­stellt. So­bald Sie die Än­de­run­gen durch­ge­führt ha­ben, hän­gen Sie die Ele­men­te wie­der ein. Das fol­gen­de Co­de­bei­spiel zeigt, wie Sie mit der detach-Me­tho­de von jQu­e­ry ei­ne Un­ge­ord­ne­te Lis­te aus dem DOM-Baum aus­hän­gen, Ope­ra­tio­nen an die­ser Lis­te vor­neh­men und die mo­di­fi­zier­te Struk­tur schließ­lich wie­der in das Con­tai­ner-Ele­ment ein­hän­gen kön­nen.

FA­ZIT

Ab­hän­gig von der Art der Web­sei­te und Ih­ren Be­nut­zern ent­ste­hen un­ter­schied­li­chen An­for­de­run­gen an die Per­for­mance. Bei ei­ner In­tra­net-Ap­pli­ka­ti­on in ei­nem lo­ka­len Fir­men­netz geht es et­wa um ganz an­de­re Über­tra­gungs­band­brei­ten und End­ge­rä­te, als wenn Sie ei­ne mo­bi­le Web­sei­te ent­wi­ckeln. Grund­sätz­lich soll­ten Sie vom Stand­punkt Ih­rer Be­nut­zer auf Ih­re Ap­pli­ka­ti­on bli­cken und sie vor die­sem Hin­ter­grund ana­ly­sie­ren. Das sorgt am En­de da­für, dass Sie Ih­re Op­ti­mie­run­gen an den rich­ti­gen Stel­len pla­nen und um­set­zen. Die wich­tigs­ten Hilfs­mit­tel beim Auf­fin­den von Per­for­mance-Eng­päs­sen sind Ihr Brow­ser und ei­ne Samm­lung von rea­len Per­for­mance-Da­ten Ih­rer Be­nut­zer.

Se­bas­ti­an Sprin­ger ist als Ja­vaS­cript En­gi­neer bei Mai­bornWolff tä­tig. Ne­ben der Ent­wick­lung und Kon­zep­ti­on von Ap­pli­ka­tio­nen liegt sein Fo­kus auf der Ver­mitt­lung von Wis­sen. Als Do­zent für Ja­vaS­cript, Spre­cher auf zahl­rei­chen Kon­fe­ren­zen und Au­tor ver­sucht er, die Be­geis­te­rung für pro­fes­sio­nel­le Ent­wick­lung mit Ja­vaS­cript zu we­cken.

Abb. 1: On­li­ne-Ana­ly­se mit Goog­le Pa­ge Speed In­sights

Abb. 2: Über­sicht über die Netz­werk-Per­for­mance ei­ner Web­site

Abb. 3: De­tail­an­zei­ge der Netz­werk-Per­for­mance für ei­nen ein­zel­nen Re­quest

Abb. 4: Per­for­mance-Me­tri­ken für den Auf­bau ei­ner Web­sei­te in den Chro­me De­ve­l­oper Tools

Abb. 5: Der Auf­bau­pro­zess aus­ge­hend von den By­tes hin zum fi­na­len DOM [Quel­le: Goog­le We­bF­un­da­men­tals, goo.gl/aL0vYb]

Abb. 6: Aus­wir­kun­gen ei­ner Scroll-Ope­ra­ti­on auf Per­for­mance ei­ner Web­site

Newspapers in German

Newspapers from Germany

© PressReader. All rights reserved.