Web Fundamentals
Web Browsers

A deep dive into Web browsers

• How did browsers evolve?
  • History of browsers
• How do moderns browsers work?
  • Architecture
  • Navigation, rendering, interactivity, extensibility

1989: Tim Berners-Lee spawned the World Wide Web

• A project at CERN
  • Information Management: A Proposal
• Based on Ted Nelson's hypertext model

1990: The first Web Browser is released

• Nexus
  • Developed by Tim Berners-Lee
  • initially named WorldWideWeb
  • Developed for the NeXTstep Operating System
  • Open-sourced in 1993

1992: More browsers are released

• Built on the libwww library
  • Developed at CERN
• MacWWW
  • The first browser for the classic Mac OS
  • Written by Robert Cailliau at CERN
• Line Mode Browser
  • First browser portable to several operating systems
  • Written by Nicola Pellow at CERN

1993: Even more browsers are released

• Lynx
  • A text-based browser for terminals
  • Still being maintained! (oldest active browser to this day)
• Mosaic
  • Developed at the National Center for Supercomputing Applications (NCSA)
  • Became first widely available browser

There are two ages of the Internet—before Mosaic, and after.

…
In twenty-four months, the Web has gone from being unknown to absolutely ubiquitous.

Mark Pesce, ZDNet

1993 - 1994: Domination of Mosaic

• Highly popular
  • Due to intuitive interface and easy installation
  • Functionality same as Nexus, but just better executed
• Dynamic Web Pages
  • First browser to allow submitting forms to servers
• Proprietary software
  • Free for non-commercial usage
  • Paid licenses for commercial usage

1994 - 1995: Rise of Netscape

• Netscape Communications Corporation
  • Founded by Mosaic developers to captizale on the Web
  • Originally named Mosaic Communications Corporation
  • Acquired by AOL in 1999
• Netscape Navigator
  • Browser developed from scratch
  • Internal codename: Mozilla (Mosaic killer / Godzilla)
  • Available for free for non-commercial usage
• Quickly replaced Mosaic
  • Mosaic development stopped in 1997

1995: Microsoft awakens

• Internet Explorer 1.0 – A licensed version of Mosaic
  • Included in Windows 95 Plus!
• Internet Explorer 2.0 – Released 3 months later
  • Available for free, including commercial usage
• Internet Explorer 3.0 – Feature parity with Netscape
• Internet Explorer 4.0
  • Included by default in Microsoft Windows

1995 - 2001: Rapid development of new features

• Proprietary HTML tags
  • Netscape: <blink>
  • Internet Explorer: <marquee>
• JavaScript
  • Developed by Netscape
  • JScript: Microsoft's Dialect
• Cascading Style Sheets (CSS)
  • Specified by W3C in 1994, but slow adoption
  • IE and Netscape had near-complete support in 1996

De-standardization

• "Best viewed with" icons
  • Rapid development → divergence from W3C HTML spec
  • Web pages were not automatically viewable in any browser
• "Viewable With Any Browser"
  • Compaign by W3C to encourage spec-compliance

2001: Dominance of Internet Explorer

• Peak market share of 96%
  • Windows already had 90% market share
• End of Netscape
  • 1998: Open-sourcing codebase
  • 1998: Founding of Mozilla Foundation
  • 1999: Acquired by AOL
  • 2007: Development stopped
• End of rapid development
  • Next major Internet Explorer release was in 2006

2003: Apple releases Safari

• Shipped with Mac OSX Panther
  • Also for Windows, but later abandoned
  • First mobile version was shipped with the iPhone in 2007
• Built on WebKit engine
  • Apple's fork of KHTML engine from KDE (spec-compliant)

2004: Mozilla Foundation releases Firefox

• Community-driven successor to Netscape
  • Browser-only version of full Netscape suite
  • Initially named Phoenix, then Firebird, then Firefox
• Quickly started gaining market share
  • Peaked at 30% in 2009

2005: Opera becomes freeware

• Opera was commercial
  • Initially released in 1996
  • Limited popularity due to free alternatives
• Known for its innovativity
  • Introduced browser tabs, mouse gestures, ...
