L’article Why using a CDN is critical to your web performance est apparu en premier sur Quanta.

Why improve the alerting system of our QUANTA tool, will you ask? Simply to allow you to react more and more quickly and accurately to changes in the web performance of your website.

As we often say, without precise, immediate, and common to all your teams information, your website may see its conversion rate strongly impacted. And this information, the basis of all optimization strategies, must have an effective alerting system, as close as possible to your concerns.

So, to discover what Phase 2 has in store for you, … Just follow me!

A bag full of new settings: Alerting on the total time of web scenarios and alerting thresholds

Until today, QUANTA’s alerting system allowed you to be notified in the event of an incident on your website. For example, in the classic case of a site undergoing a downtime.

Now, the new alert feature on the execution time of web scenarios, and the setting of thresholds of so-called alerts pushes the concept even further.

First of all, this new feature notifies you when the execution time of your web scenarios exceeds a designated limit. You can configure this limit to compare the run time against a fixed threshold or the average time monitored over a given period of time (last 2 hours, last day, or last week).

Advanced settings detail – Alerting on the total time of web scenarios and alerting thresholds

In parallel with this, we added the possibility to configure alert sensitivity. You will now be able to choose:

• how many failures of the scenario will trigger an alert (ex: I receive an alert when the incident occurred more than 15 times in the span of 25 minutes),
• and how long it will take after the resolution of an incident for the associated issue to be considered as closed (ex: I no longer receive an alert when the scenario has run 20 times without incidents).

This new feature will allow you to mobilize your teams on all incidents that could affect your web performance, not just the most impressive ones.

A more precise analysis: Alerting schedule

The QUANTA analysis and monitoring tool is the co-pilot of your web performance. But to function optimally, it must be able to rely on accurate data. But if these data came to be polluted, you could find yourself under an avalanche of alerts unnecessarily alarming.

That’s why we’ve created this feature that lets you disable certain alerts at certain times of the day. This can be useful, for example, to disable alerts during your maintenance periods.

Advanced settings detail – Alerts scheduling

This feature, available in beta only, is accessible from the window for setting up alerts on the execution time of web scenarios.

If you wish to try this feature, don’t hesitate to contact us.

A more serene environment: Notifications schedule

With this new feature, you can now choose to stop receiving alerts at certain times of the day. This will allow you to no longer receive alerts on weekends, or at night.

Advanced settings detail – Notifications scheduling

However, do not panic! You will now receive an email summary of alerts that you may have missed, to stay informed at all times of everything that happened on your website.

As for the previous one, this new feature is only available in beta, so you’ll need to contact us if you’d like to try it.

There you go ! This is the end for this batch of new features for QUANTA’s Alerting settings! As usual, we are at your disposal if you want to know more, and we are always very interested in your feedbacks!

L’article What’s Up Quanta #14 – Phase 2 for the new Alerting system! est apparu en premier sur Quanta.

L’article How HTTP2 will boost your Web Performance! est apparu en premier sur Quanta.

And what better way to be more efficient strategy-wise than to personalize the tools necessary for the creation of said strategy? As we always say, and repeat: to improve the web performance of a website, it is important to know the profile and behavior of its users.

It is with this idea in mind that Quanta’s Tech Team wanted to refine Quanta’s analysis tools. It will now allow you to:

• Personnalize Quanta, based on your needs,
• Refine your strategy thanks to new indicators.

And for this first batch of new features, we chose to focus on frontend monitoring.

New frontend options

In the settings window for your web scenarios, “Scenario edition”, new options are available for the frontend monitoring.

New options in the web scenarios settings

With these new options, you will be able to:

1. 1. Choose the browser</strong

As previously announced, we made the decision to change the default browser used in Quanta. As of September 1, 2017, Google Chrome is used by 63.98% of Internet users, so we considered that it was more representative of user profiles in general. However, the Firefox option is still available, in the “Browser” drop-down menu! The choice of browser allows you to compare the measures between Firefox and Google Chrome, and choose the browser that your users use the most.

1. 1. Choose the polling region

You now have the possibility to choose from which region of the world you want to measure data, using the “Polling region” option. This allows you, for example, to take measurements closer to your users, or to test the effectiveness of your CDN.

1. 1. Simulate a mobile device

In order to more accurately measure the loading time of your pages on phone or tablet, you can now simulate a mobile device, with the “Simulate device” option. Note that the emulation is done using the browser simulator (which works by replacing the User-Agent and the screen size); mobile hardware performance is therefore not taken into account. In addition, you can also choose the orientation (portrait or landscape) for simulated mobiles.

1. 1. Limit bandwith

To allow you to simulate the behavior of a mobile user more accurately, we’ve added an option to limit bandwidth when running web scenarios. This option (“Bandwith limit”) is available in the advanced configuration of the scenario, and allows you to simulate different types of connections. This parameter is taken into account by both our back-end probes and our front-end probes.

Detail for the bandwith limit option

New frontend metrics

