The Browser Stack

How Modern Web Technology Works - The Foundation for a Faster Web

What is in it for you?

What you might get out of this

  • Get to know how a browser builds a page
  • Learn about all involved technical components and their overall influence
  • Learn about performance and how it is shaped
  • Learn about metrics and recommended values
  • We won't talk about how CSS works
  • Or how in detail the browser calculates the visual appearance

Motivation

Why do we need to know how a browser does things

„About 25 years ago Jakob Nielsen wrote a book called Usability Engineering and he offered some advice about response times which had already been in place for at least 25 years before he wrote the book.“

  • 0.1 second is about the limit for having a visitor feel as though the system is reacting instantaneously.
  • 1.0 second is about the limit for a visitor’s flow of thought to stay uninterrupted, even though the visitor will notice the delay.
  • 10 seconds is about the limit for keeping the visitor’s attention focused on the task they want to perform.

Motivation Continued

Business

  • Pinterest rebuilt pages for performance, achieved a 40% reduction in perceived wait times. Saw 15% increase in both search engine traffic and sign-ups
  • BBC found they lost an additional 10% of users for every additional second their site took to load
  • DoubleClick found 53% of mobile site visits were abandoned if a page took longer than 3 seconds to load
  • When AutoAnything reduced page load time by half, they saw a boost of 12-13% in sales

Technology

  • Programming for the web is nowadays similar to programming for a server
  • Browser became a full stack aka have operating system characteristics
  • Full stack means full range of possibilities to do things incorrectly
  • A browser is an unreliable stack
  • A browser is not a standalone-tool, there are many influencing factors outside its control
  • Technology moves still fast and what works today might not work well tomorrow

Perception

Data vs. Feelings

  • Performance is a measure of how fast your site is
  • Perceived performance is a measure of how fast a visitor thinks your site is
  First Repeated
TTFB0.8s0.8s
First Paint2.2s1.9s
DOMContentLoaded3.3s2.4s
Load6.6s4.9s
Finished9.2s6.7s
Visual Complete9.0s7.4s
Bytes Transferred3,100kB187kB
Request Count268/26869/268

Our Topic List

What will we learn today?

  • Technical Facts
  • Life of a Page Load
  • Why Pages don't load from top to bottom
  • NO Optimization and Measurement slides

Technical Facts

  • DNS
  • Protocols
  • Bandwidth, Keep Alive, Latency, Retry
  • JavaScript, CSS, Fonts, Images
  • Critical Rendering Path
  • Performance API Events
  • Parsing, Rendering, and Painting
  • Error Handling inside a Browser

The Basic Foundation

Protocols, Terminology, and other Things

Web Terminology

Just a few words put in context that we might hear later again

  • Site: A (web)site is a collection of related web pages, including multimedia content, typically identified with a common domain name
  • Page: A web page (also written as webpage) is a document that consists of several resources to compose its visual and content appearance
  • Resources: All data needed to compose a page such as images, CSS, JavaScript, and others
  • Visit: Multiple pages viewed by the same user from the same location over a certain time period, typically 30 min. All together form a visit
  • Page View: A single page displayed to the user
  • (Page) Impression: Business term for a page view or user interaction (due to more and more single page applications). Often used in a very vague way
  • Session: The technical backing of a visit. This is mostly state management such as login, cart, and the famous session id
  • Request: A single resource "fetch"
  • Hit: Imprecise term for a request or page view

Transport

The TCP/IP reference model - Just to know how things travel around

  • Application: Where the most known things live, such as HTTP, FTP, DNS, WebDav and more
  • Transport: Host to host communication either unreliable (UDP) or reliable (TCP)
  • Internet: The IP part (Internet protocol) that take care of the "way finding" with routing and addressing (IP addresses). Basically the API of the Internet
  • Link/Network Access: The link is the physical and logical network component used to interconnect hosts. Ethernet/IEEE 802 (contains Wifi), also the MAC adress plays a role here
  • Physical: The stuff that you can "touch"

Transport - Latency

The buzzword that is thrown in randomly

  • Latency is a delay
  • It occurs all the time
  • Only when it is big enough, we start to think about it
  • Important term and number for serving web pages
  • Applies to every single request
  Real Humanized