• First to pass the Acid2 test
  • Acid2: a webpage to test browsers on spec-compliance

Full of features, easy to use, and a virtual engraved invitation to hackers and other digital delinquents, Internet Explorer 6.x might be the least secure software on the planet.

The 25 Worst Tech Products of All Time, Dan Tynan, PCWorld

2006: Internet Explorer 7 is released

• A long-awaited update
  • IE6 was released 5 years before
• Better specification compliance
  • It still did not pass Acid2 and Acid3
• More secure
  • Phishing filter and many exploit fixes

2008: Google releases Chrome

• Freeware, but proprietary
  • Based on Google's open-source Chromium
  • Uses Apple's WebKit rendering engine, later forked as Blink
  • A fast new JavaScript engine: V8

2010: Steve Jobs' Thoughts on Flash

• Adobe Flash Player – Multimedia browser extension
  • Popular for animations and interactive websites
• Open letter from Steve Jobs
  • Lists reasons why Flash would not be supported on iOS
    • Not open – Flash is proprietary
    • Unreliable and unsecure
    • …
  • Controversial at the time, but most agree in hindsight
  • HTML5 and CSS3 could replace most functionality
  • Flash Player was deprecated in 2017

Chrome quickly gains market share

• 2011 – Overtakes Firefox
• 2012 – Overtakes Internet Explorer
  • Chrome becomes the most popular browser
• 2017 – Chrome reaches 60% market share
  • Opera, FireFox, Internet Explorer fall below 5%

Chrome Won

Andreas Gal, Former Mozilla CTO, 2017

World Wide Web Consortium maintains Web standards

• 1994 – Founded by Tim Berners-Lee
  • Fostering compatibility and agreement among members
  • 462 member organizations as of 2023
• 2004 – Browsers criticize slow spec development
  • And W3C's decision to focus on XHTML (stricter HTML)
• 2004 – WHATWG is founded
  • Founded by Apple, Mozilla, Opera
  • Microsoft and Google later join

2004 - 2019: Competing Web standards

• 2007: Independent development of HTML5
  • Occasional alignment and divergence of features
• Different development strategies
  • W3C: snapshot-based (HTML5, HTML5.1, ...)
  • WHATWG: living standard (continuous updating)
• 2017: WHATWG established a patent policy
  • Applicable patents can be used royalty-free
  • W3C already had this

2019: Conflict ends

• Patent policy enabled alignment
  • Ability to implement specifications royalty-free was important to W3C
• W3C publishes memorandum of understanding
  • HTML and DOM published and maintained under WHATWG
• HTML and DOM lost public particability
  • Anyone may participate in the WHATWG
  • WHATWG is in control of the major browser vendors

A Web dominated by Chrome

• 2019 – Market share crossed 70%
  • Chrome is market leader to this day
• Other browsers become Chromium-based
  • 2013 – Opera switches to the Chromium engine
  • 2020 – Microsoft deprecates IE and releases Edge
• Google controls the Web via browser engines
  • Chromium has total market share of 71,73%

What is happening under the hood?

• Browsers have become highly-complex applications
• From clicking on a link towards an interactive page
  • Navigation and the network stack
  • Parsing and rendering
  • Interactivity with JavaScript

The multi-process browser architecture

Browser process

handles the user interface

Render process(es)

handles rendering of a single tab

Plugin process(es)

plugins inside websites (e.g. Flash)

GPU process

Handles GPU tasks

…

Impact of multiple processes

• Sandboxing
  • Better security
  • An unresponsive process can be killed and recreated
• Need for IPC
  • Inter Process Communication
• Higher memory usage
  • Multiple copies of the same infrastructure
  • Negative for memory-constrained devices

Site Isolation

• Security model requires site isolation
  • Same Origin Policy: inability to access other sites data
• Separate render processes per site
  • Site: scope of second-level domain in DNS (ex.com)
  • http://foo.ex.com and http://bar.ex.com in same site
• Complex process handling with cross-site iframes

Towards Servicification

• Hardware capabilities influence process handling
  • High-end devices can easily run many processes
  • Low-end devices with memory restrictions prefer fewer processes