We added several metrics to the frontend metrics, which you can now find on the waterfall page. In order to help you make the most of these new metrics, we have associated a rank system, which will allow you to position yourself in relation to your competition.

Waterfall view of the Speed Index and Detailed loading times

In addition to all the features already available, you can now use:

1. 1. The Speed Index

The Speed Index is a crucial indicator when talking about web performance.

This indicator highlights the loading pace for displaying the different elements of a page.

In other words, if you analyze 2 pages with the same number of elements, and the same Start Render and global loading time, the Speed Index will help you to determine which one is the most web performant between the first, with 80% of its element being loaded in 1sec, and the second, with 20% of its element being loaded in 1sec.

The Speed Index is expressed via an overall score: the lower the score, the faster the page is displayed.

1. 1. The detailed analysis of a loading page stages

With Quanta, you could already see the overall loading time and the DOM loading time. But we decided to highlight the time spent before the reception of the first octet (TTFB), and added the time spent before the Start Render (when the user is no longer faced with a blank page).

L’article What’s Up Quanta #13 – An avalanche of new frontend monitoring features! est apparu en premier sur Quanta.

Why create a plugin for Artifakt?

Modern architectures are increasingly cloud-based, in order:

• to be more flexible when it comes to creation and operating mechanisms,

• and to optimize costs.

But this flexibility often comes with a new complexity when it comes to deploying and administering these cloud-based infrastructures that are very different from static architectures.

And that’s where Artifakt‘s expertise comes in. 🙂 Artifakt makes it easy to deploy and optimize applications in the cloud, and automatically manages their configuration. The platform also makes it possible to adjust the number of instances according to the monitored traffic and the load thus produced.

The QUANTA app, for its part, allows you to follow in real time the web performance of your e-commerce website, and alerts you in case of problems (unavailability or slowdowns, for example).

Based on these characteristics, we determined that there was real synergy and a real added value between our tools. Therefore we thought it logical to build an integration.

How does it work?

This integration is available in the form of an Artifakt plugin that allows you:

• To automatically deploy the QUANTA agents and the PHP module to your instances managed by Artifakt.

• To visualize the deployments made by Artifakt, via our event system, directly in QUANTA.

L’article What’s Up Quanta #12 – The new Artifakt integration is out est apparu en premier sur Quanta.

Time to take a look. 😉

AMP, or the idea of an ever faster web on mobile

Like me, you must have experienced in the past the frustration of not being able to load content on your mobile, even when all you wanted to do was access a simple information.

In this situation, you probably left the website to look for the same content elsewhere. And you’re surely not the only one that reacted like this! Most Internet users react negatively to delays and favor the fastest experiences. This user behavior results in a much better user engagement rate, and better referencing, for websites that have bet on Web Performance.

And it is in this context of a quest for immediacy, that the open-source project AMP was launched in 2016, by Google. This project has since grown to become a community of more than 160 contributors around the world.

In concrete terms, AMP describes a format that allows you to create a page that will appear more quickly on mobile terminals. We are talking here about a median time perceived by users of less than 1 second.

Technically, AMP pages are just “normal” web pages, in HTML, and therefore compatible with all web browsers. They are nevertheless fine-tuned to be very light when loading on a mobile phone. And this is where this project becomes interesting for Quanta, as Google directly broaches the issue of Web Performance on mobile.

How AMP works

AMP tends to several problems for the speed of content display.

• Instant loading (originally Instant rendering)

With AMP, there is the possibility to pre-load links that the user would want to click, so that when he clicks, the content appears immediately as if it were already fully cached (in fact it’s the same principle as the cache for that matter, except that it is built even before accessing the content for the first time).

In order to not overload the CPU and the bandwidth necessary to load content that a user would not eventually see, the AMP system will simply pre-load the top of the landing page only and, when the user actually accesses the content, the rest of the page is loaded while he reads the top of the page.

• Pre-set layout while the items load

In AMP, the size of each element is set in the HTML, in order to avoid “surprises” during loading. Once the text is displayed, it will not move until the user interacts with the page, thus ensuring that the reading is not disturbed.

Of course, this principle is not limited to simple text. 😉 If you have videos and lots of funky stuff (like call-to-actions) that you need to display between the paragraphs of your text, AMP can be a valuable help thanks to the system of placeholders.

With placeholders, you can display banner ads, videos, or any other item with a variety of extensions, but the size of each item will be predefined on the page, with a pre-set area (typically a gray square).

A simple example would be a Youtube video. On an AMP page, a predefined rectangle will appear first, then fill up with the preview of a YouTube video while the user is quietly reading the article.

This system of placeholders for the elements of an AMP page makes the (recurring) problem  of pages that shift, as the elements are loaded, no longer an issue. Ever tried to read a book while being disturb every 3 seconds? Nightmare… Thus, with AMP, you no longer need to “scroll down” to find the line on which you were. And that’s quite an improvement in user experience.

• Fonts

