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.

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.

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.

What is OroCommerce, you ask?

OroCommerce is Oro Inc.‘s new disruptive platform, specifically designed for BtoB ecommerce websites.

This CMS easily integrates with applications, CRMs, PIM tools, or any other useful ecommerce software. It’s a complete platform that offers native CMS tools, managing solutions, and configurations to make life easier for mid to large-sized companies.

Moreover, it is a solution that relies heavily on the power of open-source technology, and community contributions, for its betterment.

What does this partnership represent for Quanta?

First, we believe that OroCommerce and QUANTA are like-minded companies. We admire the level of expert thinking, technological progress, and BtoB orientation that OroCommerce embodies. So much so that we initiated the creation of OroWiki, a blog for OroCommerce’s enthusiasts and experts.

Considering this, we believe that the emerchants that come to OroCommerce for its cutting-edge technology, could be interested in managing and optimizing their web performance with QUANTA.

Thus, this partnership is an incredible opportunity, both in terms of technology and reach, simply because it has a true potential of emulation.

As Romain Lamaison, our CEO says : “It’s not about innovation, it’s about revolution.”. And working with OroCommerce is an opportunity, not only to push further the boundaries of disruptive technology, but also to shape tomorrow’s ecommerce world.

L’article Quanta partners with OroCommerce! 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.