Siento que los ETag tendrían un gran impacto positivo en el rendimiento de la carga de páginas, ya que la mayoría de las páginas HTML no están en caché. Esto evitaría que el servidor tenga que servir la página si el cliente ya la ha descargado.
¿Se ha pensado en esto?
Puede que esté equivocado, pero Discourse ya depende en gran medida de JavaScript del lado del cliente, por lo que lo que descarga el cliente son datos mínimos. Casi todo se carga en la primera visita y luego se almacena en caché. No sé realmente cuánto podrían mejorar los ETags ese proceso de caché.
Por ejemplo, la primera carga de mi página es de ~800 KB, la segunda es de ~40 KB.
Discourse ya está bastante bien diseñado y configurado para la caché.
La mayoría de los recursos del sitio (JS, CSS) tienen URLs únicas que se generan cada vez que actualizas el sitio con un hash del recurso, para que puedan tener tiempos de caché largos.
Creo que las cargas del sitio (imágenes, avatares, etc.) también utilizan URLs únicas.
La mayoría de las páginas completas que puedes ver son dinámicas y no deberían almacenarse en caché de forma agresiva. Sería posible, supongo, implementar un tipo de caché con ETag que verifique en cada carga de página si no hay publicaciones nuevas o editadas. No estoy seguro de por qué el equipo decidió no hacer esto.
Debería haberlo aclarado: los recursos sí se almacenan en caché correctamente; lo que estoy comentando es el documento HTML (la primera solicitud).
La mayoría de las páginas completas que puedes ver son dinámicas y no deberían almacenarse en caché de forma agresiva. Supongo que sería posible implementar un tipo de caché con ETag que verifique en cada carga de página si hay publicaciones nuevas o editadas. No estoy seguro de por qué el equipo decidió no hacerlo.
Sí, esencialmente es eso de lo que estoy hablando, pero no creo que los ETag se generen manualmente de esa manera; pueden basarse en el HTML sin procesar que se sirve y decirle al cliente: “oye, esto es exactamente lo que viste antes, úsalo”.
El caso es que, según mi comprensión, eso ya ocurre con el JS en el lado del cliente. Por lo tanto, no hay HTML yendo y viniendo.
El HTML carga JSON desde el servidor, y esa solicitud de JSON podría utilizar ETags. Actualmente no lo hace, aunque no estoy seguro del argumento del equipo al respecto.
La primera solicitud a una página definitivamente ha renderizado el contenido antes de cargar el JSON desde el servidor mediante XHR, lo cual, tienes razón, también está ocurriendo.
Puedes verificar esto examinando la solicitud de red de tipo “Documento” en Chrome Debugger; debería tener (al menos en mi caso) las categorías ya renderizadas.
Aquí tienes un ejemplo de lo que se renderiza desde la solicitud del documento:
Tu solicitud carece de sentido porque Discourse es una aplicación de JavaScript que no recupera HTML; todas las “páginas” se generan mediante código JavaScript ejecutable en tiempo real.
Su solicitud no tiene sentido porque Discourse es una aplicación de JavaScript que no recupera HTML.
Respeto totalmente su experiencia y conocimientos en este ámbito, pero he ejecutado docenas de aplicaciones web renderizadas con JavaScript que utilizan ETags en la respuesta raíz (si el contenido se puede reutilizar).
todas las “páginas” se construyen mediante código JavaScript ejecutable en tiempo real.
La captura de pantalla que publiqué anteriormente es el HTML que se devuelve antes de que se ejecute cualquier código del lado del cliente, por lo que definitivamente hay algo en el backend (asumo que Rails) sirviendo esta ruta.
Cada comunidad de Discourse que he revisado (excepto esta), inicialmente devuelve una versión del sitio sin JavaScript con todo el contenido renderizado, presumiblemente para los rastreadores.
Disculpas si me equivoco por completo, pero no creo que esté diciendo cosas sin sentido; es posible que simplemente esté equivocado.
Solo para agentes de usuario de rastreadores, por lo que esta no es una observación útil.
Solo para agentes de usuario de rastreadores
Eso no es lo que veo al ejecutar esto:
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/
Ese no es un agente de usuario de rastreador y, sin embargo, devuelve la carga útil anterior.
En cualquier caso, creo que la respuesta a mi solicitud de ETag es “no”, así que gracias por la retroalimentación y quizás se reconsiderará en algún momento.
Correcto, la respuesta es un no rotundo y definitivo por razones tanto filosóficas como técnicas.
(los activos son un tema diferente, pero utilizar nombres de archivo únicos con un GUID es un enfoque muy superior, por lo que las etiquetas ETag son, en general, algo obsoletas.)
¿Incluso para la API? Podría entender que para las solicitudes más pequeñas probablemente no valga la pena, pero las vistas de temas pueden llegar a ser de hasta 20 KB, lo que se iría acumulando. Aunque, por otro lado, no mucha gente ve los temas repetidamente a menos que haya nuevas publicaciones…
Ese es el punto. Para las vistas repetidas del mismo contenido exacto, si estás desconectado, ya renderizamos todo el contenido desde la caché del navegador sin tocar el servidor.
Actualizar eso para que cargue incluso si estás conectado implica invalidación de caché, así que naturalmente es difícil.
Ah, qué bueno saber que funciona. Habría pensado que el encabezado cache-control: no-cache, no-store significaba que las respuestas de la API nunca entrarían en la caché del navegador.
No lo hacen. Bueno, es complicado. Hay varias cachés en juego 
No entra en la caché del navegador convencional que todos conocemos y amamos. Pero existe una Cache API Web expuesta a los navegadores en JS que se utiliza para almacenar en caché las respuestas con el fin de proporcionar navegación sin conexión del contenido leído anteriormente.