There is some technical cumbersomeness in the loading of fonts, which for most pages comes very late during the process of loading a page. Typically, fonts will be loaded after any content that can possibly call a font, or after all the javascripts. With AMP, the loading order is optimized, and the fonts will be able to load from the beginning, in parallel with the rest, which ultimately makes the final display much faster.

• Analytics and speed finally united

With AMP, the use of tags is limited so as to avoid having several tags potentially blocking the page.

At Quanta, we see that some emerchants frequently keep tags that they no longer use, which slow down their users. And each of these slowdowns has a negative impact on their conversion rates.

In AMP, the subject was therefore taken seriously to avoid as much as possible these untimely loadings. Tags can be called, but only via a single interface that can not slow down the page (asynchronous). For most tag vendors, the implementation of Google’s system is quite simple. But, if you use more “exotic” tags, you’ll need to do little technical adaptation to use them with AMP.

All these specificities of the AMP system didn’t come out of nowhere. These are the result of many tests and clever choices made by a college of performance gurus, who probably had enough of seeing that the Internet is still slow, despite all the technological progress.

An innovation and … a controversy

Google AMP ultimately aims for a loading speed, so far unmatched, on mobile; a loading that now seems “instantaneous”. Therefore, this seems a perfect web performance weapon.

However, like any technical innovation, Google AMP does not come without controversy.

Firstly, it should be noted that this new format was launched without the W3C’s approval, which, as everyone knows, act like a wise council, and is responsible for regulating the Internet in an open and independent way. This tacit respect for the role of W3C on the net often makes it possible for new formats that may appear to become technical standards, and thus to be widely used. By bypassing W3C, Google takes the risk to see the AMP format disappear quickly.

In addition, another recurring criticism made by many web analysts (especially when you look at the articles of The Register, or CSS-Tricks on the subject, which is a must-read) concerns the underlying nature of the AMP project.

As I explained in this article, the concept of AMP aims at adapting the content to technical specifications which, in turn, serve Web Performance. The fear of many authors is that in the long run, in the hope of seeing their SEO in Google maintained, and their appeal to users untouched, the creators of digital content end up impoverishing their productions to stick to the technical recommendations of Google.

Fear certainly justified, but with regard to the benefits in terms of Web Performance, at Quanta, we assume that, as always: “The truth lies somewhere in the middle.”

And you, what do you think of Google AMP? Do you use it for your website? Do not hesitate to leave us comments!

L’article Google AMP, when immediacy becomes a rule est apparu en premier sur Quanta.

Launch a closed-access version of the website, in advance

Some countries and states passed regulations to supervise sales periods. For example, the French government forbids the display of discounted prices, on the first day of the sales period, before 8am. The big problem here, is that most customers are eagerly waiting far before that time! But a massive change in the contents of an e-commerce platform (for example the prices, or the design announcing “Sales”), when said platform is full of users, is sure to be too much for the servers.

Why? Simply because when this horde of users try to access pages that haven’t been put in cache yet (because they’re “new”), the CMS has to do complex calculations that will inevitably overcharge your servers.

So. To avoid this unpleasantness, it is far better to simply close your website the evening before the start of the sales. Trust me, you’ll lose very few customers that night because, come on! Who buys online the day before a sales period? 0_0 And you’ll definitely be thankful for this decision later. Little bonus pointer: put your design team to work and ask them to concoct a kickass maintenance page, with a little teaser video, a countdown, …etc. Now back to business! In parallel to this “closing down”, launch online, with a closed access, the “Sales” version of the website, only accessible to your IP address and your web agency.

This way, between midnight and the official sales launch hour, you’ll be able to check one last time the performance of your entire sales funnel, in its “sales” version, in the prod environment.

I’m insisting on the “in the prod environment”, because even if your web agency gave you the green light in the pre-prod setting, it is better to be safe than sorry. Always check the entire sales funnel in its prod version, before opening hours.

The results will be that, when the hour has come to reopen the website, you’ll just have to drop your beautiful teaser page, and you’ll immediately be able to welcome your customers. Your team will have gained some bags under their eyes during the night, but they will thank you later when they will not have to perform emergency fixings, in haste.

Automatically pre-load your caches

Instead of trying to visit all your website’s pages, by hand, in their “sales” version, before the official launch, it is far more effective to use a bot to do it.

Why, you ask? Because that way, all the “sales” pages will be preloaded before the official launch of your “Sales” close-access website. They will be stored in cache (Varnish, Full Page Cache, or your CMS’s cache), before the arrival of your customers.

The page needs only to be accessed once, for it to be stored in the cache system. That is why a bot is needed; to gradually access to all your “Sales” website’s pages.

Here are some tools you can use for this operation:

• mage-perftest
  HTTrack
  Nutch
  Sphider
  Crawler4j

Just a little warning. These are all “geeky” and powerful tools, so it is important to take your time to conduct the aforementioned operation. If not, you’ll take the risk of simply crashing your website with the influx of requests. So, discuss the “how/when to” with your web agency!

Forbid back-office actions on the first day!

