Change Details

Since the delay to start fetching a preview from the API and the RESTBase API requires resource revalidation at the edge – `s-max-age` is non-zero while `max-age: 0` – so that the UA doesn't hold stale resources in its private cache(s). Consequently, there are a lot of HTTP requests made while casually moving your mouse around the page. == Steps **1. Increase the API request delay** [The median API response time is currently 115 ms](https://grafana.wikimedia.org/dashboard/db/reading-web-page-previews). Since the API response is artificially delayed so that the preview starts fading in at 500 ms, we can increase the API request delay to 200 ms without affecting the current UX. **2. Cache API responses in memory for the duration of the page session** While #1 will definitely decrease the number of incidental HTTP requests, it seems unlikely that there's great value in a preview for a link changing between interactions during the same page session, e.g. the user dwells on link A, sees preview version 1, abandons link A, waits 1 minute, dwells on link A, sees preview version 2. Since we don't indicate how recently the linked page was updated, seeing a different preview may be confusing. Depending on session length data from [the ReadingDepth schema](https://meta.wikimedia.org/wiki/Schema:ReadingDepth), we may want to use an LFU or LRU replacement strategy. This requires input from both Product and #design.

Since the delay to start fetching a preview from the API and the RESTBase API requires resource revalidation at the edge – `s-max-age` is non-zero while `max-age: 0` – so that the UA doesn't hold stale resources in its private cache(s). Consequently, there are a lot of HTTP requests made while casually moving your mouse around the page. == Steps **1. Increase the API request delay** [The median API response time is currently 115 ms](https://grafana.wikimedia.org/dashboard/db/reading-web-page-previews). Since the API response is artificially delayed so that the preview starts fading in at 500 ms, we can increase the API request delay to 150 ms without affecting the current UX. **2. Cache API responses in memory for the duration of the page session** While #1 will definitely decrease the number of incidental HTTP requests, it seems unlikely that there's great value in a preview for a link changing between interactions during the same page session, e.g. the user dwells on link A, sees preview version 1, abandons link A, waits 1 minute, dwells on link A, sees preview version 2. Since we don't indicate how recently the linked page was updated, seeing a different preview may be confusing. Depending on session length data from [the ReadingDepth schema](https://meta.wikimedia.org/wiki/Schema:ReadingDepth), we may want to use an LFU or LRU replacement strategy. This requires input from both Product and #design.

Since the delay to start fetching a preview from the API and the RESTBase API requires resource revalidation at the edge – `s-max-age` is non-zero while `max-age: 0` – so that the UA doesn't hold stale resources in its private cache(s). Consequently, there are a lot of HTTP requests made while casually moving your mouse around the page. == Steps **1. Increase the API request delay** [The median API response time is currently 115 ms](https://grafana.wikimedia.org/dashboard/db/reading-web-page-previews). Since the API response is artificially delayed so that the preview starts fading in at 500 ms, we can increase the API request delay to 200150 ms without affecting the current UX. **2. Cache API responses in memory for the duration of the page session** While #1 will definitely decrease the number of incidental HTTP requests, it seems unlikely that there's great value in a preview for a link changing between interactions during the same page session, e.g. the user dwells on link A, sees preview version 1, abandons link A, waits 1 minute, dwells on link A, sees preview version 2. Since we don't indicate how recently the linked page was updated, seeing a different preview may be confusing. Depending on session length data from [the ReadingDepth schema](https://meta.wikimedia.org/wiki/Schema:ReadingDepth), we may want to use an LFU or LRU replacement strategy. This requires input from both Product and #design.