| XF Tips & Tricks (Free) XenForo Emoji Performance Optimization

[Staraddons]

Compatible XF Versions

2.1, 2.2, 2.3

​

This setup may look like overkill if the JoyPixels CDN already performs well for your audience. For us, it addressed a real, measurable latency issue in production, particularly on restricted corporate networks, mobile users, and slower connections.

XenForo Emoji Performance Optimization

If you're using JoyPixels with Cloudflare, serving emojis through a Worker under your own domain can be faster, more stable, and more reliable than hitting the JoyPixels CDN directly, especially in restricted or high-latency networks.

This guide has been updated with:

• A safer Cloudflare Worker example.
• Request method and emoji path validation.
• Explicit Cloudflare cache TTL handling.
• Immutable browser caching.
• Updated repeated TTFB measurements.
• Clarification that this setup does not mirror or redistribute JoyPixels assets.

Why this matters?

On a production XenForo site with a Türkiye-based audience, we observed consistent problems with the default JoyPixels CDN setup:

• High and inconsistent latency.
• Requests blocked or delayed on corporate / institutional networks.
• Slow emoji rendering on mobile and low-bandwidth connections.
• Occasional missing emoji assets.
• Noticeable latency spikes depending on ISP or network conditions.

These issues were reproducible across different ISPs and environments. The root cause appeared to be external CDN access reliability, not XenForo itself. We tested multiple approaches, including local hosting, different CDN paths, and cache tuning. The most stable and practical solution was:

Serving JoyPixels through our own domain using a Cloudflare Worker with edge caching.

What this solution does?

• Terminates emoji requests at Cloudflare edge locations.
• Fetches emoji assets from JoyPixels via jsDelivr.
• Caches successful responses aggressively at the edge.
• Serves emojis from your own domain.
• Reduces dependency on direct third-party CDN reachability from the client.
• Does not touch your XenForo origin server.

This is not a XenForo template modification or core change. It is pure request routing and cache control

Important clarification

This setup does not mirror, copy, or redistribute JoyPixels assets. The Worker only routes valid emoji requests through your own Cloudflare edge and relies on Cloudflare caching. Emoji files are still fetched from the CDN path when needed.

Benefits observed

• Lower average TTFB.
• Much better latency consistency.
• Fewer CDN-related spikes.
• More reliable emoji loading on restricted networks.
• Improved repeat-load performance with immutable browser caching.
• Zero additional load on the XenForo server.
• No XenForo template or core changes required.

Implementation

Create a new Cloudflare Worker and use the following script:

export default {
  async fetch(request) {
    const url = new URL(request.url);
    if (request.method !== "GET" && request.method !== "HEAD") {
      return new Response("Method not allowed", { status: 405 });
    }
    if (!url.pathname.startsWith("/emoji/joy/")) {
      return new Response("Not found", { status: 404 });
    }
    const emojiPath = url.pathname.replace("/emoji/joy", "");
    if (!emojiPath.endsWith(".png") || emojiPath.includes("..")) {
      return new Response("Invalid emoji path", { status: 400 });
    }
    const response = await fetch(
      `https://cdn.jsdelivr.net/joypixels/assets/8.0/png/unicode/64${emojiPath}`,
      {
        cf: {
          cacheEverything: true,
          cacheTtlByStatus: {
            "200-299": 31536000,
            "404": 3600,
            "500-599": 0
          }
        }
      }
    );
    const headers = new Headers(response.headers);
    headers.set(
      "Cache-Control",
      "public, max-age=31536000, s-maxage=31536000, immutable"
    );
    return new Response(response.body, {
      status: response.status,
      headers
    });
  }
};

What this does technically?

• Only processes requests under /emoji/joy/
• Allows only GET and HEAD requests
• Only allows valid .png emoji assets
• Rejects invalid paths before proxying
• Fetches emoji assets from jsDelivr's JoyPixels path
• Caches successful emoji responses for 1 year
• Caches 404 responses only briefly
• Does not cache 5xx responses
• Adds immutable browser caching for better repeat-load performance

Worker route

Add a route in Cloudflare: yourdomain.com/emoji/joy/*
*This ensures emoji requests are handled by the Worker and never reach your XenForo origin server.

XenForo configuration

In XenForo AdminCP, go to emoji settings and set the emoji base URL to: https://yourdomain.com/emoji/joy
*No other XenForo changes are required.

Cloudflare cache rule

This is strongly recommended. Go to: Cloudflare > Cache Rules
Condition: URL path starts with /emoji/joy/
Actions:

• Cache eligible: ON
• Edge TTL: 1 year
• Browser TTL: 1 year
• Serve stale while revalidating: ON

*This helps guarantee fast emoji delivery after the first edge hit.

Optional robots.txt rule

After deploying this setup, we observed that some bots were requesting emoji asset URLs under /emoji/. Emoji images are static assets and have no indexing or SEO value. To reduce unnecessary crawl noise and log entries, you can disallow emoji paths.

User-agent: *
Disallow: /emoji/