• Servicification
  • Modularized architecture
  • Run logic inside services
  • Services could be split across processes, or merged

Navigation triggers network thread

• Navigation actions
  • Entering and confirming a URL
  • Entering and confirming a search query
  • Clicking on a link
  • Fetching required resources on pages – images, scripts, …
  • Network requests through JavaScript
  • Pre-emptive requests by the browser

Network thread handles requests

• Going through the network stack
  • DNS
  • TLS
  • TCP/IP
  • …
• Handling redirects
  • HTTP 3xx range
• Cache management – reusing previous responses
  • Cache-Control, ETag, Last-Modified

Network thread handles responses

• Identifying media type
  • Content-Type header
  • MIME Type snipping – if Content-Type is missing or wrong
• Passing to responsible process
  • HTML → Renderer process
  • ZIP → Download manager
• Performing security checks
  • SafeBrowsing – Blacklist of known malicious sites
  • CORB – Prevent data leakage in dubious requests
    • Including HTML in <img> tag

Front-end Performance: delivering smooth experience for humans

• Nielsen's guidelines on human perception
  • 0.1 second – feels instantaneous
  • 1.0 second – limit for keeping user's flow of thought
  • 10 seconds – limit for keeping user's attention
• Rule of thumb in Web performance community
  • Render (partial) pages in under 250 ms

Targets for performance metrics

• Web Documents
  • Plain text with some hyperlinks
  • DLT: Document load time – Loading single resource
• Web Pages
  • Hypermedia resources, e.g. images, videos, …
  • PLT: Page load time – Loading all resources in page
• Web Applications
  • Dynamic applications using JavaScript
  • Performance metrics depend on application

Pages can trigger multiple requests

• Median number of requests per page: 72 (67 mobile)
  • From HTTP Archive State of the Web August 2023
• Composed of different resources
  • Images: 21 requests (1029.2 KB)
  • JavaScript: 23 requests (587.0 KB)
  • Fonts: 5 requests (151.0 KB)
  • CSS: 8 requests (8.5 KB)
  • HTML: 2 requests (31.0 KB)
  • Other: 3 requests (1.3 KB)

The Resource Waterfall gives an overview of a page's performance

• Timeline of all network requests
  • Not all requests are initiated at the same time
  • Requests can happen in parallel
  • Requests go through different stages
    • Request sent
    • Time to first byte
    • Content downloaded
• Impacts the Critical Rendering Path (CRP)
  • CRP: steps for going from bytes to pixels on screen
  • Delayed by HTML, CSS, (non-async) JavaScript

Browsers schedule requests to optimize navigation

• Document-aware optimization
  • Identify and prioritize critical resource requests
  • E.g. CSS, (non-async) JavaScript
  • Using lookahead parsing, resource priority assignments, …
• Speculative optimization
  • Learning user-specific navigation patterns
  • E.g. pre-resolving DNS, TCP pre-connect, pre-rendering, …

We can assist navigation optimization

• Ordering resource types in document structure
  1. CSS – CSS fetching blocks rendering
  2. Critical JavaScript – Also blocks rendering
  3. Defer non-critical JavaScript – To load asynchronously
• Providing hints
  • Using <link rel="…">
  • dns-prefetch, subresource, prefetch, prerender

The Resource Waterfall tells only part of the story

• User experience also depends on other factors
  • User need and link click order
  • Browser cache
  • Intermediary caches
  • User's hardware
  • User's browser
  • Connectivity: wired, Wi-Fi, mobile, …
  • …
• WebPageTest may give a more complete picture

Browsers take care of networking

• Request can be afforded in different ways
  • HTML
  • Fetch
  • WebSockets
  • …
• Understanding networking stack is important
  • For optimization and debugging

Five network layers

Application

HTTP, SMTP, …

Transport

TCP, UDP, …

Network

IP

Data

Ethernet, Wi-Fi, Mobile, …

Physical

Cables, radio waves, …

Layers contribute to speed

Latency

Time between sending and receiving packet

Bandwith

Maximum amount of data that can pass

• RTT – Round-trip time
  • Time for request going from sender to receiver, and back
