Author: Clément DERON

Engineer for 6 years, he started as an automation QA on Android before switching to iOS. Having worked on multiple technologies over the course of his career, mobile automation holds no secrets for him.

Why is it crucial to monitor the environmental impact of a URL?

Posted on by Clément DERON
Reading Time: 4 minutes

The more frequently a URL is viewed, the more essential it is to reduce its digital impact. A simple measurement makes it possible to check and react to changes made on the page: modifications linked to the graphic charter, events (e-commerce sites during sales periods) or even technical modifications. All of these changes can have a big impact on the sobriety level of a web page.

When to integrate the digital sobriety measurement of a URL?

These measurements can be integrated as part of daily monitoring on any page. “Dynamic” pages whose content changes regularly, such as e-commerce home pages or press information sites, are crucial to monitor. Even less “dynamic” pages can also be targeted: updating a CDN library can, for example, impact this type of site. In this case, the measurement will make it possible to ensure that the new skin of the page does not harm the level of sobriety of the website: an image too heavy for a banner can be easily spotted.

Measurement can also be used during the development phase. To test choices before going into production or to correct excessively impactful changes very early. It is often difficult to change the choice of a technology or an implementation once a site goes into production. Measuring a URL during the development phase allows you to test different options early on and see which one corresponds best by taking into account digital sobriety as one of the criteria.

Example of daily monitoring of a web page

How to measure the digital sobriety of a URL?

There are several options available to you at Greenspector to measure a URL.

A first tool allows us to perform a simple first measurement of a URL and obtain rapid observations: the Benchmark tool based on standardized tests.

To go further, we can measure a complete user journey on a website using App Scan. This kind of measurement represents the full path on a website or mobile application, such as a purchase journey or the completion of a bank transfer. It helps identify areas to focus on to achieve significant improvement. As part of an App Scan, the measurement of a URL is also possible via an automated route which will allow obtaining specific metrics beyond the benchmark.

URL measurement vs Benchmark

Here are the different steps measured during a URL measurement vs with the Benchmark tool:

Measured steps

  • Loading without cache
  • Pause after launching without cache
  • Pause on the web without cache
  • Scroll on the web
  • Pause on the web after scroll
  • Loading with cache
  • Pause on the web with cache
  • Background app metering

Benchmark

URL Measurement

The URL metric contains more steps than the benchmark we will come back to that. Unlike the benchmark, the URL measurement is more precise on the loadings. The measured duration being the actual loading time, unlike the benchmark tool which performs the measurements over a fixed period of 20 seconds. Another difference is that the URL measurement manages the tabs present on the page, in particular those concerning cookies, which the benchmark tool does not do.

Enfin, la mesure URL par Greenspector permet de réaliser des mesures sur d’autres navigateurs que GFinally, the URL measurement by Greenspector makes it possible to carry out measurements on browsers other than Google Chrome. The benchmark tool is limited to the latter browser, but our GDSL expertise allows us to offer another browser such as Firefox to go even further.

The steps of a URL measurement

  • Loading without cache: This is the loading of the URL having previously cleared the cache and deleted all cookies. This step measures the loading of the web page when a user goes to it without a cache. It is essential for URLs with a lot of unique visits.
  • Pause after loading without cache: Measuring a short pause after loading allows you to recover data exchanges and other operations that are still taking place when your page is displayed. The ideal, of course, is to have none of that. Otherwise, it allows us to make observations and suggest ways to eliminate or reduce these treatments.
  • Pause on a page without cache: It represents the action of a user reading the content. No movement on the screen. The idea of ​​this step is to measure the impact of the continuous display of the page.
  • Scroll on the page: Scroll to the bottom of the page to make observations on the treatments during the scroll. Here we can make observations on the possible data exchanges (pagination, image download, advertising) as well as the associated fluidity.
  • Pause on the page after scrolling: Measure of pause after scrolling allowing to observe processes that continue after the end of user interactions.
  • Loading with cache: Measurement of the loading of the URL with the cache of previous interactions (loading, scroll). This step allows you to see the impact of caching on the site. This is important for pages that will be visited a large number of times by known visitors, such as a website home page.
  • Pause on the page with cache: The measure of pause on the page allowing to see if despite the cache there are treatments after loading.

