Let’s begin with a small thought experiment and look at Usain Bolt, the greatest sprinter of all time. He is a world record holder in the 100 metres, 200 metres and 4 x 100 metres relay. Well, he is fast, but then how about Michael Phelps, who is the most successful and most decorated Olympian of all time, with a total of 28 medals? The question ‘Which one of them is faster?’ is difficult to answer.
You can apply a similar thought experiment to the world of online shopping. Which online shops are fast, or even the fastest? Before we get to the conclusion - if we ever get there - let’s get familiar with the online shops websites’ speed, CMS’s, BUXUS, and other criteria in detail, so we can make an informed decision. Only a few days ago, we published a blog article on this topic from Martin Krupa’s book called ‘Online shop - from an idea to success'. We noticed an increased interest in this dilemma and thus we decided to contribute with another view of this parameter so crucial for every online shop.
What is speed and what affects it?
Speed of a particular website is time needed for it to load. Speaking of speed, it’s important to realise that there are:
- Backend speed - how much time it takes for the server to generate the website and send it to the client
- Frontend speed - how much time it takes for the web browser to fully load the website - render CSS, display pictures, load JavaScript, etc.
We are in almost full control in the backend area, as any changes here are rather straightforward. For example, we can optimise the website to make it load faster, as we know exactly what we need to do to achieve this result (we know the application code, we control the servers). The only uncertain thing is the client’s connection speed which determines how fast the client can download the loaded website (data). We can make this download faster by ensuring server’s connection to the internet is fast and trying to make the final website (HTML) as small as possible. Next, we need to look at server set up, i.e. turning Mod_Pagespeed and memcache on and setting up the HTTP/2.0 protocol.
Frontend is a little bit more difficult to handle, as it’s usually affected by multiple factors:
- Client’s device (slow mobile phone, fast mobile phone, tablet, PC, … )
- Browser - with add-ons that the user installed
- Client’s connection speed
How does CMS itself affect the speed?
CMS can improve backend speed - how fast the website loads, what caching is used, etc.
CMS can affect frontend through JavaScript minification, picture resizing, decreasing HTML code’s size, CSS compresion.
How to measure speed?
Anybody can test their website’s speed using any of the multiple tools market offers. What do they measure and what they don’t? How reliable is this measurement?
Two most used tools are:
- Page speed Insights (Google lighthouse runs this on the background)
- Yslow (plugin for browsers, you can find it online on https://gtmetrix.com/)
Advantages:
- Immediate feedback on things we can change - e.g. large pictures
- Clear numbers that tell us whether our speed improved after we implemented suggested changes
Values we get from Google Analytics calculated as an average of the whole website are very helpful as well.
Disadvantages:
- The measured data are applicable only to a particular URL, not the whole website (Page Speed Insight offers similar results in Field Data - they show data for last 30 days aggregated from all websites)
- The measured values relate to only one particular device and place (where the website loads from, so if most of my customers live in Slovakia while they have to download data from the USA, the measured times might be incoherent and distorted).
What slows us
Both pictures and videos might slow us down mainly due to their size (how long it takes for the client to download them from the server). That’s why we recommend using these tricks when dealing with pictures:
- Do not send oversized pictures - if the picture size in HTML is 200x200, there is no need for a larger picture (e.g. 500x500) as the client will not be able to see it anyway
- We can try to minimise pictures’ size by using the right format, e.g. webp
- Use lazy loading, i.e. load the picture only when the client wants to look at it - if there is a picture outside the viewport - somewhere at the end of the website - it is not necessary to load it before the client scrolls down to it.
We can use similar principles when we deal with videos; however, in this case it is more important to choose the right compression format to minimise their size to save data.
Other content is JavaScript with CSS, this is not directly visible to the user.
Generally speaking, any (e.g. marketing) tool we use on the website (mostly as JavaScript code - directly or via GTM) will slow it down in one way or another.
Recommendation: once we decide to include a tool on our website, we should do it asynchronously, meaning JavaScript will not block the main websites loading and will work ‘in the background’. This will postpone execution of the script, but this should not matter using marketing tools.
There is more than 42 ways to optimise your online shop´s speed
… so let’s choose some examples for backend:
- Application architecture
- Infrastructure scaling - adding servers
- Using caching (memcache, redis, DB caching)
- Varnish (see the picture from Analytics below, which shows how we effectively increased client’s online shop’s speed by using varnish).
Examples for frontend:
- JS and CSS minification
- JS and CSS combination
- Pictures lazy loading
- Pictures optimisation, conversion to other formats (e.g. webp)
- HTML minification
- Setting up caching for pictures, CSS, JS
- Mod_pagespeed
These are the main activities we do at ui42 to increase speed.
CMS BUXUS powered by ui42 and its speed
These are the main activities we do at ui42 to increase speed.
We can say that BUXUS sees backend speed as its priority - and if developers work the way they are supposed to (and the way standard for BUXUS), the result is fast.
Regarding frontend, BUXUS gives developers more freedom but at the same time offers solutions to achieve higher speed. If developers use JavaScript and CSS in BUXUS standardly, the BUXUS can reach higher frontend speed via compression.
In its standard version, BUXUS uses caching of either BUXUS page objects themselves or website parts (e.g. header, footer). Frontend optimisation is achieved via JS and CSS - BUXUS combines CSS into one file and creates layers for JS (layers - JS grouped by website type; imagine one basic layer and then another for the product’s detail - this would contain JS code necessary only for the product's detail)
Additionally, we offer varnish (whole websites caching) as a backend solution, together with using mod_pagespeed or custom speed adjustment for the client.
Support information - Google Analytics
What speed parameters in Google Analytics actually mean:
- Average Page Load Time - the time it takes to load the page (including pictures, JS, etc). It consists of the server time and
- Average Redirection Time - the time it takes to redirect the client from page A to page B. In most of the cases, this number is very small.
- Average Domain Lookup Time - the time it takes for the client’s browser to translate the domain name into IP address. Also this number is usually very small and the only thing that can make it higher is severely misconfigured DNS server.
- Average Server Connection Time - the time it takes for the client to connect to the server. This number should be as small as possible; it’s higher values might result from server’s inability to deal with requests.
- Average Server Response Time - backends most important number.
- Average Page Download Time - the time to download your page. It might be influenced by client’s internet speed, but if the number is too high, we need to decrease the website’s size.
The most important parameters for CMS are:
- Server Response Time
- Average Page Load Time (at least to some extent)
Conclusion
Before joining forces with ui42 he worked with assembler, C, C++, Java, PHP, network administration and also created the web portal booom.sk . It was at ui42 where he ultimately found what he was looking for, as he started as a developer and became the main CMS BUXUS developer and technical architect. Simon is interested in new technologies and loves to see our development team moving to using better and more sustainable code.
If you have any questions about speed, CMS BUXUS or even sport, do not hesitate to contact us!
If you have any questions about speed, CMS BUXUS or event sport, do not hesitate to contact us!
Andrej Kajan
CEO