CPU Cycle 0.4 ns 1 s
L1 Cache 0.9 ns 2 s
L2 Cache 2.8 ns 7 s
L3 Cache 28 ns 1 min
Memory Access 100 ns 4 min
NVM SSD 25 μs 17 h
SSD 50–150 μs 1.5-4 days
HDD 1–10 ms 1-9 months
TCP SF to NY 65 ms 5 years
TCP SF to Hong Kong141 ms 11 years

Transport - Bandwidth

What is bandwidth?

  • Defines how much data can be transferred per second
  • Upload and download are usually different
  • Net rates are normally never achieved
  • Protocol overhead leaves 85% to 94% real data rate
  • Rate is shared by all users typically equally
  • Single connections can be limited by firewalls and routers

Network Speeds in the US in 2017

  • Mobile: Download 22 Mbps, Upload 8.5 Mbps
  • Fixed: Download 64 Mbps, Upload 22.7 Mbps
  Homepage Size Mobile Fixed Limited to 5 Mbps
Columbia 3.3 MB1.2 s0.41 s5.28 s
Crocs 1.3 MB0.5 s0.16 s2.08 s
Michaels 4.7 MB1.7 s0.59 s7.52 s

Application Protocols - DNS

The Domain Name System

  • Hierarchical decentralized naming system
  • Stores information with domain names, such as:
    • IP address (A, AAAA)
    • Mail Exchanger (MX)
    • Aliases (CNAME)
    • Name servers (NS)
  • Typical lookup of IP to domain name
  • Resolved names will be cached according to policy
  • DNS can be used for load balancing and CDN functionality aka server closest to requesting host
$ dig www.columbia.com
;; QUESTION SECTION:
;www.columbia.com.		IN	A

;; ANSWER SECTION:
www.columbia.com.	680	IN	CNAME	www.columbia.com.cdn.cloudflare.net.
www.columbia.com.cdn.cloudflare.net. 300 IN A	104.17.8.17
www.columbia.com.cdn.cloudflare.net. 300 IN A	104.17.9.17

;; Query time: 59 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jun 15 19:51:46 CDT 2018
;; MSG SIZE  rcvd: 126
$ dig www.yetanotherblog.de
;; QUESTION SECTION:
;www.yetanotherblog.de.		IN	A

;; ANSWER SECTION:
www.yetanotherblog.de.	86400	IN	A	5.35.225.36

;; Query time: 211 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jun 15 20:01:55 CDT 2018
;; MSG SIZE  rcvd: 66

Another DNS Example

; <<>> DiG  www.yetanotherblog.de. @8.8.4.4
;; global options: +cmd
.			117473	IN	NS	e.root-servers.net.
.			117473	IN	NS	h.root-servers.net.
.			117473	IN	NS	l.root-servers.net.
.			117473	IN	NS	i.root-servers.net.
.			117473	IN	NS	a.root-servers.net.
.			117473	IN	NS	d.root-servers.net.
.			117473	IN	NS	c.root-servers.net.
.			117473	IN	NS	b.root-servers.net.
.			117473	IN	NS	j.root-servers.net.
.			117473	IN	NS	k.root-servers.net.
.			117473	IN	NS	g.root-servers.net.
.			117473	IN	NS	m.root-servers.net.
.			117473	IN	NS	f.root-servers.net.
;; Received 228 bytes from 8.8.4.4#53(8.8.4.4) in 5 ms

de.			172800	IN	NS	a.nic.de.
de.			172800	IN	NS	f.nic.de.
de.			172800	IN	NS	l.de.net.
de.			172800	IN	NS	n.de.net.
de.			172800	IN	NS	s.de.net.
de.			172800	IN	NS	z.nic.de.
;; Received 381 bytes from 192.5.5.241#53(192.5.5.241) in 3 ms

yetanotherblog.de.	86400	IN	NS	ns1.hans.hosteurope.de.
yetanotherblog.de.	86400	IN	NS	ns2.hans.hosteurope.de.
;; Received 91 bytes from 194.146.107.6#53(194.146.107.6) in 1217 ms

