RFC: ETag support for Router

[wmertens]

Champion

@wmertens

What's the motivation for this proposal?

Objective

Enhance Qwik Router by introducing ETag support for routes and routeLoader$ functions to optimize server-side rendering (SSR) performance and caching efficiency.

Proposed Solution / Feature

Proposal

ETag Export for Routes:

Allow routes (e.g., index.tsx) to export an eTag function or include an eTag property in the head export.
The eTag function generates a unique ETag based on the route's content or relevant data.
For routes generated from .md files, derive the ETag from a hash of the rendered content, it will be just a string.

ETag Support for routeLoader$:

Enable routeLoader$ functions to generate ETags based on dynamic data (e.g., user-specific data like logged-in status).

Server-Side Behavior:

When a browser requests a route with an ETag after cache expiration, the server compares the provided ETag with the current route's ETag.
If the ETags match, the server returns a 304 Not Modified response, bypassing SSR to reduce server load.
If the ETags differ, the server performs SSR and returns the updated content with a new ETag.

Build-Time ETag Integration:

• Incorporate the manifest hash into the ETag to ensure cache invalidation on new builds.
• Static routes, like .md files, can export their content hash

Benefits

• Shorter cache durations can be set for SSR responses without significantly increasing server load.
• External caches (e.g., CDN) can leverage ETags for efficient caching and validation.
• Improved performance for users with faster responses via 304 Not Modified.
• RouteLoaders can expose

PRs/ Links / References

No response

[wmertens]

implemented for routes but not yet routeLoaders