Pre-installation question about Comet Cache and Cloudflare

@julius-e “The fragment identifier functions differently than the rest of the URI: namely, its processing is exclusively client-side with no participation from the web server” (Wikipedia: Fragment identifier).

That means that the server never actually sees the #.WJ3JuNKP9hE portion of that URL and since Comet Cache is a server-side page-caching plugin (it uses PHP, a server-side language, to capture the output of PHP and serve static HTML versions of the page to improve performance), there’s no way for Comet Cache to see that fragment identifier and take it into consideration when caching a page.

So that means Comet Cache would see these three URLs as the same URL (even though their fragment identifier might be different, or absent) and will create and serve a single cache file:

mysite.com/category/my-article-url/
mysite.com/category/my-article-url/#.WJ3JuNKP9hE
mysite.com/category/my-article-url/#.Ju9EwPKf3Sj

If you need to cache those three pages separately, you should see if you can use query strings instead of a fragment identifier, e.g., /my-article-url/?WJ3JuNKP9hE. You could then enable GET Request caching in Comet Cache (Comet Cache → Plugin Options → GET Requests) and Comet Cache would cache each variation of the URL as separate and unique pages, each one getting its own cache file.

@julius-e writes…

I take it that even with the fragment, these pages benefit from caching?

Yes, absolutely! The # fragments don’t even make it to the server, so Comet Cache treats the URL as if it didn’t contain those fragments and caches the page as expected. (If you were using query strings, e.g., ?WJ3JuNKP9hE, you’d need to enable GET Request caching to have Comet Cache cache those pages and each fragment would be cached separately. In your case you’re using # fragments, so Comet Cache just creates a single cache file for the page and serves it as expected.)

I activated client side caching as I am the only one who logs in/updates the site, but Gmetrix actually saw an increase in load times.

Hmm, it’s odd that you would see an increase. If you see a definite, consistent cause-and-effect (enable -> test result slow, disable -> test result fast) my only guess would be that allowing Client-Side Caching is somehow having an adverse side-effect in combination with your server configuration (which itself would be odd, but it’s all I can think of).

However, if you haven’t already, I do highly recommend enabling Browser Caching (which is different than Client-Side Caching; see the note about this in the Client-Side Cache section of Comet Cache). Browser Caching generally adds a considerable speed increase. In Comet Cache Pro you can enable this via the Apache Optimizations section and Comet Cache will automatically insert (and automatically remove if you disable the feature or disable Comet Cache) the necessary rules in your .htaccess file to enable Browser Caching. But if you’re using the free version of Comet Cache, you can simply edit the file yourself and add the following to the top:

# Enable browser caching.
FileETag mtime size

<IfModule expires_module>
  ExpiresActive on
  ExpiresDefault "access plus 1 week"
</IfModule>

Many thanks for your detailed replies, leaving a well deserved 5 star rating

Woohoo! Thanks so much! 😀