Features
-
Proactive caching
Your content is always fresh in the cache. Instead of purging expiring content, it is updated from the origin. Your content is always served from the cache - and always fresh.
-
On-demand updates
When content is updated, you can notify our CDN of the changes either via special HTTP headers or PURGE requests. Or just update everything at once when your are finished with your changes.
-
Cache everything
All of your content is cached according to the HTTP caching specification (RFC 9111). But you also have the possibility to cache any other request, such as POST requests. So you can cache e.g. your GraphQL queries or complex POST calculations.
Other features
- HTTP/2
- Automatic SSL
- Page Rules
- Instant purge
- CNAME configuration (with redirects)
- Root domain configuration
- HTTP caching standard compliance
- Brotli compression (coming soon)
- Image optimization (coming soon)
- IPv6 (coming soon)
Use cases
-
Create a static version of your site
We never evict (invalidate in HTTP caching speak) content from the cache. Rather, all content is kept in the cache until instructed otherwise. This means you can e.g. take your origin server completely offline without worrying about the availability of your site.
Example customer: SaaS company spinning up their WordPress instance about once per month to make changes to their marketing site. -
Cache complex queries and API responses
We cache all read requests - including POST requests that only read content. If a response is the same every time and causes no side effects, it will be served from cache. This means you can enjoy lightning-fast speeds even for e.g. GraphQL queries and complex API requests.
Example customer: 3D modeling company caching gigabytes of renders based on dozens of different inputs. -
Update dynamic content on demand
Sometimes content or data changes, in which case we update the cache where needed. The next time someone requests the changed content, the updates will already be in the cache. This means you can cache even the most dynamic content while always keeping everything up to date.
Example customer: Financial services company keeping their customer portal with slow 3rd party dependencies entirely in cache.
Frequently Asked
I'm trying out your CDN, but my PageSpeed Insights performance score doesn't change - why?
In short, because the tests do not really measure network performance. Also, site performance depends on a lot of other factors as well, such as the amount of images and JavaScript loaded.
PageSpeed Insights (i.e. Lighthouse) and other similar tools artificially slow down the network while testing a site, so you won't necessarily see the (very real) network performance improvements in these tools. The best way to test your site is to simply browse it yourself and see the difference.
One way to see the network performance of your site is to check the Chrome User Experience reports (CrUX) e.g. by checking your site on PageSpeed Insights. A Content Delivery Network will directly impact the "Time To First Byte (TTFB)" metric seen in under "Discover what your real users are experiencing". This metric shows how long it takes your server to start responding to a real user request, and improvements here will translate to better performance directly.
How can I be sure that my site will always be online after I switch to acache.io?
You don't. Sometimes entire networks or datacenters go down, and this is no different for acache.io. However, we have servers all around the world, many layers of monitoring, and many layers of fallbacks in case of issues. Our servers are located in the most secure and reliable datacenters available. We do have a 100% uptime guarantee (Service Level Agreement), and if we do not hit that we'll pay you back x10.
How do I know my forms won't stop working or you won't cache pages for logged in users?
Our caching system is compliant with the HTTP caching standard (RFC 9111), which means we do not cache things your server tells us not to cache. As a general rule, things that cause side effects (e.g. change data, interact with another system such as email signups, and so on) are never served from the cache. Authenticated requests (with the "Authentication" HTTP header) are also never served from cache, and servers such as WordPress will tell us in the response not to cache responses that are authenticated via a cookie - e.g. the admin pages.
Having said that, it is of course possible that servers do not follow the HTTP standards, which might lead to caching content that should not be cached. In these cases you can leverage our Page Rules to manually add the desired caching behavior for any page or other URL.