• Either latency or bandwidth may be more important
  • Video streaming is bandwidth limited
  • Interactive applications are latency limited

Latency is the bottleneck,

and the fastest byte is a byte not sent.

Ilya Grigorik

Data connection types for the Web

• Ethernet – Wired connection
  • Stable and low latency, high bandwidth
• Wi-Fi – Wireless connection
  • Variable latency and bandwidth
• Mobile networks – Wireless connection
  • Variable latency and bandwidth
  • More complex and costly than Wi-Fi
  • Possibly better performance than Wi-Fi

Ethernet is stable

• Internet backbone is wired
  • Mostly fiber-optic connections
• Ideal: connect all devices via ethernet
• Reality: wireless connections are more convenient
  • 58% of Web traffic is mobile
  • Web infrastructure must cope with mobile reality

Similarities between mobile and Wi-Fi

• Variable latency
  • If latency is too high → transport protocol with lower overhead (UDP)
• Variable bandwidth
  • Less problematic for traditional Web applications
  • For multimedia: adaptive video bitrates

Differences between mobile and Wi-Fi

• Cost of bandwidth
  • Wi-Fi traffic usually costs less than mobile network traffic
  • Signal switching from mobile to Wi-Fi for large downloads
• Battery usage
  • Data transfer over Wi-Fi is more battery-friendly
  • Idle connections are more efficient over mobile networks

Anticipate variability in mobile networks

• Connections change over time – devices are mobile
  • Tower-to-tower handoffs cause delays (100ms - seconds)
  • Transitions between modern and legacy networks (5G, 2G)
• Connections will be unavailable
  • Transient errors will happen – plan and retry
• Decouple UI from network communication
  • Execute requests in background
  • Enable interactions even if offline (localStorage)

Anticipate high latencies in mobile networks

• Radio goes to low-power state when idle
  • High latency (100-1000ms) to reestablish connection
• Impact on scheduling requests
  • Request in bursts (carriers prioritize bursty flows)
  • Prefer push over polling
  • Defer non-critical requests until radio is active
  • Anticipate user needs and pre-fetch
  • Avoid progressive loading
  • …

Transport protocols for the Web

• TCP – Used by HTTP/1.x, HTTP/2
  • Reliable connections, ordered packets
• UDP – Used by WebRTC
  • No guarantees
• QUIC - Used by HTTP/3
  • Multiplexing without head-of-line-blocking

Setting up TCP connections is expensive

• Three-way handshake
  • Introduces full roundtrip of latency
• Slow start
  • Reduced initial bandwidth to avoid congestion
• Reuse TCP connections
  • TCP keepalive – default since HTTP/1.1
• Lower RTT by positioning servers closer to user
  • Content Delivery Networks

TCP suffers from head-of-line blocking

• TCP guarantees in-order packet delivery
  • Packets have sequence numbers
• Lost packet will cause delay for later packets
  • Packet needs to be retransmitted

UDP provides no guarantees and minimal overhead

• Use if not all features of TCP are needed
  • Reliability
  • Ordered delivery
  • Flow and congestion control

QUIC aims to supersede TCP

• Solves problems with TCP
  • Multiplexing of multiple requests over one connections
  • Head-of-line-blocking
• Limited adoption
  • Used on 26.8% of all Websites
  • Supported by 95% of browsers

HTTP – transfer of hypermedia

• Browser-directed
  • Following hyperlinks
  • Fetching subresources
• Fetch API – HTTP requests via JavaScript
  • For one-time client to server requests and polling
• Server-Sent Events – One-way messaging
  • Persistent HTTP connection from client to server
  • Server can send stream of text messages

WebSocket – Bidirectional messaging

• Communication of text and binary data
  • Persistent connection
• Standalone protocol
  • Mainly designed to use in browsers

WebRTC – Peer-to-peer messaging

• Arbitrary connection direction
  • One-to-one, one-to-many, …
• Arbitrary message types
  • Bytes, text
• Enables audio/video streams between peers
  • Initially designed for videoconferencing

Critical Rendering Path