Thanks to our tools and our expertise, we can offer reliable and relevant measurements on a URL. Whether it is a simple measurement allowing initial findings using our benchmark tool or a more in-depth measurement with our GDSL language. This regular URL monitoring gradually improves the sobriety level of its website. This approach compared to other approaches commonly used in the web (Analysis only of the loading of the page with Lighthouse or others …), brings more finesse to the knowledge of the consumption of the page.

How to clean up the Chrome app for reliable energy and performance measurements?

Posted on by Clément DERON
Reading Time: 5 minutes

Context

Welcome to this new “GDSL focus” section. We will explain some methods of the Greenspector GDSL automation language. If you have not yet read the GDSL introductory article, do not hesitate before reading this one further.

Today we will focus on the browserReset method. It allows cleaning a browser to perform reliable performance and energy measurements.

To perform correct browser measurements, you need to be able to make sure to measure only your web page, without any parasite that could come from the browser, such as open tabs. Without this, the measurement of the consumption of a web page would be biased by tabs in the background carrying out processing and network exchanges. Moreover, it allows to precisely measure the consumption of the empty browser, once the cleaning has been carried out, and to compare it with the consumption of the site.

When it comes to automation, we cannot stand not knowing the initial conditions of our test. The unknown could disrupt its proper functioning or even lead to a test where nothing can be learned. Because, in the end, we do not know what will be measured.

On an automated test bench, it’s hard to know the state of the browser at the start of your test: you don’t know if a previous test left tabs open, changed the browser language, or anything else. We could take a look in the smartphones room but it becomes complicated if it is on the other side of the world. Not to mention the current health situation (this article was written during the crisis of Covid-19). You could also use the tools to monitor the phone remotely. So yes, but this is only valid if you are present when you run your test. For continuous integration campaigns that can run for hours or even overnight, you aren’t going to be able to monitor them constantly.

So what should be done? Clean the browser efficiently before each test.

Quick approach

In our case, we are going to use the Chrome browser. This method also works the same with another browser. We will also assume that this browser is updated regularly on phones.

A quick method, which will work in many cases to clean up a browser, is to close open tabs and clean the cache at the start of each of our tests. This way, the next time the browser opens during measurements it will be on an empty tab.

This method will work on the majority of smartphones but will be difficult on tablets because of the management of tabs. On tablets, tabs are generally displayed on a bar at the top (or bottom) of the browser, like on a computer. The peculiarity of this tab bar is that it is invisible to classic automation tools, which makes it very difficult to click on the cross to close the tab. In addition, the size of a tab will depend on the number of tabs open, making click by coordinates even more hazardous.

To top it off, the button to close all tabs at once only appears with a long press on the close cross of the first tab, making it unusable for us.

The last difficulty that this method can encounter is its maintenance, in fact by updating the application, the management of the tabs can change, as can the architecture of the application, requiring to modify regularly the automation scripts.

Complete solution

The solution used at Greenspector to clean the browser before our measurements and ensure the relevance of our results is as follows:

  • Clean up application data. This is usually done using the adb shell pm clear PACKAGE_NAME command but can also be done in the phone’s settings menu.
  • Skip browser first launches popups with automation.

Once this is done, there is one last point that can pose a problem. Some manufacturers or mobile operators display a personalized browser home page. To be able to compare measurements between several smartphones, you must get rid of this home page. We have chosen to disable the home page in the browser settings.

There is one last point regarding this home page. Indeed, it was loaded the first time the browser was launched and is therefore open, which is not practical for taking measurements. Our solution was to navigate to Chrome’s “new tab” page at the following URL:

  • « chrome://newtab »

Once all these operations are done, your browser is ready to take measurements without the risk of having existing conditions to disturb it.

