Just like Google searches done on a desktop, as of July, mobile searches now also consider speed. The Silicon Valley company has indeed expressed that mobile content, even if very relevant, will be bumped down the search engine’s results pages if it takes too long to load.
It is commonly accepted that a page’s loading speed has a strong impact on conversion rates, and as a result, on the overall performance of online sales. With this announcement, Google takes a step further by stating that a mobile site with poor web performance will lose visibility by being less well referenced. The direct result is a reduction in the number of visits to the site. Online sales numbers are directly linked to these two factors, so a site’s profitability hangs in the balance.

In June 2017, 56% of visits to websites in France were made from a mobile device (source DN/Médiamétrie and eStat), so online retailers should not just think “mobile first” but “fast mobile first”, or they risk jeopardizing their sales volumes. The American giant’s decision to demand good user experience will require online retailers to change in step.

With this change, e-merchants must therefore work to improve their mobile web performance. More than 500 online businesses have already followed the steps below to avoid being relegated to the famous search engine’s lower ranks:

1/ Identify Your Key Pages
Google is a major source of traffic for e-commerce sites. Based on what they search and Google’s index, web users won’t  all land on the same page. It is therefore best to first identify the pages upon which users most frequently land, and then focus your efforts on those ones first. The most cost-effective and pragmatic approach is to take note of the most important pages for your business and concentrate on them.

2/ Compare the Speed of Your Key Pages To Those of Your Competitors
By using Google’s automatic test page, you can compare your site to that of your competitors. When the test is complete, you just have to select your industry to see if you are one of the good or bad students.

3/ Optimize
Among the most important recommendations:
– Use a cache system (CDN)
– Enable compression on your server
– Compress and resize images in order to provide the user with content that is always perfectly tailored to their device

The list of optimizations to complete (and to maintain over time!) is long. Google also
provides PageSpeed Insights, a tool you can use to determine if the improvements you implement on your site are making an immediate effect.

4/ Monitor
An e-commerce site is a complex and perpetually moving machine. Every week, your site undergoes several changes that may lead to unexpected slowdowns or disruptions. If these performance problems are not identified and corrected before Google next analyzes your site, they can have serious repercussions on your site’s ranking. Implementing a system of continuous measurement, slowdown identification, and alerting is therefore necessary for your site’s long-term success.

L’article Google Speed Update: When Web Performance Impacts SEO, How Do You Ensure Your Mobile Site is Up to Speed? est apparu en premier sur Quanta.

Here is a little tour of the main Web Performance KPIs that should catch your attention.

Loading time: a basic metric, but a little outdated

Loading time has been the first performance indicator used. It simply represents the overall loading time of a page (until the last pixel is displayed).
It is interesting to follow this indicator but it does not represent the customer experience. The main reason for that is that a page is usually displayed progressively and become interactive before being fully loaded, which makes the user feel like the page was loaded before the total loading time was reached.

Speed ​​Index: a weighted measure of loading time

The Speed ​​Index is a measure of the display time that takes into account the actual user experience. It is expressed in milliseconds. A low score means a fast display and therefore a better user experience. Concretely, the speed Index represents the average display time of all pixels above the bottom of the screen.

Let’s take an example:

Page A is displayed progressively (30% of pixels at 0.5 seconds, 70% at 1 second and 100% at 1.5 seconds) vs page B which is displayed in one time (0 to 100% at 1.5 seconds).

Page A and Page B will have the same loading time (1.5 seconds). However, the user experience will be much better on page A.
In the case of page A, as the page is displayed gradually, it has a double positive effect for the user:

• He has a visual confirmation that the page is loading: it helps him to wait and keeps him focus on the page.
• He can already use some of the page contents: the loading time is no longer “lost”.

The Speed ​​Index calculation will take this difference into account to favor the progressive display. Thus, Speed ​​Index page A will be 1000ms when the one of page B will be 1500ms.

What is a good Speed ​​Index?
It is commonly accepted that after a 1 second wait, customers will lose their train of thought and their purchase intent. After 3 seconds, more than half of them will leave the site out of frustration. Therefore, a good Speed ​​Index should ideally be (and stay!) under 1000ms. Between 1000 in 3000ms, the navigation remains “acceptable” but fragile. And above 3000ms it is absolutely necessary to improve it as the risk of losing visitors if becomes very high.

​​Page Speed Score: a best practice compliance indicator

The ​​Page Speed score is a very different indicator. It does not represent the loading time, but Google’s best practice recommendations.
This score is a global grade out of 100 and made up with the compliance grades of each different best practices.

Thus, Google Page Speed ​​is not an indicator representing the user experience, but rather a tool that will highlight optimization opportunities. It is very complementary to other KPIs as following your PageSpeed score will help you build the optimization roadmap to ultimately improve your Speed Index and User Experience.

As a conclusion, there are many indicators to track the Web Performance of your pages. But in the end, what you need to follow the big picture which is “how is my User Experience?”. To answer this question, the Speed ​​Index is the reference. On the other hand, once you have identified which pages need to be improved, you need to know what to do next to be able to improve, and this is when the ​​Page Speed score makes the most sense.

L’article Loading time, Speed Index, Score Page Speed… which indicator better represents the User Experience? est apparu en premier sur Quanta.

The acquisition of WebPerf.io to meet a growing market demand

Our mission has always been to offer the Digital, Marketing and E-Commerce Departments a global solution for Web Performance Management.
Following a growing demand from the market and our customers, we wanted to integrate a feature of Real User Monitoring to offer an new dimension in the web performance analysis by integrating the navigation data of real users. WebPerf.io, which has become, in the past years, a reference in the identification and analysis of visitor segments, was therefore the ideal solution to integrate. This new acquisition will allow us to respond more quickly and efficiently to market demands.