• Steps to go from bytes to pixels on screen
  • HTML, CSS, JavaScript, …
• "Critical"
  • Only those resources required for rendering a page
  • Some steps may be skipped, e.g., CSS media="print"
• Can be slow for complex and dynamic pages
  • Optimize for human perception: FCP, LCP, …

Metrics for human-perceived load speed

• FCP: First Contentful Paint
  • Time until something is rendered
  • Blue line in Chrome's Resource Waterfall
• LCP: Largest Contentful Paint
  • Time until rendering of largest image or text block
  • Red line in Chrome's Resource Waterfall
• And more!
  • Relevant metrics depend on your type of Web Application

DOM: Document Object Model

• Tree-based representation of document structure
  • Stored in memory, derived from HTML files
• Steps for constructing a DOM
  • Conversion: raw bytes to characters (e.g. UTF-8)
  • Tokenizing: characters to tokens (e.g. <body>)
  • Lexing: tokens to objects (e.g. a body object)
  • DOM construction: tree represents relationships
• Event handlers can be attached to nodes
  • For triggering events: "click", "mousedown"

JavaScript can block DOM parsing

• Parsing is paused on <script> tags
  • JavaScript can change document structure
  • Especially problematic for remote scripts
• Avoid blocking
  • Async script tags: Load JS asynchronous to parsing
  • Defer script tags: Load JS once DOM is available

Preload scanner for subresources

• Preload scanner runs concurrently next to parser
  • Looks for subresources
  • <img>, <link>, …
• Fetch subresources immediately
• Placing resources early in document is beneficial
  • CSS stylesheets
  • <link rel="preload"> for resources that will be required

CSSOM: CSS Object Model

• Separation of concerns
  • Designers (CSS) and developers (HTML)
• Tree-based representation of style rules
  • Stored in memory, derived from CSS files
• Steps for constructing a CSSOM
  • Identical to DOM construction
• Rules cascade down in tree
  • Hence the name Cascading Style Sheets

CSS is a render blocking resource

• Time to first render delayed until all CSS is loaded
  • To avoid FOUC issues: Flash of Unstyled Content
• Optimize CSS usage
  • Refer to CSS in document head
  • Avoid CSS imports to reduce additional roundtrips
  • Consider inlining critical CSS
  • Use media queries
    <link href="…" … media="orientation:portrait" />
<link href="…" … media="print" />

Render Tree combines DOM and CSSOM

• DOM and CSSOM are independent from each other
  • DOM: document structure; CSSOM: document style
• Render Tree combines both
  • Prerequisite for layout step
• Render Tree only contains visible nodes
  • Nodes with display: none are omitted
  • Non-renderable notes are omitted, e.g. <meta>
  • visibility: hidden considered, which occupy space.
  • Screen size is not considered yet at this step!

Constructing the Render Tree

1. Traverse each node in the DOM
   • Only consider visible nodes
2. Apply style rules to each node
   • Matching rules are derived from CSSOM
3. Emit nodes with content and computed styles
   • Result is a tree structure

Layout Stage (=reflow) computes positions

• Render Tree only contains content and styles
  • Layout calculates position and size of each node
• Dependent on viewport
  • Area of the window in which content can be seen
• Many aspects to consider
  • Font-size, line breaks, …
• Outputs a Box Model
  • Contains absolute positions and sizes of each node

Painting Stage converts to pixels on screen

• Ordered iteration over Box Model
  • In order of HTML sequence
  • z-index can override order
• Outputs sequence of Paint Records
  • E.g. draw rectangle at position X with size Y, with color Z
• Paint Records are rasterized
  • Conversion to pixels
  • Some records are expensive, e.g. solid color vs gradient

Compositing splits page into layers

• Rasterization can be expensive
  • Redo upon scroll due to change in viewport
  • Redo on animations
• Grouping parts of page into layers
  • Each layer can be rasterized separately
  • Browser will guess layers, or use CSS hint will-change
• Rasterized layers can be composed
  • Layers can be moved on scroll or animation

Compositing marks Non-fast Scrollable Regions

• Regions that may be slow to rasterize
  • E.g. region with event handler on scroll
  • Compositor has to wait for main thread
