Мне кажется, что использование ETag дало бы значительный положительный эффект для производительности при загрузке страниц, поскольку большинство HTML-страниц не кэшируются. Это позволило бы избежать необходимости серверу отдавать страницу, если клиент уже её загрузил.
Было ли какое-либо обсуждение этого вопроса?
Возможно, я ошибаюсь, но Discourse уже сильно зависит от клиентского JS, поэтому клиент загружает минимальный объем данных. Почти всё загружается при первом посещении, а затем кэшируется. Не знаю, насколько ETags могут улучшить этот процесс кэширования.
Например, первая загрузка моей страницы составляет ~800 КБ, а вторая — ~40 КБ.
Discourse уже достаточно хорошо спроектирован и настроен для кэширования.
Большинство ресурсов сайта (JS, CSS) имеют уникальные URL-адреса, которые генерируются при каждом обновлении сайта с использованием хеша ресурса, что позволяет устанавливать длительное время кэширования.
Полагаю, что загрузки на сайте (изображения, аватары и т. д.) также используют уникальные URL-адреса.
Большинство полноценных страниц, которые вы видите, являются динамическими и не должны кэшироваться агрессивно. В принципе, можно было бы реализовать кэширование по типу ETag, при котором при каждой загрузке страницы проверяется наличие новых или отредактированных сообщений. Не совсем понятно, почему команда приняла решение не делать этого.
Я должен был уточнить: ресурсы действительно кэшируются хорошо — речь идёт о самом HTML-документе (первый запрос).
Большинство полных страниц, которые вы видите, динамические и не должны агрессивно кэшироваться. Я полагаю, что возможно реализовать кэширование на основе ETag, при котором при каждой загрузке страницы проверяется, нет ли новых или отредактированных постов. Не совсем понятно, почему команда решила не делать этого.
Да, речь именно об этом, но я не думаю, что ETag генерируются вручную таким образом — они могут базироваться на исходном HTML, который отдаётся, и сообщать клиенту: «эй, это в точности то, что вы видели раньше, просто используй это».
Дело в том, что, насколько я понимаю, это уже происходит с JS на стороне клиента. Так что у вас нет передачи HTML туда и обратно.
HTML загружает JSON с сервера, и этот запрос JSON мог бы использовать ETags. В настоящее время этого не происходит, хотя я не уверен в аргументации команды по этому поводу.
Первый запрос к странице действительно возвращает уже отрендеренный контент до загрузки JSON с сервера через XHR, что, как вы верно заметили, также происходит.
Вы можете убедиться в этом, посмотрев на сетевой запрос типа “Document” в отладчике Chrome; в нём (по крайней мере в моём случае) категории уже отрендерены.
Вот пример того, что возвращается в ответ на запрос документа:
Ваш запрос бессмысленен, так как Discourse — это JavaScript-приложение, которое не загружает HTML: все «страницы» формируются в реальном времени с помощью исполняемого JavaScript-кода.
Ваш запрос бессмысленен, потому что Discourse — это JavaScript-приложение, которое не возвращает HTML.
Я полностью уважаю ваш опыт и экспертизу в этой области, но я запускал десятки веб-приложений с рендерингом на JavaScript, которые используют ETags в корневом ответе (если контент может быть переиспользован).
все «страницы» создаются исполняемым JavaScript-кодом в реальном времени.
Скриншот, который я опубликовал выше, показывает HTML, возвращаемый до выполнения любого клиентского кода, поэтому на бэкенде (предположительно Rails) точно есть что-то, обслуживающее этот маршрут.
Каждое сообщество Discourse, которое я изучал (кроме этого), изначально возвращает версию сайта без JavaScript со всем отрендеренным контентом, предположительно для поисковых роботов.
Приношу извинения, если я сильно ошибаюсь, но я не думаю, что мои слова «бессмысленны» — возможно, я просто неправ.
Только для пользовательских агентов-роботов, так что это не очень полезное наблюдение.
Только для агентов-краулеров
Это не то, что я вижу при запуске этого:
curl -H "User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36" https://community.midi.city/
Это не агент-краулер, но возвращается вышеуказанная полезная нагрузка.
В любом случае, я считаю, что ответ на мой запрос о ETag — «нет», так что спасибо за обратную связь, и, возможно, это будет пересмотрено в какой-то момент.
Верно, ответ — категорическое «нет» по обеим причинам: философским и техническим.
(Ассеты — это отдельный вопрос, но использование уникальных имён файлов с GUID является значительно более предпочтительным подходом, поэтому ETags в целом несколько устарели.)
Даже для API? Я могу понять, что для небольших запросов это, вероятно, не стоит того, но просмотры тем могут достигать 20 КБ, что в сумме даст ощутимый объем. Но с другой стороны, не так много людей просматривают темы повторно, если нет новых сообщений…
В этом и суть. При повторных просмотрах точно такого же контента если вы离线, мы уже отображаем весь контент из кэша браузера, не обращаясь к серверу.
Обновление этого механизма для загрузки даже при наличии подключения к интернету требует инвалидации кэша, поэтому, естественно, это сложно.
Отлично, что это работает. Я бы подумал, что заголовок cache-control: no-cache, no-store означает, что ответы API никогда не будут попадать в кэш браузера.
Они не сохраняются. Ну, это сложно. В процессе задействовано несколько кешей 
Он не попадает в обычный кеш браузера, который все знают и любят. Но существует Cache Web API, доступный в браузерах через JavaScript, который используется для кэширования ответов с целью обеспечения навигации по ранее прочитанному контенту в автономном режиме.
