ShimmerCat is brought to you by ShimmerCat AB, a company with offices in Tampa, USA, Stockholm, Sweden, and Umeå in beautiful northern Sweden, where the summers are short but have long days, and the winters are long and come with long nights! 😉
You can reach us directly by either calling or sending us an email:
- +46 704851947
You can also use our ticket system with chat function:
We would really like to talk to you!
What about SSL Certificates?
ShimmerCat Accelerator does TLS termination and needs access to a SSL certificate for the served site. ShimmerCat Accelerator combines the TLS and HTTP/2 fingerprints of the peer to do small adjustments specific to the visitor's browser, and to help separate human and bot activity.
How does ShimmerCat Accelerator work with cookies?
With HTTP/2 Push, the server can do a good guess of what the client needs already from the first request, and send it to the browser. However, for a user that visits a site not for the first time, the server need to know what contents the browser keeps in cache from previous visits. Todo this, the standard is for the browser to communicate an overview of the contents of its cache explicitly. The mechanism is called "cache digests", and it complements HTTP/2 Push.
What compression format does ShimmerCat Accelerator use?
ShimmerCat Accelerator uses Brotli by default for compression of static assets, which compared to gzip is well worth the substantial file size savings.
How to update files?
ShimmerCat Accelerator access files in the same way than your traditional web server, so get to update things in the same way you have been doing it so far.
How does ShimmerCat Accelerator work with locally cached content?
The data we collect allows us to build rules tailored for browser and device, and of course local cache contents, whenever that is possible. More concretely, we can know if a user is a first-time visitor, and estimate the amount of unused bandwidth by looking to its network latency and bandwidth, which ShimmerCat Accelerator can estimate using timings from the handshake process and HTTP/2 Ping frames. That allows us to create a very specific set of resources to push to first time visitors. For not-first-time visitors, we use cache digests via an, opt-in, automatically injected service worker, so that we know which assets are already in the browser’s cache. Some browsers do not implement service workers yet, so our solution is less effective in those cases. However, even browsers that do not implement service workers yet benefit from optimizations for first time visitors and automatic image prioritization.