• Non-fast Scrollable Regions slow down rendering
  • Avoid event listeners on large elements
  • Or use { passive: true } listeners

Dynamicity for Web pages with JavaScript

Example: handle button clicks

document.getElementsByTagName('button')[0]

  .addEventListener('click', () => {

    console.log('Clicked!');

  });

Standardized as ECMAScript (ECMA-262)

• ECMAScript is a standard for scripting languages
  • A blueprint, not a language
  • Also includes JScript and ActionScript
• JavaScript conforms to the ECMAScript standard
  • Also contains Web APIs (DOM, …)
  • JavaScript is an informal name
• Ecma is a nonprofit standards organization
  • European Computer Manufacturers Association until 1994

TC39 committee works on ECMAScript

• Yearly version releases
  • ES2023, ES2022, ES2021, …
  • ESNext refers to next version in progress
  • Major version numbers until 2015 (ES6 = ES2015)
• Language proposals go through 5-stage process
  • Implemented by engines in stage 3~4 → available to public

JavaScript engines execute JavaScript code

• Modern engines use just-in-time (JIT) compilation
  • Combines ahead-of-time compilation with interpretation
  • Older engines were interpreters (flexible, but slow)
• Since 2017, most engines also support WebAssembly
  • Execution of compiled code for improved performance

Spidermonkey is the engine in Firefox

• The first JavaScript engine
  • Initially developed for Netscape
• JIT compilation since 2009
  • Interpreted before
• Adoption beyond Firefox
  • MongoDB and CouchDB databases
  • Adobe Acrobat/Reader, Flash, Dreamweaver
  • GNOME desktop environment
  • …

V8 is the engine in Chromium

• Released in 2008
  • Together with Chrome
• JIT compilation upon release
  • Much faster than any other engine upon release
• Adoption beyond Chromium
  • Node.js and Deno runtime environments
  • Electron for desktop apps
  • MarkLogic database
  • …

JavaScriptCore is the engine in WebKit

• WebKit is the browser engine of Safari
  • Forked from KDE's JavaScript engine
• JIT compilation since 2014
• Adoption beyond WebKit
  • Other MacOS apps: Mail, App Store, …
  • Bun runtime environment
  • React Native (partially until 2020)
  • …

More JavaScript engines

• Chakra – Internet Explorer
  • Discontinued
• Hermes – Designed for React Native
  • Optimized for fast startup
• Graal.js – part of GraalVM
  • Execution on the Java VM
• …

Browser APIs expose browser and system capabilities

• Beyond DOM and CSSOM
  • Manipulation of pages
• Access via JavaScript
  • Sometimes technology-specific (e.g. CSS)
• Standardized through different efforts
  • W3C, WHATWG, …

Web Workers enable multi-threaded JavaScript

• Creation of Worker()'s
  • Refers to a JavaScript file that needs to run
  • Not all APIs are available, e.g. DOM
• Message-based communication
  • structuredClone() datatypes (excludes functions)
• Different types of workers
  • Dedicated: Access from a single context
  • Shared: Access from contexts with same origin
  • Service: Proxy worker between network and app

Web Storage enables data persistence

• sessionStorage
  • Duration of page session (browser open, reload, restore)
  • Shared between pages with same origin
• localStorage
  • No automatic expiration
• Access to Storage interface
  • Key-value pairs

WebAssembly for low-level code execution

• Assembly-like language
  • Languages can target it for compilation
  • C/C++, Rust, Python, …
• Aims for better performance
  • Nearing native performance
• Interaction with JavaScript
  • Causes overhead when lots of data has to be translated

WebGL exposes GPU access

• Aims for optimizing interactive graphics
  • Usage within the <canvas> tag
• API closely conforms to OpenGL
  • OpenGL ES 2.0 for Embedded Systems

Beyond browser APIs with extensions

• Browser APIs are limited
  • Solve a specific problem by design
  • Standardized across browsers
• Browser extensions allow full browser manipulation
  • Few limitations
  • Manual installation of users
  • Ad blockers, password managers, time tracking, …
  • Less common with powerful browser APIs