We are pleased to announce today that we have added ShieldSquare Bot Mitigation and Management to section.io’s modular web optimization platform. Both section.io and Shieldsquare focus on improving the security of web applications and thier content.

To maintain a well performing and highly available website, it is important to provide several layers of security. In addition to normal patching, user access management and good development hygiene, we recommend you use a combination of following to ensure your website is protected:
DNS Protection
HTTPS
Network Protection
Caching
Rate Limiting And IP Blocking
Web Application Firewall

Competition as an e-retailer has never been tougher. The marketplace has become so crowded that if I want to buy a boutique reindeer outfit for my dog, I have literally dozens of options. Online shoppers have an overwhelming number of choices, and even the slightest blemishes on their user experience can turn them somewhere else. One of the easiest ways to lose customers is through slow pageload times.

Announced in 2016 but postponed until now, Google has decided that all web certificates issued after April 30th, 2018 must comply with the Chromium CT Policy in order for the Chrome web browser to honor them. When Chrome visits a website with a certificate issued after this date that does not comply with the Chromium CT (Certificate Transparency) policy, it will display a full page warning notifying the user that their connection is not CT-compliant. To see what this will look like, check out this link

What is Cache Warming?
Cache warming is a process that some engineers follow to try and improve the performance of their website.
Many websites depend on caches. A cache is a system that stores portions of the website in high-performance storage to help avoid reading from systems that have poor performance or to reduce pressure on bottlenecks in the system.
Caches exist in many places in your website setup. For example, there are caches within your CPU, built into your database, and even within specific applications like Redis or Memcached.

Once you’ve been introduced to Varnish Cache’s power as a web application accelerator (HTTP caching reverse proxy) and understand the basics of the benefits it provides, you’ll quickly want to make sure it is maximizing the number of responses it can handle itself and not pass on to your web application server. To do this, it will need to match the incoming requests to items in its cache as often as possible without ever giving an incorrect or mismatched response.

Varnish Expiration vs Eviction
When investigating cache hit rates in Varnish Cache it is important to differentiate between objects that have expired from the cache and objects that were evicted from the cache.
An expired asset is one that has exceed the sum of its TTL(time-to-live) value and grace period and should be removed from the cache. An evicted asset, however is one that is removed from the cache because Varnish Cache has run out of space in memory and must delete a piece of data prematurely. The former is a regular part of the caching process, the latter can cause unnecessary performance problems.