It only takes a simple click in your CMS’s back-office to ruin one of the most important business day of your year. Clicks in the back-office consume a lot of server resources, and it can be dangerous for the platform, especially when they happen at the same time of a buttload of orders.

Our advice? At the very least, inform your e-commerce / sales team that on the first day of the sales period, nobody is to use your CMS’s back office to add new products, or modify the existing ones’ descriptions.

On that day, it’s hands off! No more touch ups! And if you really want to have peace of mind, just plainly (temporarily) forbid the access to your back office to all non-tech/vital users. 😉

You don’t think that’s such a big deal? Well, we’ve seen and measured it, time and again, at QUANTA. A simple back office click can invalidate the caches of a lot of pages, and greatly affect a website (Cf point 2, for those of you that have been following :P).

More info on this subject here.

Temporarily add front-end servers

Warning, it’s time for a little tech talk! 😉 At QUANTA, we observed that for almost all CMS, but specifically for Magento, the peaks in customer activity induce peaks in the CPU load on front-end servers (those that generate the visual pages for e-commerce website), more than the load on database servers. Although it is usually all by itself, the database server is generally less solicited than the rest of the architecture.

And that’s truly for the better. Simply because it is complex to have several database servers working in parallel to hold a larger load, whereas it is very simple to add front-end servers to distribute queries between a string of servers (Commonly referred to as a “server pool”).

In other words, to sustain the load on the first day of the sales period, rather than multiplying the database servers, just multiply the front-end servers.

However, do not do this rashly. If you only had a single front-end server until then, it is important to verify that the architecture of your website is ready to accommodate other fronts. The potential implications are to be discussed beforehand with your agency, but the main one you should focus on is the user sessions (cookies). The question to ask yourself is whether a user session, in your configuration, is stored as a file in a directory on the front-end server, or if it is stored in a shareable system such as the database, or a cache server like Redis? The session must be shared and accessible by each of the front-end servers so that the user’s navigation (Login, Adding a cart) is not disturbed.

Imagine if your customer puts an article in his cart, then is redirected to a server that can no longer find his session and his product. There is a good chance that he will slam the door of your website.

But even with this key step to be watchful of, adding front-end servers remains the easiest way to increase the capacity of your site for the first days of sales.

Last but not least. Try to install your front-end servers 2 to 3 days before the sales period, so as to be sure of:

• The good working of your sales funnel, on each of your servers (Yes, I already said that, and I’ll keep saying it.)
  To installation of your monitoring probes on these new servers, in order to have a complete mapping of the health of your architecture for the D-Day.

Run load tests

In order to be sure that you will be able to welcome more visitors than usual on your website, I advise you to simulate a peak of traffic higher than the one you expect on the day of the sales.

Yes, yes, and yes! Get some leeway! It would surely be extremely frustrating if your emailing campaigns worked too well, but if you ended up with a crashed website, thus torpedoing your turnover. By the bye! It reminds me of the story of an e-commerce director on the first day of sales… 😛

To perform load tests, many solutions exist, grouped in 2 categories:

• House tests performed by your teams, with generally free and time consuming tools as siege, wget, curl, ab, etc.
• “Pro” tests performed by independent third parties such as CloudNetCare, Neotys or QUANTA.

Whichever solution is chosen in the end, during these tests it is important to:

• Simulate what a customer would do on your website, by basing the scenario of your load tests on the behavior of your average customer, monitored in your Google Analytics history.
• Do your calculations so as to easily see what the limit is (before your website crash, ndlr). Unintelligible example of load test results: “We can handle 13 422 HTTP requests per minutes with 60% of CPU” “… Ok. Buuuut… Is that good or bad?” Intelligible example of load test results: “My website in “Sales mode” handles, without disturbances, 5 times the traffic recorded during our previous sales period, and this with virtual customers going through the whole sales funnel.” “Ok, then I am relaxed for the D-day.”

If you want to know more about important things you should keep in mind before you get started; we already wrote a comprehensive guide on the implementation of load tests.

Good sales to you!

L’article QUANTA’s 5 tips for successful sales! est apparu en premier sur Quanta.

The entire Quanta team has worked hard to offer you brand new features. So it was high time to talk about it. 😉 So here we go for the overview of the new alerting system, and of the latest profiler, the one for OroCommerce.

THE NEW ALERTING SYSTEM

As some of you may have already noticed in the app, we’re undertaking a major project to profoundly improve the QUANTA alerting system, making it ever more customizable and intuitive.

The first phase of this work has just ended and mainly concerned the “configuration of alerting” part, to make this crucial tool more fun to use.

So we built a new page specially dedicated to the subject, soberly called “Alerting”.

This tab of the app now allows you to:

• Configure your alerts with a simplified subscription form,
• Manage your (very) many alerts more easily,
• As well as register your teammates for alerts when you are in “administrator mode”.

New “Alerting” tab in QUANTA

Of course, all these actions are also possible for the Daily & Weekly Digests.

All this work of personalization on the alerting dashboard was accompanied by a complete overhaul of the system, to make it more scalable, which will allow us in the future to implement new functionalities more easily.

