This guide shows the simple 5-step process needed for a site to start using ShimmerCat.
To create the prerequisites for a successful on-boarding, we first need to gather some preliminary information.
This can be done via, for example, Google Analytics, Alexa, Ahrefs, SEMRush, etc. In this link they show one way to estimate.
There are some different types of certificates, see for example this link, including Domain Validation SSL, Organization Validation SSL, and Extended Validation SSL.
For e-commerces the Extended Validation SSL is usually recommended. But it is not mandatory, and generally the e-commerces acquire the one recommended by the provider of the installed payment system. There are no rules to decide which certificate authority (CA) to use. There are several Certificate Authorities/signatories of certificates, for example: digicert, GlobalSign, GoGetSSL, Let’s Encrypt, Thawte, etc
This typically means information about the division of dynamic and static content, and if it is generally possible to see this through the URL path. With the scheme we tested for the configuration file when we tested the site, we have not encountered any URLs that ShimmerCat could not handle ‘by default’.
If they still appear, in that case we will follow this documentation
sc_packon the edge servers
In this step we simply we use automatic ansible recipes. This step includes:
We usually deploy Haproxy in front of the edge servers. Haproxy has several advantages, including very robust SNI support, live-checks and fallback options. We can also provide configuration and binaries for Haproxy if needed.
The customer can of course use their own load balancer, then the only thing is to make sure it is properly configured. It is not mandatory to have more than one edge server. However, it is advisable to have at least two to ensure redundancy.
The scheme that is often used in this configuration is the following:
Sometimes the application has some configuration that avoids or blocks the requests made by ShimmerCat. In those cases it can be necessary for the application owner to put the IP of the VPS on their ‘white list’.
For the configuration files, we usually do not need any specific info from the application owner before we start. We often perform some pre-tests of the site and the structure to check this, and we will reach out if more info is needed.
To check that everything works fine, it is a good idea to browse the site and check, for example, that:
Also, if the site uses any special external services or integrations, such as electronic billing and/or stock updates, etc, that should also be checked.
When everything is tested, the application owner can simply change the DNS to the ShimmerCat edge servers, or if they want, create a setup where a proportion of the web traffic is directed there. If the site uses a CDN, ideally would be to stop using the CDN when ShimmerCat optimizations are turned on.