www.yetanotherblog.de.	86400	IN	A	5.35.225.36
;; Received 107 bytes from 217.115.143.140#53(217.115.143.140) in 118 ms
; <<>> DiG  www.columbia.com. @8.8.4.4
;; global options: +cmd
.			65027	IN	NS	a.root-servers.net.
.			65027	IN	NS	b.root-servers.net.
condensed here
.			65027	IN	NS	l.root-servers.net.
.			65027	IN	NS	m.root-servers.net.
;; Received 228 bytes from 8.8.4.4#53(8.8.4.4) in 6 ms

com.			172800	IN	NS	a.gtld-servers.net.
com.			172800	IN	NS	b.gtld-servers.net.
com.			172800	IN	NS	c.gtld-servers.net.
com.			172800	IN	NS	d.gtld-servers.net.
com.			172800	IN	NS	e.gtld-servers.net.
com.			172800	IN	NS	f.gtld-servers.net.
com.			172800	IN	NS	g.gtld-servers.net.
com.			172800	IN	NS	h.gtld-servers.net.
com.			172800	IN	NS	i.gtld-servers.net.
com.			172800	IN	NS	j.gtld-servers.net.
com.			172800	IN	NS	k.gtld-servers.net.
com.			172800	IN	NS	l.gtld-servers.net.
com.			172800	IN	NS	m.gtld-servers.net.
;; Received 494 bytes from 199.7.91.13#53(199.7.91.13) in 4 ms

columbia.com.		172800	IN	NS	udns1.ultradns.net.
columbia.com.		172800	IN	NS	udns2.ultradns.net.
columbia.com.		172800	IN	NS	pdns3.ultradns.org.
columbia.com.		172800	IN	NS	pdns4.ultradns.org.
columbia.com.		172800	IN	NS	pdns1.ultradns.net.
columbia.com.		172800	IN	NS	pdns2.ultradns.net.
columbia.com.		172800	IN	NS	pdns5.ultradns.info.
columbia.com.		172800	IN	NS	pdns6.ultradns.co.uk.
;; Received 365 bytes from 192.52.178.30#53(192.52.178.30) in 24 ms

www.columbia.com.	900	IN	CNAME	www.columbia.com.cdn.cloudflare.net.
;; Received 83 bytes from 204.74.115.1#53(204.74.115.1) in 16 ms
    

DNS Testing

UltraDNS Performance

DNS is just another service

Application Protocols - HTTP/HTTPS

A quick look at HTTP and HTTPS

HTTP

  • Textual and stateless protocol
  • Request-Response protocol
  • Design allows intermediate components on the network to participate (CDN, Optimizer, Proxies)
  • HTTP resources are identified by URLs using URI scheme HTTP/HTTPS
  • HTTP/1.0 initial protocol
  • HTTP/1.1 added connection reuse (keep alive) and streaming
  • HTTP/2 improved further

HTTPS

  • HTTP over TLS aka a mix of application and transport protocol
  • HTTP stays the same, just runs over encrypted connections
  • TLS requires handshake roundtrips to start the encrypted connection (two roundtrips)
  • HTTP/2 can use ALPN (Application-Layer Protocol Negotiation) to reduce the roundtrips to one

HTTP/1.1 Headers

GET / HTTP/1.1        
Host: www.yetananotherblog.de        
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: de,en-US;q=0.9,en;q=0.8
Cache-Control: no-cache
Connection: keep-alive
DNT: 1
Pragma: no-cache
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36
HTTP/1.1 200 OK
Connection: keep-alive
Content-Encoding: gzip
Content-Length: 11299
Content-Security-Policy: default-src 'self' 'unsafe-inline' data: https:; upgrade-insecure-requests
Content-Type: text/html; charset=iso-8859-1
Date: Sat, 16 Jun 2018 14:55:47 GMT
Generator: LMNucleus CMS v3.66
Server: Apache
Set-Cookie: lastVisit=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; secure
Vary: Accept-Encoding,User-Agent
X-Content-Type-Options: nosniff
X-FRAME-OPTIONS: SAMEORIGIN
X-XSS-Protection: 1; mode=block

The payload starts here...

HTTP/2

