1. Is this PHP or XenForo-side code? No. This is a Cloudflare Worker written in JavaScript and running entirely at the Cloudflare edge.
2. Does this change XenForo core or templates? No. No XenForo core files or templates are modified. Only the emoji base URL is changed in AdminCP.
3. Does this add load to my XenForo server? No. Emoji requests are handled by Cloudflare and do not reach the XenForo origin server.
4. Does this mirror or redistribute JoyPixels assets? No. This setup does not copy, mirror, or redistribute JoyPixels assets. The Worker only routes valid emoji requests to the CDN path and lets Cloudflare cache eligible responses.
5. Is long-term caching safe? Yes. JoyPixels emoji assets are static and versioned. Successful emoji responses can safely be cached long-term.
6. What happens if an emoji does not exist? 404 responses are cached only briefly. This prevents repeated unnecessary upstream requests without permanently caching missing assets.
7. What happens if the CDN returns an error? 5xx responses are not cached. Temporary CDN errors should not be stored long-term.
8. Does this reduce Worker request usage? Not completely. Requests matching the Worker route still invoke the Worker. However, invalid requests are rejected early, successful assets are cached more effectively, and unnecessary upstream fetches are reduced.
9. Does this help on restricted or slow networks? Yes. This was the main reason we implemented it. In our tests, the Worker route provided lower average TTFB and significantly better latency consistency.
10. Is a Cloudflare Cache Rule still recommended? Yes. The Worker already defines cache behavior, but a Cache Rule for /emoji/joy/ adds another clear layer of cache control and makes the setup easier to manage.