This work did not, of course, happen at random. This redesign was necessary to prepare for the “Phase 2”, which promises some surprises. We are indeed working on some new features that should be released in the weeks to come:

• Configuring custom thresholds alerts,
• And the possibility of now being warned when a web scenario exceeds a certain threshold of loading time (against an alert only in case of scenario error, currently).

We hope that these new features will please you, and please, do not hesitate to send us your remarks. 😉

THE ONE AND ONLY PROFILER FOR OROCOMMERCE

For those who follow the technological advances in the field of e-commerce, you surely have already heard about OroCommerce, the new CMS published by Oro, and destined to BtoB companies.

And for those who are also following the Quanta news, you must have heard that we released the very first OroCommerce profiler, designed to monitor the performance of this brand new platform.

Like our already well proven Magento 1 and Magento 2 profilers, our users now have a profiler that offers the same level of analysis for OroCommerce websites.

Analysis of the general performance of an OroCommerce website in the QUANTA app

This new profiler allows you to have an extra level of detail of analysis on all the e-commerce websites running on OroCommerce. It allows you to precisely identify the code blocks that have the greatest impact on OroCommerce’s web performance, and to track live the evolution of the application’s execution time.

Detailed analysis of the different loading times of an OroCommerce website in the QUANTA app

Detailed analysis of the blocks of an OroCommerce website in the QUANTA app

This new profiler is currently in beta. To use it, simply send an email to the support team, and we will gladly give you access to it. 🙂

So that’s it for this What’s Up Quanta # 11!

See you soon for other news about the new features for the QUANTA app, and do not hesitate to contact us for specific requests. We are always eager to hear good ideas to improve the app, and to always offer you more web performance!

L’article What’s Up Quanta #11 – A new alerting system and the famous OroCommerce profiler est apparu en premier sur Quanta.

For those of you that weren’t there for last year’s blog post on web performance, titled “What is the Best E-Commerce Platform for Web Performance?“, let me catch you up on the purpose of this little study of ours.

Why is web performance a big issue for e-commerce companies?

Well it’s a simple calculation, really. 😉

“Time is money”, as the saying goes. So for an ever growing economy like the e-commerce business, that amounted to $1,915 billion of worldwide revenue in 2016 (and who will keep increasing by up to 20% each year, in the near future), time truly is of the essence.

And in the e-commerce world, who is the worst enemy of speed (and thus revenue)? Bad web performance.

So you can imagine how most companies, aware of the importance of e-commerce and heavily invested in the field, would want to get the better out of their CMS platform, and achieve a high level of performance and user experience. Simply because if your e-store is slow, customer won’t come / stay / buy, and you’ll have lost a lot of money in customer acquisition / marketing / development / …etc.

Why choosing the right CMS platform is such an important decision for web performance?

Using a CMS to build an online store is a sound tactical choice. It allows you to focus on:

• sales, instead of on the technical aspects of running an online store,
• SEO and marketing actions,
• or even on the finer points of you internet catalogue.

However, using a CMS instead of a custom-made platform for an e-shop is not without consequences:

• By default, it often implements many functionalities that might not be useful, which can make the overall system quite heavy and slow at first.
• It can be more or less prone to bugs, slowdowns or even downtimes; depending on how the CMS is built and customized after installation.

So when it comes down to it, to your speed and conversion rate, choosing the right CMS platform for your e-store is crucial.

And that is why, for the second year in a row, we decided to conduct a study on the performance of 7 leading, well-known, or brand new, e-commerce platforms that seem to be all the rage in 2017. 😉

The idea is to establish a ranking, and find out which one of the platforms delivers the most stable and fastest experience during the classic e-commerce sales funnel.

So without further ado, here is our 2017 competitors pick for the Best E-commerce Platform competition:

• WooCommerce,
• Shopify,
• Magento (we combined the results for Magento EE and CE, but we’ll be sure to do a more thorough blog post on their respective performances later on),
• Prestashop,
• BigCommerce,
• Drupal Commerce,
• and Salesforce Commerce Cloud (former Demandware).

You’ll notice on the chart below, representing the worldwide proportion of websites for each of our chosen CMS, that some in our selection have quite small communities. But we do believe that these CMS present high hopes for the future of e-commerce, in terms of technology, so we’ve decided to test them nonetheless.

METHODOLOGY FOR THIS STUDY

How did we select the websites for the study?

Like for our 2016 CMS platforms study, the study was carried out on a panel of 120 websites (20 per technology), with an Alexa ranking between 200 000 and 600 000. The medium values revolve around rank 430.000, which represents websites with approximately 67.000 visitors/month.

Choosing such a range gives more representativity to the study, since these websites are more likely to meet minimum UX and performance agreed-upon standards.

How did we analyze the performance?

The data was collected using our monitoring tool, Quanta: it reproduces the behavior of a visitor going through the classic sales funnel (Home > Category > Subcategory > Product > Cart), and analyzes the speed and availability of each page from the Home Page to the Cart.