The new kid on the block, also known as H2

  • HTTP/2 was built based on SPDY by Google
  • Addresses HTTP/1.1 shortcomings around performance
  • It is BINARY! What you see is not what you transmit
  • Uses one connection per host instead of many
  • Multiplexes data in both direction including prioritization
  • Divides the connection into streams (these into messages and these into frames)
  • Uses HPACK to compress headers
  • There is only HTTPS in HTTP/2, unencrypted H2 is a standard but not implemented (called H2C)
  • To start H2, you start ALPN on TLS and signal in the handshake that you want H2, if the server is ok, it responds appropriately
  • You could push data proactively to the client as part of H2 but it is mostly not used

HTTP/2 Headers

GET / HTTP/2        
Host: www.columbia.com        
:authority: www.columbia.com
:method: GET
:path: /
:scheme: https
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
accept-encoding: gzip, deflate, br
accept-language: de,en-US;q=0.9,en;q=0.8
cache-control: no-cache
dnt: 1
pragma: no-cache
upgrade-insecure-requests: 1
user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36
accept-ranges: bytes
cache-control: no-cache, no-store, must-revalidate
cf-ray: 42be2de3b85454f2-ORD
content-encoding: gzip
content-type: text/html;charset=UTF-8
date: Sat, 16 Jun 2018 15:06:15 GMT
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
expires: Thu, 01 Dec 1994 16:00:00 GMT
pragma: no-cache
server: cloudflare
set-cookie: __cfduid=dbd5bbb595f00e8e9166a4f9e2ba7f6cf1529161574; expires=Sun, 16-Jun-19 15:06:14 GMT; path=/; domain=.columbia.com; HttpOnly
set-cookie: dwac_bd5D2iaaitc6EaaaddrFt9bJhC=Vyfy4tOMQG8756F9Rr8IHjR8UzXNsWzUfpk%3D|dw-only|||USD|false|US%2FPacific|true; Path=/
set-cookie: cqcid=adR56XabqtjiUW2SKVe6GLdpWV; Path=/
status: 200
vary: Accept-Encoding
x-content-type-options: nosniff
x-dw-request-base-id: OFp2ylslJ2egAgAK

The payload starts here...

Web Fundamentals

HTML, Images, Fonts, CSS, JavaScript, and more

HTML

HTML5, the cornerstone of the modern web

  • Markup language for content on WWW
  • Includes APIs and DOM specs (both new to HTML5)
  • Includes processing specs and error handling
  • Includes many new elements such as section and footer
  • Does not contain visual styling or similar things!
<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8">
        <title>Title of the document</title>
    </head>

    <body>
        Content of the document......
    </body>
</html>

CSS

Cascading Style Sheets - How to make things beautiful

  • CSS3 is a stylesheet language
  • Describes the presentation of (mostly) HTML
  • Separation of content and design
  • Cascading comes from how you can combine and overlay styles
  • Textual definition
  • A selector defines where to apply the styling rule
  • CSS had well-defined error handling right from the beginning

Selector Examples

  • .foo: Elements with class foo
  • .foo .bar: Elements with class foo under elements with class bar
  • #foobar: Elements with id=foobar
  • p[foo]: p elements with attribute foo
  • p[foo="bar"]: p elements with attribute foo and value bar
  • .foo:not(p): Elements with class foo and not being a p element
  • section > p: p elements that are direct children of section

CSS again

Just some more important facts

  • SASS and LESS
    • Aren't CSS, they are CSS based languages to simplify consistent CSS creation
    • Are offline preprocessors that produce CSS files
  • CSS can have includes (@import)
  • Media queries permit conditional CSS based on viewport properties (@media)
  • Rules can overwrite each other hence there is a specificity calculation in the standard, order is not important
  • CSS supports animation
@import "custom.css";
@import "common.css" screen;
@import url('landscape.css') screen and (orientation:landscape);
@media screen and (max-width: 600px) {
    .example {
        display: none;
    }
}
<style>
    * {color: White;}           /* 0, 0, 0, 0, 0 */
    p {color : Red !important;} /* 1, 0, 0, 0, 1 */
    .foo {color : Yellow;}      /* 0, 0, 0, 1, 0 */
    p.foo {color : Brown;}      /* 0, 0, 0, 1, 1 */
    div p {color : Green;}      /* 0, 0, 0, 0, 2 */
    #header p {color : Green;}  /* 0, 0, 1, 0, 1 */
    p {color : Blue;}           /* 0, 0, 0, 0, 1 */
    p {color : Gray;}           /* 0, 0, 0, 0, 1 */
