section.io Website Performance and Security Blog

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

The recently released top 50 people in Australian ecommerce has again demonstrated section.io’s market leadership.

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.

When creating a website, you have to set up a lot of moving pieces to actually make it function. For example, creating an HTTP server with software like Nginx or Apache, constructing the application logic sitting behind your web server like a Node app or Magento installation, defining and styling the user facing application with HTML and CSS, and if you have application state you’ll also need to configure a database. Once your application is ready to use you’ll have to start worrying about performance, security, and scalability by using software like Varnish Cache, a Web Application Firewall, and/or a Content Delivery Network.

The section.io platform was built with the understanding that changes to sites are often deployed to a series of environments before being deployed to Production. We anticipated that with each set of site changes, there may also be some corresponding changes required to how section.io applies caching, optimization, and security rules to the site. The section.io platform handles this by using multiple branches within a single git repository per site, i.e. section.io Application.

Sometimes site downtime is unavoidable. Major upgrades, database server crashes/backup restoration, and a number of other events require that your site temporarily go offline. Whatever necessitates the outage, you don’t want your users getting meaningless server errors or having their browsers timeout waiting for a response from your site.