The Web

Performance (server-side)

1. Multi-threaded. Start servicing new client while still responding to last client.

2. Cache of (maybe huge numbers of) files in memory.
   Disk reads are slow. So don't make separate disk access for every file request. Instead maintain cache in RAM of frequently accessed files and/or small files which are easy to hold in RAM.
   OS will cache files in RAM and Web server can also cache files in RAM.

   Example of caching files in RAM

   Example: Search my genealogy site. Searches text of web pages. Over 2,400 web pages.
   But search is instant. Think it is caching every single web page in RAM.
   Web pages are text files and so are small compared to images, video. 2,400 pages is only about 20 M total. Could easily hold all that in RAM.
   Entire site is about 60 G. So the HTML text is less than 1/1000 of the site. This is normal enough.

3. Multiple disks. Site could be spread over multiple disks to allow many reads going on at once.

4. Defragmentation of disks. Reduce seek times.

5. Multiple servers. "Server farm".

6. Content delivery network - distributed distribution of resources.

1. Minification - Do various transforms to JS and other files to reduce size (reduce download time) and make parsing faster.
   Text files tend to be tiny anyway.

2. Bundling of Files. One network request for a bundled JS file for the page, instead of 20 network requests for 20 JS files.
   Same for CSS - bundle into one CSS file.
   Reducing network calls can make a big difference.

   Example of file bundling

   Example: On my Ancient Brain site, at time of writing I have 5 JS files for each page, that I bundle into one JS file page.js.

   And I have 13 CSS files for each page, that I bundle into one CSS file main.css.

3. Small / low-resolution images (for any images used inline).
   Can click to expand.
   Definition of "small" changes over time.

Problem: OK to have all (small size) requests come in through one front end and get routed to searching nodes.
Not OK to have all (large size) replies go back through one front end - bottleneck.
Solution: TCP handoff - trick to have the searching node reply directly in a manner that is invisible to client.
The reply load is therefore distributed over all the nodes.

Caching in HTTP

• Caching can be done on server and client.
• Server can cache files in memory.
  Could, say, check file date each time file requested. Only do disk read if changed.
• Client can cache files in memory or disk.
  Does not ask server. Just uses local copy.
• Server can tell client how long to cache a resource for. Uses HTTP headers.

• MDN web docs
  • HTTP headers
  • Cache-Control
  • Last-Modified
  • ETag

• Caching on Apache

• How long to cache for?
  • Some files change regularly: As site develops, HTML, CSS, JS might change many times.
  • Some files hardly ever change: JPEG might be unchanged for years.

Server logs

• Server log
• Common Log Format

• JS could log your mouse movements and page downs and send that info to server.

URI schemes

• URI schemes (see category)

• IANA
  • List of URI schemes

• http: - plain http.
  If intercept traffic can see sensitive data - being replaced by https

• file: - can browse off disk - very useful (may not need prefix)
• mailto: - very useful - but spammers search for these

• ftp: - guest login with no password - pre-web publication system
• news: - usenet - pre-web discussion system - now survives on Google Groups
• gopher: - pre-web publication system
• telnet: - telnet login to a server as guest - not used any more

• mms: (Microsoft protocol) - old streaming media
• rtsp: - streaming media (old RTE streaming)
• rtmp: - streaming media (old RTE streaming, also TG4)
• A lot of streaming uses http: and https: now, using adaptive bitrate streaming.

• wtai: - old WAP system - can launch phone call
• tel: - launch phone call
• callto: - launch phone call / chat
• sms: - send text to phone

• https: - secure http.
  After years of being only for serious sites involving shopping, banking, logins, this is now taking off and becoming the norm for the entire Web.
  Mixed content rule: https should include https content not http content. Browser may enforce this.

• data: - can include image in page direct, without it being a separate file.
• view-source: - can make a link like this to view source
  Blocked by Chrome, and yet when you view source, you get a "view-source:" URL. So why block it?

HTTP client

Uses MIME types.
(a) Plug-in - Runs inside browser process.
(b) Helper application - Separate process.

• MIME types
• Data formats
• Web browsers

Keeping state

Identify user (pay-to-view, register, personalisation).
Shopping carts.

• Cookies
  • Server sends data that is stored on client side (in file).
  • Server can only read cookies that it previously sent (not other site's cookies).
  • How to see your cookies in different browsers.
  • PHP cookies

• Security issue:
  • Can you spoof someone else's cookie?
  • e.g. For user login. If userid is stored as simple cookie, you could set cookie:
    userid = someoneelse
    and then log in as them.

• Sessions are more secure.
  • Typically use underlying cookies but are much harder to spoof/hijack.
  • Session ID
  • PHP sessions

Performance (client-side)

Actually, all of these things, though taking place on the client, involve server support too:

1. Client-side caching
   • Browser maintains cache (in memory or disk or both).
   • How to see your cache files in various browsers.
   • Server tells you what to cache.

2. Site-wide (or ISP-wide) cache via proxy server.

3. Lazy load - of images etc.

4. Infinite scroll - Load more of page on scroll to bottom.
   Use with moderation. See article about why this is only suitable for some types of sites.

5. Delayed loading of resources.
   Delayed running of scripts.
   Fetch some resources / run some JS only after initial page is rendered.