</style>
    
<div id="header">
    <p class="foo" style="color: Black;">Text here</p> /* 0, 1, 0, 0, 0 */
</div>

Fonts

Make things look even better

  • Scalable font definition
  • Vector definition instead of bitmaps
  • TrueType or OpenType based
  • WOFF (Web Open Font Format) is that above plus compression
  • WOFF2 is WOFF with even better compression
  • File-based, downloaded by the browser
  • Fonts can be reduced based on character set

Ubuntu Mono

Roboto Mono

Roboto Mono 300

Hack

Roboto

Roboto Condensed

JavaScript (JS)

The dynamic part of a web page

  • High-level, interpreted programming language
  • Supports event-driven, functional, and imperative (including object-oriented and prototype-based) programming styles
  • Many API are provided by the host, not by the language
  • Can be loaded as file or embedded into the HTML
  • JS can manipulate the entire DOM
<!DOCTYPE html>
<html>
  <head>
    <script>
       // run this function when the document is loaded
       window.onload = function() {

         // create a couple of elements in an otherwise empty HTML page
         var heading = document.createElement("h1");
         var heading_text = document.createTextNode("Big Head!");
         heading.appendChild(heading_text);
         document.body.appendChild(heading);
      }
    </script>
  </head>
  <body>
      <!-- empty -->
  </body>
</html>

Images

The largest payload with the nicest look

  • Vector images (SVG, "Fonts"): Nicely scalable
  • Raster images (PNG, JPG, GIF): Mostly photos
  • GIF can do animation, besides that avoid it
  • PNG is lossless, great for sharp edges, bad for many details, adjustable compression, progressive
  • JPG is lossy, great for photos, bad for sharp edges and text, adjustable compression, progressive
  • Images pixel are always 4 bytes after decompression to internal memory
  • A 1400x400 pixel image might be 100 kB in transit, but will be 2.3 MB in memory
  • Retina support: 2800x800, almost 9 MB now

XHR

Important piece of the AJAX thing

  • XMLHttpRequest (XHR) is an API
  • Made for asynchronous communication
  • Runs outside of the page load
  • Meant to make things more interactive
  • Even though it says XML, it is mostly not XML anymore
  • Most likely manipulates the DOM tree as result
var request = new XMLHttpRequest();
request.onreadystatechange = function () {
    var DONE = this.DONE || 4;
    if (this.readyState === DONE){
        alert(this.readyState);
    }
};
request.open('GET', 'somepage.xml', true);

// Tells server that this call is made for ajax purposes.
// Most libraries like jQuery/Prototype/Dojo do this
request.setRequestHeader('X-Requested-With', 'XMLHttpRequest');  
                                                                 
// No data needs to be sent along with the request
request.send(null);  

Cookies

Small things that can get big

  • Small key-value pairs for state management
  • Set mostly by the server as part of a response
  • Client can read and set cookies when not marked HTTPOnly
  • Client always returns all cookies matching domain and path even when not needed by the server aka when images are fetched, HTTP/2 applies some magic to avoid sending the same cookies again (HPACK compression)
  • Reality shows that Chrome returns up to 150 cookies while Safari returns up to 600
  • Minimal cookie support by a browser:
    • 50 cookies per domain
    • 4096 bytes in size
    • 3,000 cookies in total

1,866 Character Example