Selected sites are analyzed every minute, 24/7, during 14 days. The tool goes through the main five pages of the website (pages following the sales funnel, ndlr), every minute. And does this for every website selected for the study. This represents a total of 600 clicks per minute, and a total amount of 12 millions HTTP requests for the whole study.

The numbers featured throughout the study are the median values for each page of a regular sales funnel, out of the 20 websites selected per CMS. That is to say that for a better reading comfort, we displayed the median results for all websites, per CMS.

For each technology, we created a summary in the form of an illustration, displaying availability rates and page load times, for each step of an ordinary sales funnel.

Disclaimer. You may notice that the further you go into the sales funnel, the more results are likely to decrease. That’s perfectly normal since the results are added up to each step that follows.

Now, let’s cut the chit-chat and dive right in! 😉

STUDY

WooCommerce

WooCommerce is the leading e-commerce platform on the market. Free and easy to use, it works as an extension of WordPress, and thus:

• does not require an external hoster,
• uses the same plugins as the ones for WordPress (ex: for SEO, it’s Yoast SEO),
• has many themes and plugins available to upgrade the stores,
• and is very scalable, making it a good solution both for big and small companies.

But even with all these technical advantages, it’s too early to declare WooCommerce as the ideal solution for performance. That was the case in 2016, and it remains so today.

The performance test shows that WooCommerce is still overly average in terms of availability and average response time (ART).

The average page load time for all monitored stores is 0,63 seconds (s), which is OK, but not great considering that the immediacy threshold, the holy grail of web performance hailed by Google itself, is 100 milliseconds. Plus, out of the 20 tested websites, we noticed a big a gap in the ARTs; proving that WooCommerce is not a reliable platform in its “out of the box”configuration. For example, a cart once loaded in 4,14 s!

However, it’s true that the results are way better than last year’s. The Home Page and the Cart remain big performance bottlenecks, but we’ve seen a 20% increase in speed for these two steps.

For the availability, WooCommerce comes in 3rd in our competition. With its 99,87% availability rate on average (0,35% more than last year), the solution is stable, even if it still represents a 13 minutes downtime every week on average.

In conclusion, despite its great technical advantages and its increased availability and average response time, WooCommerce as it is often set up, can’t be considered a reference in matters of performance. Of course, in some measure, you can overcome its slowness by:

• using a hoster specialized in WordPress and WooCommerce websites,
• using additional modules like WP Rocket,
• compressing big and heavy images,
• or caching the maximum number of elements in your code.

Shopify

The Canadian solution Shopify is very easy to use if you want to launch an e-commerce platform. It was created in 2006, in order to build a complete website in ten minutes, tops.

Shopify is an all-in one e-commerce platform, which doesn’t require any knowledge in development to set up. You simply have to create your catalogue with the articles, texts and images you need for the store. The structure of the website and themes are already provided when subscribing to the solution.

Shopify is not only simple, but also very performant. Again! The data extracted from our study revealed that on average, web pages loaded in 0,35 s, when the Google Guidelines recommend an average of 0,50 s for loading times! Thanks to its fast response times and results, Shopify delivers a very good overall user experience.

But contrary to last year, Shopify can’t be considered the most stable solution. It actually comes in 6th, with its 99,83% Sales Funnel availability (99,95% last year), on average. Of course, this could be explained by the increase in worldwide availability incidents but still, it’s a little bit disappointing for our 2016 Performance Champion. It represents a 17 minutes downtime each week.

Such performances can be explained by the fact that Shopify is a full-Saas platform; meaning that it manages both the CMS and its hosting. This specificity is definitively an advantage pertaining to loading times and availability, but the drawback is that when Shopify’s servers are down or suffer a slowdown, all the websites hosted are affected in the same way. If you want to know more about this subject, I actually wrote a blog post on the impact of the 2016 Dyn DNS attacks on Shopify websites. You can find it here.

Magento

Created in 2008, Magento is an open-source e-commerce solution, with a big and active community, providing advanced user assistance and many dedicated extensions. It is currently the leading e-commerce platform in Europe, with more than 230 000 websites using their technology.

However, to this day, it remains quite difficult to master, due to its architecture and all its functionalities. Skilled developers are often needed to undertake modifications.

During our study, we discovered that, in 2016, Magento has been a rather stable platform since the availability rate reached 99.89%, on average, which is better than 2015’s 99,71%. The availability rate for the Subcategory, Product and Cart steps are way more satisfactory. So it comes in 3rd position in terms of general availability.

Although Magento websites are the most frequented (with an average of 3000 visitors per day), they are not the fastest! The results showed that the pages, composing a classic user’s sales funnel, loaded in 0,60 s on average, which is beyond the “under 500 milliseconds” goal set by Google. And even if the Product’s average response time has been cut by half since last year, it remains far from the racing cars that are the likes of Shopify.

Nonetheless, Magento’s Cart load time is reasonable with a result of 0,58 s; which is fast enough to retain clients until the end of the sales funnel.

