Web Application Performance: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
== Introduction == | |||
Two fundamental limits on performance: | |||
* Amount of data | |||
* Distance (limited by speed of light - fast but not instant) | |||
Other considerations: | |||
* Number of requests - each one involves 1+ round trips (though can re-use connections) | |||
== Cache == | == Cache == | ||
| Line 27: | Line 38: | ||
* Difficult now that everything is HTTPS | * Difficult now that everything is HTTPS | ||
* No longer transparent for ISPs etc. | |||
* Can pay a cache provider | |||
Latest revision as of 15:13, 11 July 2023
Introduction
Two fundamental limits on performance:
- Amount of data
- Distance (limited by speed of light - fast but not instant)
Other considerations:
- Number of requests - each one involves 1+ round trips (though can re-use connections)
Cache
HTTP headers
- Cache-Control: max-age
- ETag: Hash of file, don't download if unchanged (but beware of how this is calculated, e.g. Apache may use inodes by default which differ on load-balanced servers)
- Expires: Re-download after this
- Last-Modified
Most headers won't help on first visit.
Request headers (conditional GET request):
- If-Modified-Since: Date/time
- If-None-Match: Hash (ETag)
Problems:
- Can't override the browser behaviour - once it's cached with an expiry time
Fingerprinting / hashing
- Gets around caching, effectively forces a new request by using a unique filename based on file contents
- Effectively allows you to set long expiry times but still force updates, e.g. 12 months for site logo
Proxies / intermediates
- Difficult now that everything is HTTPS
- No longer transparent for ISPs etc.
- Can pay a cache provider