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.
1. Increase the API request delay
The median API response time is currently 115 ms. 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 (see also @Krinkle's remarks in T70861#3129780).
2. Review the Cache-Control header
... with @GWicke with a view to increasing the max-age part.
3. 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, we may want to use an LFU or LRU replacement strategy.
This requires input from both Product and Design.