In conclusion, we can safely say that Magento is a complex machine, making it slower than the average other solutions.

To improve its performance, try using Varnish, or the built-in Full Page Cache functionality, developed by Magento itself. Those two popular cache systems can really boost you store and help it near the sweet spot of 100 milliseconds, the immediacy threshold.

PrestaShop

Since its public release in 2007 PrestaShop has been a very popular CMS in France. The solution is used by 250,000 websites across the globe, and has a huge community (1 million community members!).

PrestaShop is free to download and install, and provides native basic functionalities. However, in order to have a fully functional website, it is necessary to download themes and extensions in the PrestaShop market, which are hardly ever free…

The analysis of PrestaShop websites’ performance showed average results. The average speed for every page is 0,65 s, with the Cart being the fastest page at 0,56 s. It presents significantly better results compared to last year’s, particularly for the Category and Subcategory pages.

However, PrestaShop still presented a very good (even if a little bit diminished) availability rate of 99,90%, garnering it the 2nd place in our competition for Best Availability.

Those results could possibly be improved using many optimization and caching tools the solution provides, as well as choosing hosting services fitted for PrestaShop, using a CDN and reverse proxy solutions.

BigCommerce

BigCommerce is our second full-SaaS solution. A CMS that we chose to include in this 2017 edition of our study, because of its growing reputation and use by e-commerce companies. Created in 2009 by Eddie Machaalani and Mitchell Harper, following a chance meeting in an online chatroom in 2003, it is tailored for fast-growing, mid-market, companies.

Unlike a Magento or a Drupal Commerce, BigCommerce offers few customization options. There are four different levels of pricing – Standard, Plus, Pro and Enterprise -, that each offer specific features and services. So if you’re looking for a close-to-custom-made platform, BigCommerce is not made for you.

But even if it wears proudly its “Full-SaaS feel” when it comes to customization, BigCommerce is a great choice when it comes to overall web performance.

As you can see on the illustration below, most of the indicators for the Sales Funnel steps, for both availability and ART, are in the green. With its average response time of 0,50 s, BigCommerce is a fast platform. This response time places it in the third position of our competition for Best Average Response Time, and matches exactly the recommendation of Google when it comes to speed.

As is customary for many full-SaaS CMS, it is also quite stable. With an average availability rate of 99,87%, BigCommerce seems to be a valid option for e-commerce websites.

Drupal Commerce

We monitored a panel of Drupal Commerce stores. Created in 2011, Drupal Commerce is an extension of Drupal, adding to the original CMS all the e-commerce features needed by online companies. It is free and open-source.

One of Drupal Commerce’s particularity, is to be really well-fitted for SEO, which allows websites to climb the rankings in Google search engine.

Drupal Commerce was a rather good solution when it came to performance. In fact, the medium for the pages load time is 0,56 s, which represents the fourth best performance out of all the technologies tested, very close to SaaS solutions like Shopify and BigCommerce!

With 99.86% availability rate, Drupal Commerce represents the sixth most available technology among the tested CMS. But even if it seems poor, Drupal Commerce remains a reliable technology to use for an e-commerce store.

However, creating and updating a Drupal Commerce based website is not as simple as using Shopify or PrestaShop. It requires a dedicated team of developers, and thus, to invest some time and money into the setup.

Salesforce Commerce Cloud (former Demandware)

And last but not least, here comes Commerce Cloud. It is a cloud-based e-commerce platform created in 2004 by Stephan Schambach, and purchased in 2016 by Salesforce to reinforce its e-commerce services.

Commerce Cloud was conceived as a full SaaS platform with a touch of predictive technology, that aims at managing all the aspects of an e-business: hosting, marketing, and customer services. As you can see in the “CMS Proportion 2017” chart in the beginning of this study, Commerce Cloud is not a widely used CMS at the moment. But we chose to include it in our study because we do believe that the Salesforce buy will give this CMS nw possibilities of expansion.

That being said, let’s take a look at the results of our web performance test.

If you’ve been with us since the beginning of this study, the results in the graph below should not really be a surprise to you. As a Shopify or a BigCommerce, Commerce Cloud presents overall excellent results when it comes to availability and average response time.

See? Green almost everywhere! Commerce Cloud presents the best overall results in both availability rate and average response time.

The medium average response time is a tiny 0,35 s, with a really fast Cart that peaks at 0,23 s. Yup. That’s closing fast on the immediacy threshold, and are pretty impressive results.

But Commerce Cloud is not only fast, it is also really stable. With its 99,96% availability rate (which represents only 5 minutes of downtime each week), it’s the number 1 reliable CMS platform for this year’s study.

AND THIS YEAR BEST WEB PERFORMANT PLATEFORM IS…

Before unveiling the name of this year Web Performance champion, we thought it was a good idea to look more precisely at the availability rate and average response time results.

As we’ve said before, every e-company is different, and its unique features call for a tailored choice of CMS. Even if web performance as a whole must remain the key factor in choosing a CMS, some businesses will want to focus on availability, or on average response time.

