section.io Website Performance and Security Blog

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.

I am extremely excited to join the section.io team in its mission to empower companies to deliver performant and scalable web content. As a former middle school math teacher, I understand what it’s like to fight with slow and unresponsive technology in a hectic workplace setting, and I look forward to partnering with section.io to create a streamlined, painless technological experience for your customers. If technology is not making our lives easier, less stressful, and more productive, then it is not doing its job.

Website security is a hot topic these days, with a new hack of a major institution making it in the headlines every few weeks. You know security is important, and you want to protect your site, but what measures should you take to keep your site secure? The truth is website security will be slightly different for every site. Some large ecommerce sites may need an internal security team in place to juggle the various security tools being utilized, while smaller to mid-size sites can manage without a dedicated security team.

So you’ve installed Varnish Cache, now what? How can you tell whether or not it gave you the performance improvement you expected? You’d be surprised how many people get Varnish up and running and end up flying blind. Without proper logs and metrics you have few ways of knowing if Varnish is actually doing what you think and giving you the performance benefits you are looking for. In addition, Varnish often needs to be tuned after the initial setup to ensure that new items are properly cached and you are accounting for the behaviors of your specific users in your cache setup.