michaeldera/image-accessibility-extension

Caching API responses for identical resources

Opened this issue · 5 comments

Right now, if https://soure/of/image.jpg is used (without an alt attribute) in page1.html, Image a11y will query the server for a description. If the user navigates to page2.html, and https://soure/of/image.jpg is also used there, Image a11y will again query the server for description.

Describe the solution you'd like
Image a11y could have a service-worker that intercepts fetch requests and caches responses. (Read more...). If requests to the same image source are made within a certain time frame, the service-worker can just return the cached response.

Additional context
There may be a set back on images dynamically served by the server. For example, if a server returns an apple from <img src="https://soure/of/generate-random-fruit">, and on the next request the the same https://soure/of/generate-random-fruit results in an orange being returned from the server.

Would it be better if this is done here or from the API end?

Would it be better if this is done here or from the API end?

Or both? It would definitely be worthwhile to cache the backend so that if there is another use case for the API, it is easy to implement that.

Would it be better if this is done here or from the API end?

Or both? It would definitely be worthwhile to cache the backend so that if there is another use case for the API, it is easy to implement that.

I think this sounds like a great way to go. A) By caching on the frontend, we save an extra http request. B) By caching on the backend, we also avoid repeatedly running image recognition on the same image, resulting in also in faster response time. Say if user1 already requested a recognition on site/img/image1.jpg, the recognition function will not need to run for user2

Okay awesome, so if you would like to take it up on the frontend, I will get started in the backend.

Thank you ☺ I am happy to