So, here you go. Here are the results for the Best Availability Rate, and Best Average Response Time rankings.

As expected, the full Saas platforms perform well, especially when it comes to the average response times (advantage only possible because they host the websites themselves, instead of employing an external hosting service and communicating with it). And we can also conclude that it is not the most used platforms that presents the most impressive results. Moreover, if you compare these results to last year’s ranking, it cements the idea that CMS platforms, like all technology, evolve throughout the time, and that yesterday’s good results do not necessarily mean tomorrow’s success.

But these rankings are just partial answers to our founding question of “Who is the best web performant CMS platform for 2017?”. So without further ado, here is the definitive podium.

Drum roll please!

We’re pleased to announce that, after taking into account all the datas provided and analyzed, the most web performant e-commerce platform is Salesforce Commerce Cloud.

The study revealed Commerce Cloud websites tends to be faster and more stable than other CMS-based websites. And more broadly, that seems to be the case for the other Saas CMS, like Shopify and BigCommerce.

BigCommerce is also a fast and reliable full Saas solution, garnering it the second place on our podium.

And last, but not least, on the 3rd step of our podium, we find Magento, that represents a safe and good option in terms of web performance. Even if it is not the fastest, or the most available, its medium scores in these two areas makes it a well balanced platform.

Of course, if your site runs under Prestashop, or WooCommerce, there is no reason to be alarmed! The results of all these platforms are very close, and the differences between the different rankings on the podium are often minimal. But we do believe that a little healthy competition can nudge the publishers of these solutions to better take into account the issue of web performance. 😉

Moreover, we observed during the study that significant differences could exist in the performance of sites running on the same technology. It’s just that some sites are better tuned than others. This only reinforces my belief (and the message I tried to get through to you!) that a CMS will never be perfect “out of the box”, and that optimizations to cater to the specific needs of an e-commerce website are absolutely necessary.

LAST WORDS

And this conclude this year Best Web Performant CMS Platform competition!

But here is a little sneak peek at our 2018 edition.

QUANTA’s Head of Operations, Matthieu Rosinski, tested the performance and scalability of Oro‘s new cutting-edge platform, OroCommerce, and the results were very promising! So we can’t wait for next year to come, and hope that we’ll have the opportunity to test the web performance of these  websites. 😉

Remember that the most important conclusion to be drawn is that the technology used for a website is not the only key factor to get good performances.

Relying only on a CMS native availability or speed will certainly lead to poor performance, and numerous issues. So, to get the best performances possible, it is crucial to rely on a professional team of developers, who will be able to maximize website optimization, and improve page load time speed. And this, even for full Saas CMS platform that, even if performant in their out-of-the-box configurations, need fine tuning to push further the boundaries of web performance.

L’article What is the Best E-Commerce Platform for Web Performance? – 2017 Edition est apparu en premier sur Quanta.

Why monitor an e-commerce website?

For those of you that, like us, are passionate about web performance and e-commerce, you should have seen lately that everybody is talking about the users’ cry for instantness.

E-customers don’t want to wait. If they can’t buy online in a timely manner, and on a website which offer great UX, they will simply leave.

You’ll thus have lost both a chance to sell, and a chance to establish your reputation. And we all know how much money it cost to attract new customer, instead of simply retaining your current ones…

That being said, if you want to reduce your loading times, increase your conversion, retain your customer, AND offer a great UX, then web performance should be your number 1 priority.

And to optimise your web performance, you need to carefully monitor your website. And not just the back-end (which means everything that is invisible to your users : server, response time, network, …etc.)! You need to keep an eye on your front-end (which means everything that is visible to your users : images, pages, links, tags, …etc.) also, to have a complete pictures of where your e-commerce platform could be optimised.

How does our front-end monitoring feature works?

Until recently, Quanta’s main focus was to offer precise, clear and constant back-end monitoring. It means that thanks to our app’s profilers and dashboards, you were able to monitor your back-end and keep track of any incident or slowdown that your server, network, databases, …etc. experienced.

With the front-end monitoring feature, you have the opportunity to analyse more thoroughly the web performance of each page of your e-commerce funnel.

Quanta’s probes now analyse the loading times of the front-end elements (images, CSS, JS, external tags, …etc.) on each of your pages.

Our waterfall view

Our waterfall view allows you to track down each resource loaded. As such, you know what happened, for how long, and when! Also, to help you identify the most important issues, we provide you with Google Pagespeed recommendations.

Waterfall of the category page

In other words, you can now discover which of your super heavy kitten image, or which JS line written by your freshly arrived intern, is jeopardizing your web performance and thus your revenue, AND take action right away to correct it.

Pretty neat, ha?

Results?

Some of our clients already tried it, and had mind-boggling results. Seriously.

The first place actually goes to Madura, who reduced its frontend page loading times by 20%, in just one week!

But we’ll soon do a Case Study on this subject, so stay tuned to read about the real life applications of this new feature.

L’article What’s Up Quanta #10 – Our Front-End monitoring is there! est apparu en premier sur Quanta.