Cookie: __cfduid=d1f0558eb4291014c9f1ab4d49df0ee971527262512;
dwanonymous_29c8bd709bce117811b14d53deb17581=acZl83aSHkCSQRi0C21biPDfSa;
mt.v=2.970178920.1527262513452;
_ga=GA1.2.1567325025.1527262514;
tracker_device=77a185df-2e94-4fea-b5e5-6aff7e88f325;
__sonar=16246308783896654907;
sr_cr102_exp=3;
sr_browser_id=14a19809-7a3c-42f2-a6ca-7f3f994c7813;
QuantumMetricUserID=5b370292cd3498392b9a13090c6c88f8;
__cq_seg=0~0.00!1~0.00!2~0.00!3~0.00!4~0.00!5~0.00!6~0.00!7~0.00!8~0.00!9~0.00!f0~15~9;
cqcid=acZl83aSHkCSQRi0C21biPDfSa;
__cq_dnt=0;
dw_dnt=0;
dw=1;
undefined=1;
ColeHaanNewsletterVisits=2;
ColeHaanNewsletterSession=0;
QuantumMetricEnabled=true;
QuantumMetricSessionID=38436054e0b8906818d9b45d9d0e139f;
dwac_bct8giaagE38Yaaac663BfOTDo=MvJXttrDjrbZhWSoqtWjnrK5vaKqmIToA04%3D|dw-only|||USD|false|America%2FNew%5FYork|true;
sid=MvJXttrDjrbZhWSoqtWjnrK5vaKqmIToA04;
tradeGlobalGeolocation=DE;
clhSessID=yocN8p0w==;
customerID=MvJXttrDjrbZhWSoqtWjnrK5vaKqmIToA04=;
dwsid=q7w-eGxZrDtli89TV0_0Viv31GwcAqZlv0D_uPzY49QEsA3ngjKIXndKG_5g6R3fRLfCpy98ZN5fR4yocN8p0w==;
_gid=GA1.2.342874631.1529413056;
_dc_gtm_UA-38317407-1=1;
_uetsid=_uet7554f3c0;
mp_cole_haan_mixpanel=%7B%22distinct_id%22%3A%20%2216397f09133498-0d552b06f36dc5-3b7b0d58-1fa400-16397f0913442a%22%7D;
__cq_uuid=d26e3e40-7176-11e8-96f9-db11fe5c995a;
_hjIncludedInSample=1;
_gat_UA-38317407-1=1;
RT="sl=1&ss=1529413055000&tt=5016&obo=0&sh=1529413060023%3D1%3A0%3A5016&
    dm=colehaan.com&si=90e14679-0448-4346-a7e6-38497ec5ee2e&bcn=%2F%2F36e4f0e7.
    akstat.io%2F&ld=1529413060025&r=http%3A%2F%2Fwww.colehaan.com%2F&
    ul=1529413078197";
_4c_=LY%2FrSgQxDIXfJb%2BHIUmbtJ1%2FgiA%2BhfSKoqzLungb5t03FUMhLZxzvp4dvp77CTYSTp4chsioC7
    z2nw%2FYdri8tLk%2BYQMuRTWM3EnioFozh5I75txGVV8QFvieOU7QRaHgOB4L1PO%2Ff4f63rrlUFp1daa
    %2B%2Fs4XT2M%2FTcL50uw%2BzAGlYXXaKrochX3OZUQ3CH1qlWNR0z3cPT3ezwRRYwmyrFYisLKQB0P%2F
    %2FcZapeTFjhjx%2BgZbVI9zjuO4AQ%3D%3D

The Life of a Page Load

How Does a Webpage gets Loaded?
Turn Text into Graphics

LoaPL - Ask for Something

URL first

  • User types in the url, uses a link or navigates
  • Browser verifies url for correctness
  • Browser checks local cache for resources
  • Depending on cache either loads it from cache or starts networking
  • Modern browsers often cache the previously rendered page as well (even readily rendered)
  • Browser can cache locally
  • Request was executed before and marked as cacheable
  • You can increase speed by making things cacheable privately

LoaPL - DNS

Find where the system for that URL is

  • Browser checks local cache for DNS name
  • Browser asks OS for resolution
  • OS might have cached it or asks the configured resolver
  • Next hop might be the provider or company DNS
  • From there, the usual fallbacks happen
  • Browser caches for a while
  • Browser reports the DNS lookup time if any
  • 25 to 60ms per domain are typical
  • ISP DNS resolvers are often slow because they scan, check, and sell data

LoaPL - Connect

Establish connection on Internet layer

  • You have to establish a connection first
  • Handshake using three packets (29ms)

LoaPL - TLS

Establish TLS with a handshake

  • Build up TLS with a another handshake (963 to 977)
  • Took 46ms

LoaPL - Initial Request

Time to ask for something useful

  • Browser sends request for resource
  • Typically the first page HTML
  • First byte (TTFB) after 830ms

