Комментарии 13
Уже сколько раз видел статьи про кеширование изображений с помощью sw, и так и не могу понять, а зачем? Ведь браузер изображения и так кеширует.
например, для офлайн режима
к сожалению нет, для того что бы мы уверенно могли сказать, что наше приложение может работать в офлайн режиме, мы должны загрузить картинки сами, когда есть связь, а не надеяться на то, что пользователь ранее к ним обращался и на клиенте это закешировано.
Вы наверное про Google workbox не слышали, можно всю статику принудительно закешировать
Руководство по Workbox: https://github.com/harryheman/React-Total/blob/main/md/wb/wb.md. Пример кеширования статики с помощью СВ при его установке: https://github.com/harryheman/Modern-HTML-Starter-Template/blob/main/service-worker.js
1. В отличии от кеширования браузером, кеширование с использование sw дает вам полный контроль над вашим кешем. Браузер не дает Вам никаких инструментов по управлению кешем вообще. Как и не дает гарантий того, что кешироваться что-то вообще будет, не смотря на все ваши заголовки. А если и будет закешировано, то может быть удалено от туда уже через минуту работы. По сути, в случае если вы полагаетесь на браузер, вы ничего не знаете о том как обстоят дела с кешем.
2. sw и cache api позволяет работать с кешем даже тогда когда связь отсутсвует.
3. работая через sw, Вы и только Вы решаете, что когда и как будет загружаться. Честно говоря я вообще не представляю как можно делать современный проект без sw.
@aio350погоняли ваш Imgproxy, он так не хило жрет ресурсов для картинок 2k+ , не годится для обработки в реалтайме для высоконагруженных систем.
Он умеет делать ресайз и сохранять конечную картинку на диске и потом при следующем запросе без обработки её использовать?
И еще вопросик, часто бывает нужно получать в ответе конечный файлнейм , а не диктовать его название от клиента.
Тоесть загружаешь 1.png , а тебе дают GUID в ответ 4593-053534-545-3453.png. Такое умеет?
Imgproxy, к сожалению, не мой. Вот его разработчик: https://github.com/DarthSim
Сохранение файлов на диске и их последующее использование без запроса к imgproxy похоже на кеширование.
Честно говоря, не знаю, полистайте доку: https://docs.imgproxy.net/
он так не хило жрет ресурсов для картинок 2k+ , не годится для обработки в реалтайме для высоконагруженных систем.
Он умеет делать ресайз и сохранять конечную картинку на диске и потом при следующем запросе без обработки её использовать?
nginx вам в помощь
Тег figure решает специфические семантические задачи и не может использоваться как универсальное средство при верстке изображений.
За исключерием случаев, когда для Вас не важно то, каким образом ваша верстка будет интерпретирована сторонними средсвами анализа контента. Только в этом случае, тег figure Вам тем более не нужен, и только будет бесполезно потреблять ресурсы.
Постоянные запросы к favicon связана с особенностями работы devtools. Если Вы закроете devtools и перегрузите страницу, обнаружите что все работает как ожидается.
JavaScript: ускоряем загрузку изображений с помощью Imgproxy, Cache API и Service Worker API