21 December 2018Comments are off for this post.

How to boost EpiServer site performance and reduce visitor drop out rate

Before showing you HOW you can improve your Episever site performance, first I'd like to tell you WHY you should optimize it.

In today’s world, people don’t want to wait for things. They want them instantly.

Research shows that you have no more than 3 seconds to load your page. After this time, you can lose a lot of customers. If you want to be reckoned with these days, you have to match up to these expectations.

That’s why the performance of your site is one of the key features to make your site successful. Nowadays most traffic comes from 3G mobile networks, which is not super fast. Google knows that and if your site is slow, that may impact your position on the popular search engine result page (SERP).

Fortunately, there is a very handy tool which will help you to keep good practice on your site. This tool comes from Google and it is called Lighthouse.

What is Lighthouse?

Lighthouse is a 'ready to use automated tool' which helps you to maintain the quality of your webpage. It checks performance, good practices or even SEO. After running it against your site you will get helpful metrics together with some nice tips about how to improve.

Lighthouse is really easy to use. The easiest way is to open the Chrome browser and go to the "Audit" tab in DevTools. After running an audit you will see general numbers about how well your site is performing with a list of passed audits. You will also see what you should fix and how to fix the issues. For more advanced usage you can read the Lighthouse official documentation or since it is an open source project - you can even write your own metrics.

One of the most important factors is called first contentful paint. It is the time needed by the browser to render the first bit. I don’t have to tell you how important it is to keep it low, so users will see that your page is actually loading. Lighthouse shows you a few tips and one of them is that you will need to improve your server response time.

How can you speed up EpiServer site performance?

Before you start optimizing your website be sure to run an audit and save your results. It will be really inspiring to see how well the optimization went and you will have a reference to see actual improvement. This can be your bargain card for a raise. Apart from profiling your EpiServer application, there are some universal tips.

Avoid dynamic properties

DynamicProperty class is a really nice API to play with EpiServer objects in a flexible way without using tons of code. There is a strong temptation for developers to use it. Unfortunately, you can read in the EpiServer docs that:

“EPiServer.DataAbstraction.DynamicProperty is a non-cached API for administrative purposes and should not be used on normal templates that are not for administrative purposes. Using this API on your templates will significantly impact performance.”

Switch to Entity Framework

The second big step is to migrate from the default EpiServer Object-Relational Mapper called Dynamic Data Store to Entity Framework. There is a really nice blog post about how to make migration in EpiServer. After reading it you will know about some additional benefits coming from this change.

Configure your server properly

I would like to focus on the lighthouse performance audit. It is divided into four parts: metrics, opportunities, diagnostics and passed audits. The first one will give you the gist about the general condition of your page. Then comes opportunities and diagnostics which can help you upgrade your page. After you introduce all fixes to your page hopefully you will extend the list of passed audits.

 

google light house audit

 

Enable Text Compression

There is a strong correlation between page size and site speed. Fewer bytes to download means faster page loads. The average page size in 2018 was around 1.88 MB. To keep the size of your site small you can compress its source.

Lighthouse automatically detects if you are using any compression on the server. Enabling GZIP is often just one flag on your server, which can improve your metrics significantly.

Thanks to GZIP compression on the front page of alt.dk for our main HTML, CSS and JS files were compressed to 86 KB from the original 380 KB which is only 22.63%.

enable text compression

In the size column, you can see download size compared to the original size

 

Deliver your page in an efficient way

Besides the size of your page, it is important to deliver it in an efficient way. This is why you should use the content distribution network (CDN) for your static resources.

The general idea is to keep the resources closer to the end user. Your scripts, styles and images are distributed to multiple servers and then users will download them from the closer server. Thankfully it is quite easy to configure CDN for EpiServer.

Upgrade Protocol

The next thing you can improve is the protocol. To send a package with data to your client using Hyper Text Transfer Protocol (HTTP), for every resource, the server needs first to build a connection, send the actual data and then close the connection. However, according to Google research, the average number of resources for one site is around 115.

It would be nice to use the same connection for multiple data packages. Switching to HTTP/2 will do the trick. It allows you to send your resources faster to the client. If your site is already running HTTPS the change for HTTP/2 will be easy and painless.

Finally, Lighthouse will help you to set a proper browser cache time for your assets, which is helpful for returning users. There is no need to fetch resources again and again if they have not changed.