LoaPL - Loading, Parsing, and Trees

Take care of the first content

  • Now things will get really interesting
  • While still downloading the response, the browser uncompresses and parses what it receives
  • Still loading in the background
  • Will place all resources it sees in the download queue
  • DOM will be composed while parsing the response
  • DOM building irons out HTML errors
  • HTML5 defines some rules how to deal with errors
  • Errors can set back parsing and emit events that slow things down

Main Flow Started

Lot of things will happen now in parallel

  • DOM tree will be built by the HTML Parser
  • CSS Parser builds the style rules, which can be one or more other trees
  • DOM and CSS Trees are input to the Render Tree aka what elements to display and in which order
  • The Render Tree will be layout aka position and visual properties are determined
  • Last step is the painting aka the display to the end user

Parallel and Asynchronous

Highly optimized in modern browsers

  • In the beginning everything was synchronous and serialized
  • More cpu and memory and more demanding web techniques gave us asynchronous processing
  • DOM tree is built while HTML is still loaded
  • CSS "tree" is built despite DOM still loading (inline styles) and more styles being in-flight
  • Render tree is built and layout calculated as much as possible
  • If nothing essential is missing up to this point, we might even paint
  • In contrast, any change to the DOM, CSS or resources already displayed, will cause a relayout and repainting
  • Amount is determined by the change itself and how much of the tree it depends on
  • Page building became non-deterministic to a certain extend
  • Standards should keep the result identical despite different order
  • We will learn about cross-dependencies in the next slides

LoaPL - Subresource Loading

CSS, JavaScript, Images, and Fonts

  • Browser puts all resources into download queue with priorities
  • CSS is highest, JS is high, all that is defer or async is low
  • What is important for layout is high such as Fonts
  • Images are low
  • When the CSS file is loaded, the main parser thread stops and does the CSS parsing
  • This might emit new resources for the loading queue

Font Loading

Fonts have special loading behavior

  • Font is a compressed file
  • Fonts are announced/setup in CSS
  • A font is needed to calculate style aka size of areas
  • Browser delays font loading until it knows it needs it (CSS is applied)
  • If the font is not yet available, browser will block rendering for three seconds before going for a fallback
@font-face {
    font-family: 'RobotoMono';
    font-style: normal;
    font-weight: normal;
    src: url('fonts/Roboto/roboto-mono.woff') format('woff'),
         url('fonts/Roboto/roboto-mono.ttf') format('truetype'),
         url('fonts/Roboto/roboto-mono.svg#roboto-mono') format('svg'),
         url('fonts/Roboto/roboto-mono.eot?#iefix') format('embedded-opentype');
}

LoaPL - JavaScript

JavaScript is considered a "parser blocking resource". This means that the parsing of the HTML document itself is blocked by JavaScript. When the parser reaches a script tag, whether that be internal or external, it stops to fetch (if it is external) and run it.

  • When directly embedded code, parse and compile it, execute it, when the snippet writes into the DOM, reset DOM parsing to that point if needed
  • When code is external, load code and continue as it would been embedded code

defer

  • Defer execution till after DOMInteractive but before DOMContentLoaded
  • Maintain order of scripts as found for execution

async

  • Load asynchronous
  • When script is loaded, executed it synchronously aka block the parser
  • Order is non-deterministic

LoaPL - CSS

The base for any kind of rendering

  • CSS parsing is easier, because the grammar is context free
  • CSS defines hard error processing rules
  • Browser requires CSS for the display, hence it it is eager to get it
  • Inline CSS causes changes to the style "tree" and might cause render tree changes as well as layout changes
  • Browser is smart enough to know when a change has effects (depends also on the rendering engine)
  • Browser build style "tree" called CSSOM

CSS, JavaScript, and Content

CSS and JS depend on each other

Visual Properties

  • JS can ask for and manipulate render tree properties
  • Data might not be available when JS asks
  • Browser will stop script until render tree is ready
  • Tree requires stylesheets and fonts, images are a little undefined

CSS is also content

  • Modern CSS is also content (pseudo-elements)
  • This will create entries in the render tree, not the DOM
  • Content supports DOM access via attr
  • Any attribute can be set via JS