It is even ideal to do the cleaning also at the end of your test, that way you leave the phone ready for the next person.

UPDATE: For our measurement needs, we are interested in performance data, energy, and mobile data. This method meets performance and power requirements well but is not suitable for data on the Chrome browser. Indeed, by resetting the browser, Chrome automatically resynchronizes the data of the Google account, and at least the first two minutes of use there are exchanges of data related to the Google account. Signing out of the Google Account on Chrome or the phone doesn’t seem to solve the problem entirely. Therefore at Greenspector we no longer use this method to clean up a browser. No measurements have been taken on browsers other than Chrome to say that this method is not valid on them.

Here you know everything about the browserReset method. See you soon for a new GDSL focus where I will introduce you to another feature of the Greenspector automation language.

Introduction to GDSL: The Automation Language by Greenspector

Posted on by Clément DERON
Reading Time: 3 minutes

What is GDSL ?

The term GDSL stands for Greenspector Domain-Specific Language. It is a language created by Greenspector to simplify test automation on Android and iOS. To put it simply, it is an overlay based on the automation frameworks from Google and Apple, embellished with functions to ease test automation.

This language is the result of the Greenspector expertise accumulated over several years. It combines ease of writing with the ability to measure the energy performance of an application or website.

The GDSL principle is to be a language for describing actions that will be performed on the smartphone. In that sense, it can be closer to Gherkin with whom it shares the quality of not requiring developer training to be read.

The GDSL is a series of actions that will be performed in order on the smartphone. It has the basic actions of WAIT, CLICK or PAUSE as well as more complex actions such as launching an application or managing the GPS. 

With GDSL it is possible to quickly automate most of the critical user journeys of your applications or mobile website. 

GDSL syntax

Here is an example line from GDSL:

waitUntilText,username,10000

The first element, in green (waitUntilText), is the name of the method. Usually, it will be in English and self-explanatory. Here we will wait for a text. The main actions of WAIT and CLICK are available with variations for id, text or content description.

The second element, in orange (username), is going to be the main parameter of the method. This is usually the graphical element on which the action should be taken. Depending on the method called, this will be an id, a text or a description. In the example, this is a text.

The last element, in blue (10000), is a second parameter of the method. These are most often optional parameters giving additional conditions during execution. Here it is a time in milliseconds.

To separate each element we use a comma.

The method presented as an example is therefore used to wait for the element with the text “username” for a maximum of 10 seconds.

In the current state of the language, there are no methods requiring more than two parameters. If the method fails then the test will stop and the report will show the test as failed.

The advantages of GDSL

  • GDSL does not require any development skills or knowledge of programming languages ​​to be used or read. The names of the methods are self-explanatory and allow anyone new to the project to read and understand your tests.
  • No IDE or specific development environment is required to write GDSL, a basic text editor is sufficient.
  • One test = one file. With GDSL no need for complicated file architecture, only one file contains your test.
  • Its ease of use allows you to write a test very quickly without relying on the rest of the test project as other automatic test languages ​​would require.
  • In addition, its ease of execution with the associated tools at Greenspector allows each new test to be implemented very quickly.
  • Updated and maintained regularly, the language already has advanced features for website automation such as tab opening or URL navigation.
  • In direct combination with the tools and expertise of Greenspector, GDSL is the only automation language that allows you to measure the performance and environmental impact of your application while performing your daily tests.

The current limits of GDSL

  • The GDSL does not yet allow us to perform complex logic tests (for example: if I am connected then I see element 1, otherwise I see element 2). You have to write a different test for each case.
  • The GDSL is based on graphic elements present in descriptive form. It is unable to interpret the content of an image or analyze the layout of your application. It cannot do a test verifying that the button is located at the bottom right of the screen.

The Greenspector team works daily to improve the language and add functionalities. The current state automates most of the scenarios required for a complete measurement campaign for an application or website as well as the critical journeys of most applications. In a future article, we will tell you about the Greenspector tools for running GDSL tests.