Real User Monitoring, a complementary feature to offer a 360° Web Performance solution

Until now, we have been following a Web Performance approach by simulating navigation scenarios for defined virtual users. The objective is to follow the evolution of the response times of a purchase scenario for example, without any effects of external factors.
This approach of STM (Synthetic Transaction Monitoring) is typically useful for measuring the impact of a change on web sites. It is precious to settle a process of continuous improvement since the measurements are calibrated and comparable, vs the RUM where each user has its own configuration that impacts the results.

The RUM enables to follow the Web Performance and to measure how each elements impacts on the conversion rates for a specific segment of real users. It is now possible to know, for example, that a new feature creates slowdowns for a strategic mobile user segment. Quanta will then offer a 360° view of the Web Performance of a site by offering Analytics and Alerting Business functionalities, Web Performance management, communication between the different actors of the site and from now on Real User Monitoring (RUM).

Our technical team is working hard to integrate the WebPerf.io solution. A private BETA program should be launched soon. To find out more, do not hesitate to contact us!

L’article Quanta acquires the WebPerf.io RUM technology to offer a 360° solution for Web Performance Management est apparu en premier sur Quanta.

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.

Our analysis focused on business elements (conversion rate, page views, turnover, etc.) and their technical implications, by comparing the activity of 450 sites on the first day of the sales period VS the average metrics recorded the day before the beginning of the sales. Well, it’s safe to say that we had some surprises. ^^

The great upheaval

As early as 8 am, the indicators began to rocket. At the end of the day, the turnover registered an average increase of + 359%!

This end result was the combination of several factors:

More visits

Many visitors meet, that day, on the exact same time slot as early as from 8 am (+ 155% of sessions).

More pages viewed

Visitors click more on this one day, and go further in their sales funnel (+ 182% of additional page views per visit).

Better conversion rate

The prices are more attractive and the Internet users are competing with each other to “seize” the best deals, so the conversion rate is also above normal (+ 38% on average).

That is how the combination of all these factors (more visitors, who go further in the sales tunnel, and thus buy more) has led to this +359% global increase in sales.

Congratulations to all for these results. 😉

But do not think it is simple to get there. These results were made possible thanks to a good management of the load by the platform, kept almost the whole time in operational conditions. One could even go further by talking about optimal conditions, ie the platform held the charge, at the peak of traffic, with page load times as fast as in the off-peak periods.

Small reminder on this point: in the ecommerce world, every 100ms of additional loading time impacts the final conversion rate. That is, if a site is slowed down by 2s per page during the first morning of sales period, you can expect it to register 20% less than predicted!

By analyzing the measures recorded on the hosting infrastructures during that same morning of sales, it’s easy to grasp the magnitude of the difficulty encountered by any emerchant who is preparing for a strong traffic on the day of the sales.

A technical challenge for estores

Because, yes, the very good results that the ecommerce sites recorded during the sales have a significant technical cost for the infrastructures.

Increased demand for infrastructure

Metrics showed this summer a +149% CPU load increase on french ecommerce infrastructures. This increase can be easily explained by the execution of the order processing and the CMS code (whether it is based on Magento, Prestashop, OroCommerce, or even a “home” solution).

What does it tell us ? From this number we can say that in order to keep a little room for mishaps on the infra, and to withstand this sudden increase in the load, it is often necessary for the emerchants to have 4 times more infrastructure on the D-Day, than on the rest of the year. On a so-called “fixed” infrastructure, this amounts to paying a quadruple capacity compared to its average need, and just for… 2 days in the year (the first day of the winter and summer sales) ! You can understand easily why elastic (or cloud) infrastructures have the wind in their sails at the moment.

To correctly anticipate the provisioning of infrastructures before the D-Day, the most recommended option remains the implementation of upstream load tests. On the subject, if you have any questions about how to set up these tests, do not hesitate to read our article dedicated to this matter.

Greater response times during peak traffic

There was a +44% increase in page response time, demonstrating that despite the addition of supplementary infrastructures for the D-Day, some users are still suffering from unoptimized and slower-than-usual software processing, hence the importance of:

• Upstream optimization,
• Load tests (yes. Again!),
• And caches at all levels => varnish, cache block, …etc.

What does a 44% increase in response times represents, you say?

With an average of 600ms of page rendering time (this is the time for our panel of measured websites), a user has a navigation experience of an additional 250ms of loading times with each click, on the morning of sales period.

According to various studies, including that of the star, Amazon, 250ms of additional loading time is equivalent to about 2.5% of turnover loss. For the entire French ecommerce, it is therefore several million euros that can be lost in a single day, if the anticipation on traffic peaks is not properly carried out!

Indeed, there is a combination of a slowed time precisely on a day when the turnover is much higher, the effects of speed on conversion are thus multiplied.

This analysis of the summer 2017 sales shows how closely the commercial success of a website is linked to its technical preparation in many aspects:

• The availability (an unavailable site does not sell anything and deteriorates the image of a brand),
• The speed (each 100ms counts for the conversion rate … and the SEO too),
• And how the infrastructure handles the load in general

In other words, this shows that success and web performance are intimately linked when talking about ecommerce.

See you soon in January 2018 for an upcoming analysis of the next french biggest peak of activity of the year. But by then, do not hesitate to contact us for an expert advice during your preparation.

L’article French Summer Sales 2017 – Health status of the ecommerce websites est apparu en premier sur Quanta.