document.write

  • JS can manipulate the DOM
  • Add elements, remove elements, move elements
  • Change styling on the fly (direct properties)
  • Change styling via inline rules (direct write of CSS or a style link)

CSS Standard Processing Model

The standard suggests a model for renderer and layouter

  • Parse the source document and create a document tree.
  • Identify the target media type.
  • Retrieve all style sheets associated with the document that are specified for the target media type.
  • Annotate every element of the document tree by assigning a single value to every property that is applicable to the target media type. Properties are assigned values according to the mechanisms described in the section on cascading and inheritance.
  • From the annotated document tree, generate a formatting structure. Often, the formatting structure closely resembles the document tree, but it may also differ significantly... Note that the CSS user agent does not alter the document tree during this phase. In particular, content generated due to style sheets is not fed back to the document language processor (e.g., for reparsing).
  • Transfer the formatting structure to the target medium (e.g., print the results, display them on the screen, render them as speech, etc.).

LoaPL - Rendering

Building the render tree

  • Build a tree that contains elements to be displayed
  • Display none is out and visibility hidden is in
  • Stylesheet rules are applied (nifty optimizations to be fast)
  • Render tree is attached to DOM to listen for updates
  • "Renderer" is attached to a DOM node

LoaPL - Layouting

Calculating visual appearance

  • Calculate layout for each entry in the render tree
  • From root (viewport) down to each child
  • Dirty bit removed
  • If the DOM is changed or some properties, the dirty bit is set
  • Browser might bundle up changes into one relayout
  • Browser tries to do as little as possible aka color change does not cause a relayout
  • Layout can be global or incremental
  • Small changes causes recalculations of these "blocks" only
  • Only when size is changed, larger areas might have to be done again
  • Some change triggers a global layout immediately aka window size change or font changes

LoaPL - Painting

Finally things appear

  • Transfer the layout of the render tree to the media (e.g. screen)
  • That means drawing a large bitmap
  • OS bundles up changes to the screen before showing it
  • Non-visible pieces are not painted
  • Painting has an order:
    • background color
    • background image
    • border
    • children
    • outline
  • P.S: Actually it is a little more complicated
  • Use the stacking order (z-index), the higher the later

Timing and Events

Most important events during a page's lifecycle

Navigation Timing API

Events - TTFB/TTLB

When do we get things

  • Time to first byte
  • Time to last byte
  • Interesting because we know how long server processing and networking took
  • Interesting because we know how long downloading took
  • The following technical details are involved:
    • DNS
    • TCP handshake
    • TLS handshake
    • Send time
    • Server processing time
    • Time to first byte delivered (contains latency)
    • Time to last byte downloaded (also with latency)
    • Network capacity

DOM Events

A series of timestamps and events, measurements by Performance Timing API

  • domLoading: Got the first bytes and started parsing
  • domInteractive: Got all HTML, finished parsing, finished async JS, finished blocking JS, starting deferred JS processing
  • domContentLoaded: Deferred JS was executed, DomContentLoaded event fires and triggers event handler for JS
  • domComplete: All content has been loaded (aka images and more), DomContentLoaded event was fully processed (attached JS), fire onload event and start processing JS
  • loadEventEnd: All JS attached to onload was executed, dust should have settled

Events - Painting

User does not care about technical details

  • Users judges by impression
  • No interest in DOM numbers
  • New browsers expose Paint Timing API: first-paint, first-contentful-paint
  • Alternative measurements are "first meaningful paint" aka something the user waited for, not just content
  • The page is complete and does not load or move anymore ("visual complete")
First Paint First Contentful Paint
First Meaningful Paint Visual Complete

DOM Events still useful?

How to use the measurements despite being of low interest by the user

  • domInteractive: How long does parsing take and do I block it with JS?
  • domContentLoadedStart - domInteractive: How much defer JS do I have?
  • domContentLoadedEnd - domContentLoadedStart: How long does the DomContentLoaded JS event processing take aka working on the parsed and mostly ready CSSOM? Do I block the CSSOM by any chance?
  • domComplete: When is really everything downloaded?
  • loadEventEnd - loadEventStart: How long does the final onload event handling JS take?
  • loadEventEnd - domLoading: How does does the full page processing take?

Questions And Answers

Your Questions and Feedback