diff options
| author | Marcel Amirault <mamirault@gitlab.com> | 2019-09-06 11:10:08 +0900 |
|---|---|---|
| committer | Marcel Amirault <mamirault@gitlab.com> | 2019-09-06 11:10:08 +0900 |
| commit | cea2a4829e005d3de6cb80989ac0e9fbe187547e (patch) | |
| tree | 8c2e66db0be0250d3b176b2ee51d3325830c8ea1 | |
| parent | 171736262bb13a2c46dddce59700ea887a5508ff (diff) | |
| download | gitlab-ce-docs-merge-examples-with-features.tar.gz | |
Final cleanup for browser performance docdocs-merge-examples-with-features
| -rw-r--r-- | doc/user/project/merge_requests/browser_performance_testing.md | 49 |
1 files changed, 24 insertions, 25 deletions
diff --git a/doc/user/project/merge_requests/browser_performance_testing.md b/doc/user/project/merge_requests/browser_performance_testing.md index de04c8dab97..5d089af0627 100644 --- a/doc/user/project/merge_requests/browser_performance_testing.md +++ b/doc/user/project/merge_requests/browser_performance_testing.md @@ -24,18 +24,20 @@ for [additional metrics](https://gitlab.com/gitlab-org/gitlab-ee/issues/4370) in a future release. Going a step further, GitLab can show the Performance report right -in the merge request widget area: +in the merge request widget area (see below). ## Use cases For instance, consider the following workflow: -1. A member of the marketing team is attempting to track engagement by adding a new tool -1. With browser performance metrics, they see how their changes are impacting the usability of the page for end users -1. The metrics show that after their changes the performance score of the page has gone down -1. When looking at the detailed report, they see that the new Javascript library was included in `<head>` which affects loading page speed -1. They ask a front end developer to help them, who sets the library to load asynchronously -1. The frontend developer approves the merge request and authorizes its deployment to production +1. A member of the marketing team is attempting to track engagement by adding a new tool. +1. With browser performance metrics, they see how their changes are impacting the usability + of the page for end users. +1. The metrics show that after their changes the performance score of the page has gone down. +1. When looking at the detailed report, they see that the new JavaScript library was + included in `<head>` which affects loading page speed. +1. They ask a front end developer to help them, who sets the library to load asynchronously. +1. The frontend developer approves the merge request and authorizes its deployment to production. ## How it works @@ -47,11 +49,11 @@ example on [Testing Browser Performance](../../../ci/examples/browser_performanc GitLab then checks this report, compares key performance metrics for each page between the source and target branches, and shows the information right on the merge request. ->**Note:** +NOTE: **Note:** If the Performance report doesn't have anything to compare to, no information will be displayed in the merge request area. That is the case when you add the Performance job in your `.gitlab-ci.yml` for the very first time. -Consecutive merge requests will have something to compare to and the Performance +Consecutive merge requests will have something to compare to, and the Performance report will be shown properly.  @@ -59,20 +61,19 @@ report will be shown properly. ## Configuring Browser Performance Testing NOTE: **Note:** -The job definition shown below is supported on GitLab 11.5 and later versions. -It also requires the GitLab Runner 11.5 or later. -For earlier versions, use the [previous job definitions](#previous-job-definitions). +The job definition shown below is supported in GitLab 11.5 and later versions. +It also requires GitLab Runner 11.5 or later. For earlier versions, use the +[previous job definitions](#previous-job-definitions). -This example shows how to run the -[sitespeed.io container](https://hub.docker.com/r/sitespeedio/sitespeed.io/) on -your code by using GitLab CI/CD and [sitespeed.io](https://www.sitespeed.io) +This example shows how to run the [sitespeed.io container](https://hub.docker.com/r/sitespeedio/sitespeed.io/) +on your code by using GitLab CI/CD and [sitespeed.io](https://www.sitespeed.io) using Docker-in-Docker. First, you need GitLab Runner with -[docker-in-docker build](../../../ci/docker/using_docker_build.md#use-docker-in-docker-workflow-with-docker-executor). +[docker-in-docker](../../../ci/docker/using_docker_build.md#use-docker-in-docker-workflow-with-docker-executor). -Once you set up the Runner, add a new job to `.gitlab-ci.yml` that -generates the expected report: +Once you set up the Runner, add a new job to `.gitlab-ci.yml` that generates the +expected report: ```yaml performance: @@ -103,16 +104,14 @@ that you can later download and analyze. Due to implementation limitations we al take the latest Performance artifact available. The full HTML sitespeed.io report will also be saved as an artifact, and if you have -[GitLab Pages](../pages/index.md) enabled, it can be viewed -directly in your browser. +[GitLab Pages](../pages/index.md) enabled, it can be viewed directly in your browser. -For further customization options for sitespeed.io, including the ability to -provide a list of URLs to test, please see the -[Sitespeed.io Configuration](https://www.sitespeed.io/documentation/sitespeed.io/configuration/) documentation. +For further customization options for sitespeed.io, including the ability to provide a +list of URLs to test, please see the [Sitespeed.io Configuration](https://www.sitespeed.io/documentation/sitespeed.io/configuration/) +documentation. TIP: **Tip:** -For [GitLab Premium](https://about.gitlab.com/pricing/) users, key metrics are automatically -extracted and shown right in the merge request widget. +Key metrics are automatically extracted and shown in the merge request widget. ### Performance testing on Review Apps |