Our client Alt.dk is a leading Danish lifestyle magazine using EpiServer CMS. After 2 years of cooperation, the site now ranks in the top 10 of the Danish website index. See Case Study.  

 

product owner egmont

 

How can you speed up your frontend?

When you open Chrome devtools you can easily check what is the heaviest part of your website. In most cases images are. Thanks to Lighthouse here are a few hints on how you can decrease the size of graphics on your site.

Optimize images

Your site will be displayed on many different devices with different screen sizes and resolutions. Small images will be not readable on big screens or could be stretched in a weird way. On the other hand, big images can corrupt page layout and exhaust mobile network capacity. This is why you should use responsive images on your website.

Different images for different devices

All modern browsers have a special mechanism for serving different versions of an image for different screen sizes. Thanks to this you can display wide picture on desktops and the same picture cropped to show only the most important part on phones.

Here is an HTML markup for it:

<img srcset="image-320w.jpg 320w,
 image-480w.jpg 480w,
 image-800w.jpg 800w"
 sizes="(max-width: 320px) 280px,
 (max-width: 480px) 440px,
 (max-width: 800px) 800px"
 src="image-800w">

You can define different image sources inside srcset attribute for different sizes. There is a nice article about responsive images, which will help you to better understand the whole idea.

For example, the main image in the article on alt.dk is 1960px wide and its size is about 2 MB, however on mobile devices with small screens it is 420px with its size only about 154 KB.

Compress images

The next obligatory thing to do is to compress your images. There are various algorithms which will help you to save the network capability. Fortunately, there are a few ready to work solutions which can help you. Lighthouse apart from pointing out your uncompressed images also provides you already compressed images for downloading. All you need to do is just copy them to your site.

Load only images that are needed

When a user enters your page, especially on mobile devices, he will only see the very top of it. Probably the logo of your site, header, title of an article or maybe the few first lines. To see the next part he will need to scroll down. But the decision if he will stay or not may be based on the page load time.

To save that time and also your server resources you can postpone loading images from a further part of the site. This technique is called deferring offscreen images and Lighthouse is really looking for it.

When you enter the alt.dk homepage on an iPhone 5, you will get only 13 images at the beginning. After scrolling down another 22 images will be loaded. That is an improvement which saves 2.1 MB for the first page load (more than 60% of all images are not loaded if they are not needed).

How to defer offscreen images

The next opportunity to speed up the loading time of your site is to defer offscreen images. The general idea pointed out by Lighthouse is that users need to see only images displayed currently in the viewport. All other images, which are mostly below, can be loaded later or even never if the user decides to leave your site. To make it happen you need to change your HTML displayed for every image:

<!-- An image that eventually gets lazy loaded by JavaScript →
<img class="lazy" src="placeholder-image.jpg" data-src="image-to-lazy-load.jpg" alt="I'm an image!">
<!-- An image that is shown if JavaScript is turned off →
<noscript>
  <img src="image-to-lazy-load.jpg" alt="I'm an image!">
</noscript>

And add some Javascript for switching data-src with src when the image is near the viewport. For detecting that moment you can use IntersectionObserver . I strongly recommend to read an awesome article about that.

Optimize parts of the layout

On every modern design, you can find some small graphics displayed all over the site. It could be the logo, a fancy button, arrows or lines which are really hard to display using only HTML with CSS.

The first idea is to draw them using PNG files. Unfortunately, there are a few disadvantages in this approach. Let's say you need to display 4 different ornaments in 3 different colors on your site. Then you need to include 12 additional files. That will make 12 additional requests to your CDN server. It is time and resource consuming. You can combine all these images to one sprite, but it is still hard to add new colors or elements and it is hard to scale.

A Better approach is to use inline SVG. You can change the color of them from code and since it is a vector-based image, you can easily scale them. This approach is recommended by Lighthouse, but on the other hand, you can easily fall into another issue. When your SVG element is complicated, you can make your DOM tree too large. Lighthouse recommends:

  • keep less than 1500 nodes in total,
  • with a maximum depth size of 32 nodes
  • without a parent node with more than 60 child nodes.

So there is an even better solution: you can convert all your SVG elements into font with a really simple tool called Icomoon. Now your ornaments will be scalable, you can change colors using CSS and you can download it using one request for the custom font. For example, to display your clock icon, all you need to do is add this to the HTML code:

<i class="icon-">clock</i>

As you can see now your ornaments will be optimized and easy to maintain.

 

Summary

Website speed & performance is critical to any business success. A slow loading page can put off a huge chunk of visitors from visiting your website and knowing more about your business. Luckily with the help of Google Lighthouse, you can analyze how your site performs. It can point you towards the pertaining issues on your site as well as recommending practical solutions.

And if you’re site is running on EpiServer, then the steps I laid down above can boost your website performance drastically. So try them out and if you have any further questions, feel free to leave them in the comments below or just email me and I’ll be happy to answer them.

alt denmark

15 November 2017Comments are off for this post.

The OWASP Top 10 – what’s not so new in 2017

The Open Web Application Security Project (OWASP) is getting ready to release their Top 10 biggest web development mistakes. It’s strikingly terrifying that a lot of the items on the list have been there since the initial release in 2003.

2003! That’s almost 15 years ago! Let’s see what we’re still messing up when developing web applications.

TL;DR

Injection flaws, Cross-Site Scripting (XSS), Insecure Direct Object References and Cross-Site Request Forgery (CSRF) are still such common mistakes that they’ve been on the OWASP Top 10 for almost 15 years. If you don’t start educating your developers then we’re all doomed!

The OWASP Top 10 list for 2017 is still not ready to be published. The community was presented with a Release Candidate but it was rejected. The horror started when it was realised that the discussion was only about the inclusion of two new points on the list. That's 8 points that have been there since 2013 and no one has ever voted to remove them. We uniformly agree that they are as viable today as they were 5, 10 or 15 years ago!

What items have been on the list the longest? They’re the ones that have been talked over thousands of times. That the programming community figured out the best ways to deal with years ago. So, what are they and why can’t we get rid of them?

Injection flaws

In the simplest form injection attacks are based on the fact that you have an input in your app that gets passed to some part of the system as actual code – NOT AS USER INPUT. This means that anyone with basic programming skills can get access to all your data (if you’re vulnerable to SQL-injection) and all your users’ data (if you’re vulnerable to JavaScript-injection) etc.

This item has been on the OWASP list for almost 15 years and has been with us since the birth of Web 2.0. This means that almost anyone with technical skills can take advantage of these bugs and hack your web app.

How is this possible that injection bugs still exist in 2017? We’ve been struggling with them for decades and there are thousands of posts on how to deal with them once and for all. There’s even a cheat sheet from OWASP themselves created in March 2009.

Cross-Site Scripting

Cross-Site Scripting (XSS) is slightly related to injection attacks. Their only difference is that they do not harm your servers, so might go unchecked for years before someone realises that there’s a problem. The idea behind this one is also really simple. When you allow users to change any part of your web app (i.e. write a comment, change their profile description), it’s possible for them to insert scripts that run in other users’ browsers without them even realising it.

These scripts have access to all local data in the users’ browsers (session cookies, access tokens, even some local files), but furthermore, they can act on the user’s behalf without their knowledge. Attackers can post comments or do anything that your app allows them to do (if your app is a store, they can order items and send them to any address). It’s even possible for the attacker to send data to their remote servers introducing a big data breach of your service.

XSS flaws can be difficult to identify

These bugs are a lot harder to find when they reach the end users. It requires going through logs (finding suspicious activity) or just scanning all the user’s input in search of any malicious codes. OWASP themselves suggests the following:

  • The best way to find flaws is to perform a security review of the code and search for all places where input from an HTTP request could possibly make its way into the HTML output. Note that a variety of different HTML tags can be used to transmit a malicious JavaScript.
  • Nessus, Nikto, and some other available tools can help scan a website for these flaws, but can only scratch the surface. If one part of a website is vulnerable, there is a high likelihood that there are other problems as well.

But on the other hand, making sure you’re not vulnerable to these bugs is really easy. SImply sanitize all input that you get from users, validate it, escape special characters and you’re set to deliver a product that is not prone to such attacks.

As before OWASP offers a cheat sheet, which was also created in 2009.

Cross-Site Request Forgery

Cross-Site Request Forgery (CSRF) is an attack that allows the attacker to execute unwanted actions on a web application that a user is currently authenticated in. These attacks require a lot more setup than Injection and XSS but are equally devastating.

By preparing a special website, sending e-mails or with just a little help from social engineering an attacker can make actions on behalf of another user.

These attacks, similar to XSS, can do anything that the user that was targeted can do within your app (transfer funds, make purchases etc.). If the targeted user is an administrator of the service then it’s possible to get access to all the data the service has stored.

Again, cheat sheet Again, 2009!

These attacks can, fortunately, be solved with not a lot of effort. OWASP advises to do two things:

  1. Check standard headers to verify the request is the same origin.
  2. Generate and check the CSRF token

These two actions, in a well-designed application, should take a couple hours to implement and get rid of this problem once and for all.

Insecure Direct Object References

Insecure Direct Object References is the last on the list that’s been there for over a decade. This attack relies on the sloppiness of the developers and by missing authorization checks when your application provides direct access to objects based on the user-supplied input. For example, in an invoicing application, there might be a URL that enables the user to view an invoice in the system.

It might look something like https://my_app/invoice/1923 where 1923 is the ID of the shown invoice. If for some reason, the developers writing code for this app forget to check if a user is allowed to see the invoice, you can access all the invoices by just guessing their ID numbers.

There’s no uniform solution for this problem as it’s really dependent on your systems’ implementations, but, as usual, cheat sheet, unfortunately, this one is still in progress.

Most large scale applications developed this age are so complex that they use a lot of well-established patterns and frameworks to do trivial things (i.e. data access). If you’re using any kind of object-relational mapping (ORM) you already have the necessary ingredients to do authorization for each element accessed.

If it has to be checked against the user, instead of fetching it directly using ID, then fetch it using your current user model that you need to have access because of user authentication. For instance: don’t fetch invoice with ID number 1923 from all invoices but from the list of invoices that are related to your current user.

Final words

We’ve seen huge breaches in web applications with enormous amounts of data stolen. These attacks are covered by the media and big companies who need to inform their users about them. Most of them are not caused by the issues we’ve covered here. But for some reason OWASP is still saying that these are the real problem. Most of the apps on the internet are vulnerable when it comes to trivial tasks.

How to solve your problems? Educate your developers! Make sure they know about these issues and not after they’ve created them themselves. Make them learn from others’ mistakes and not their own.

 

OUR OFFICE

Wojskowa 6, 60-792 Poznań, Poland
+48 506 798 998
office@setapp.pl

OUR OFFICES

POL: Wojskowa 6, 60-792 Poznań, Poland
+48 506 798 998
office@setapp.pl

ISR: 220 Hertzel Street, 7630003 Israel

COMPANY DATA

Setapp Sp. z o.o.
VAT ID: PL7781465185
REGON: 301183743
KRS: 0000334616

PRIVACY POLICY

OUR OFFICES

PL: Wojskowa 6, 60-792 Poznań, Poland
+48 506 798 998
office@setapp.pl

ISR: 220 Hertzel Street, 7630003 Israel

COMPANY DATA

Setapp Sp. z o.o.

VAT ID: PL7781465185
REGON: 301183743
KRS: 0000334616

PRIVACY POLICY

OUR OFFICE

Wojskowa 6, 60-792 Poznań, Poland
+48 506 798 998
office@setapp.pl

COMPANY DATA

Setapp Sp. z o.o.

VAT ID: PL7781465185
REGON: 301183743
KRS: 0000334616

PRIVACY POLICY

 COMPANY DATA

Setapp Sp. z o.o.
VAT ID: PL7781465185
REGON: 301183743
KRS: 0000334616

PRIVACY POLICY

OUR OFFICES

POL: Wojskowa 6, 60-792 Poznań, Poland
+48 506 798 998
office@setapp.pl

ISR: 220 Hertzel Street, 7630003 Israel

COMPANY DATA

Setapp Sp. z o.o.
VAT ID: PL7781465185
REGON: 301183743
KRS: 0000334616

PRIVACY POLICY

OUR OFFICES

PL: Wojskowa 6, 60-792 Poznań, Poland
+48 506 798 998
office@setapp.pl

ISR: 220 Hertzel Street, 7630003 Israel

COMPANY DATA

Setapp Sp. z o.o.

VAT ID: PL7781465185
REGON: 301183743
KRS: 0000334616

PRIVACY POLICY

OUR OFFICE

Wojskowa 6, 60-792 Poznań, Poland
+48 506 798 998
office@setapp.pl

COMPANY DATA

Setapp Sp. z o.o.

VAT ID: PL7781465185
REGON: 301183743
KRS: 0000334616

PRIVACY POLICY

klacz
Clutch award badge
topdizajn
svg-image
svg-image
svg-image
svg-image
Instagram Icon
svg-image
svg-image
smart-growth
european-union

©2020 Setapp. All rights reserved.