Docs 8.0 (#2254)
This commit is contained in:
Peter Hedenskog
GitHub
parent
c39ddecd5e
commit
e9e33bbcb8
|
|
@ -5,14 +5,9 @@ compress_html:
|
|||
clippings: all
|
||||
endings: all
|
||||
include: ["_headers"]
|
||||
highlighter: none
|
||||
kramdown:
|
||||
enable_coderay: false
|
||||
coderay:
|
||||
coderay_wrap: div
|
||||
coderay_line_numbers: inline
|
||||
coderay_line_number_start: 1
|
||||
coderay_tab_width: 4
|
||||
coderay_bold_every: 10
|
||||
coderay_css: style
|
||||
syntax_highlighter_opts:
|
||||
disable : true
|
||||
gems:
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,93 @@
|
|||
{% capture headingsWorkspace %}
|
||||
{% comment %}
|
||||
Version 1.0.2
|
||||
https://github.com/allejo/jekyll-anchor-headings
|
||||
|
||||
"Be the pull request you wish to see in the world." ~Ben Balter
|
||||
|
||||
Usage:
|
||||
{% include anchor_headings.html html=content %}
|
||||
|
||||
Parameters:
|
||||
* html (string) - the HTML of compiled markdown generated by kramdown in Jekyll
|
||||
|
||||
Optional Parameters:
|
||||
* beforeHeading (bool) : false - Set to true if the anchor should be placed _before_ the heading's content
|
||||
* anchorBody (string) : '' - The content that will be placed inside the anchor; the `%heading%` placeholder is available
|
||||
* anchorClass (string) : '' - The class(es) that will be used for each anchor. Separate multiple classes with a space
|
||||
* anchorTitle (string) : '' - The `title` attribute that will be used for anchors
|
||||
* h_min (int) : 1 - The minimum header level to build an anchor for; any header lower than this value will be ignored
|
||||
* h_max (int) : 6 - The maximum header level to build an anchor for; any header greater than this value will be ignored
|
||||
* bodyPrefix (string) : '' - Anything that should be inserted inside of the heading tag _before_ its anchor and content
|
||||
* bodySuffix (string) : '' - Anything that should be inserted inside of the heading tag _after_ its anchor and content
|
||||
|
||||
Output:
|
||||
The original HTML with the addition of anchors inside of all of the h1-h6 headings.
|
||||
{% endcomment %}
|
||||
|
||||
{% assign minHeader = include.h_min | default: 1 %}
|
||||
{% assign maxHeader = include.h_max | default: 6 %}
|
||||
{% assign beforeHeading = include.beforeHeading %}
|
||||
{% assign nodes = include.html | split: '<h' %}
|
||||
|
||||
{% capture edited_headings %}{% endcapture %}
|
||||
|
||||
{% for node in nodes %}
|
||||
{% if node == "" %}
|
||||
{% continue %}
|
||||
{% endif %}
|
||||
|
||||
{% assign headerLevel = node | replace: '"', '' | slice: 0, 1 | times: 1 %}
|
||||
|
||||
<!-- If the node doesn't have a header, then it's content before the first heading; don't discard it -->
|
||||
{% if headerLevel < 1 or headerLevel > 6 %}
|
||||
{% capture edited_headings %}{{ edited_headings }}{{ node }}{% endcapture %}
|
||||
{% continue %}
|
||||
{% endif %}
|
||||
|
||||
{% assign _workspace = node | split: '</h' %}
|
||||
{% assign _idWorkspace = _workspace[0] | split: 'id="' %}
|
||||
{% assign _idWorkspace = _idWorkspace[1] | split: '"' %}
|
||||
{% assign html_id = _idWorkspace[0] %}
|
||||
|
||||
{% capture _hAttrToStrip %}{{ _workspace[0] | split: '>' | first }}>{% endcapture %}
|
||||
{% assign header = _workspace[0] | replace: _hAttrToStrip, '' %}
|
||||
|
||||
<!-- Build the anchor to inject for our heading -->
|
||||
{% capture anchor %}{% endcapture %}
|
||||
|
||||
{% if html_id and headerLevel >= minHeader and headerLevel <= maxHeader %}
|
||||
{% capture anchor %}href="#{{ html_id}}"{% endcapture %}
|
||||
|
||||
{% if include.anchorClass %}
|
||||
{% capture anchor %}{{ anchor }} class="{{ include.anchorClass }}"{% endcapture %}
|
||||
{% endif %}
|
||||
|
||||
{% if include.anchorTitle %}
|
||||
{% capture anchor %}{{ anchor }} title="{{ include.anchorTitle | replace: '%heading%', header }}"{% endcapture %}
|
||||
{% endif %}
|
||||
|
||||
{% capture anchor %}<a {{ anchor }}>{{ include.anchorBody | replace: '%heading%', header | default: '' }}</a>{% endcapture %}
|
||||
|
||||
<!-- In order to prevent adding extra space after a heading, we'll let the 'anchor' value contain it -->
|
||||
{% if beforeHeading %}
|
||||
{% capture anchor %}{{ anchor }} {% endcapture %}
|
||||
{% else %}
|
||||
{% capture anchor %} {{ anchor }}{% endcapture %}
|
||||
{% endif %}
|
||||
{% endif %}
|
||||
|
||||
{% capture new_heading %}
|
||||
<h{{ _hAttrToStrip }}
|
||||
{{ include.bodyPrefix }}
|
||||
{% if beforeHeading %}
|
||||
{{ anchor }}{{ header }}
|
||||
{% else %}
|
||||
{{ header }}{{ anchor }}
|
||||
{% endif %}
|
||||
{{ include.bodySuffix }}
|
||||
</h{{ _workspace | last }}
|
||||
{% endcapture %}
|
||||
{% capture edited_headings %}{{ edited_headings }}{{ new_heading }}{% endcapture %}
|
||||
{% endfor %}
|
||||
{% endcapture %}{% assign headingsWorkspace = '' %}{{ edited_headings | strip }}
|
||||
|
|
@ -126,12 +126,27 @@ a:hover {
|
|||
cursor: pointer;
|
||||
text-decoration: underline;
|
||||
}
|
||||
|
||||
|
||||
|
||||
code {
|
||||
font-size: 16px;
|
||||
background-color: #f5f2f0;
|
||||
}
|
||||
|
||||
pre code {
|
||||
display: block;
|
||||
padding: 6px;
|
||||
}
|
||||
|
||||
/*
|
||||
code {
|
||||
background-color: #eee;
|
||||
padding: 2px;
|
||||
}
|
||||
|
||||
|
||||
#
|
||||
pre code {
|
||||
display: block;
|
||||
padding: 9.5px;
|
||||
|
|
@ -147,6 +162,7 @@ border-radius: 4px;
|
|||
font-family: Monaco,Menlo,Consolas,"Courier New",monospace;
|
||||
white-space: pre-wrap;
|
||||
}
|
||||
*/
|
||||
|
||||
.language-bash code:before {
|
||||
content: '$ ';
|
||||
|
|
@ -323,6 +339,11 @@ blockquote span:before {
|
|||
color: red;
|
||||
}
|
||||
|
||||
.anchor {
|
||||
font-size: 80%;
|
||||
color: grey;
|
||||
}
|
||||
|
||||
.king img:hover {
|
||||
/* Start the shake animation and make the animation last for 0.5 seconds */
|
||||
animation: shake 0.5s;
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
## Browsertime 3.0
|
||||
## Browsertime 4.0
|
||||
* * *
|
||||
[<img src="{{site.baseurl}}/img/browsertime-ff-chrome.png" class="pull-left img-big" alt="Browsertime logo" width="180" height="162">]({{site.baseurl}}/documentation/browsertime)
|
||||
|
||||
We've been working on releasing 3.0 of Browsertime for some time and now it's here! You should use Browsertime if you want a raw JSON result for timings and/or execute your own JavaScript. Browsertime is perfect if you wanna build your own performance tool, as VoxMedia did when they created [Lightbike](https://github.com/voxmedia/lightbike) built on top of Browsertime.
|
||||
Browsertime 4.0 supports testing multiple pages within the same browser session and scriptinmg. You should use Browsertime if you want a raw JSON result for timings and/or execute your own JavaScript. Browsertime is perfect if you wanna build your own performance tool, as VoxMedia did when they created [Lightbike](https://github.com/voxmedia/lightbike) built on top of Browsertime.
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
Use our [Docker container](https://hub.docker.com/r/sitespeedio/sitespeed.io/) to get an environment with Firefox, Chrome, XVFB and sitespeed.io up and running as fast as you can download them. They work [extremely well]({{site.baseurl}}/documentation/sitespeed.io/performance-dashboard/) together with Graphite/InfluxDB and Grafana.
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io/
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io/
|
||||
~~~
|
||||
|
||||
#### npm
|
||||
|
|
|
|||
|
|
@ -43,8 +43,10 @@ layout: compress
|
|||
<link type="application/atom+xml" href="https://www.sitespeed.io/feed/index.xml" rel="alternate" />
|
||||
|
||||
<style>{% include css/default.css %}</style>
|
||||
<link rel="stylesheet" href="{{ "/css/prism-1.15.css" | prepend: site.baseurl }}">
|
||||
<script type="text/javascript">{% include userTimings.js %}</script>
|
||||
{% include analythics.js %}
|
||||
<script src="{{ "/js/clipboard-2.0.4.min.js" | prepend: site.baseurl }}" defer></script>
|
||||
<script src="{{ "/js/prism-1.15.js" | prepend: site.baseurl }}" defer></script>
|
||||
</head>
|
||||
|
||||
<body>
|
||||
|
|
@ -53,7 +55,7 @@ layout: compress
|
|||
<div class="grid">
|
||||
<div class="col-1-1">
|
||||
<main>
|
||||
{{ content }}
|
||||
{% include anchor_headings.html html=content anchorBody='#' anchorClass='anchor' h_max=4 h_min=2 %}
|
||||
</main>
|
||||
</div>
|
||||
<section>
|
||||
|
|
|
|||
|
|
@ -45,6 +45,9 @@ layout: compress
|
|||
<style>
|
||||
{% include css/default.css %}
|
||||
</style>
|
||||
<link rel="stylesheet" href="{{ "/css/prism-1.15.css" | prepend: site.baseurl }}">
|
||||
<script src="{{ "/js/clipboard-2.0.4.min.js" | prepend: site.baseurl }}" defer></script>
|
||||
<script src="{{ "/js/prism-1.15.js" | prepend: site.baseurl }}" defer></script>
|
||||
</head>
|
||||
|
||||
<body>
|
||||
|
|
|
|||
|
|
@ -0,0 +1,249 @@
|
|||
---
|
||||
layout: default
|
||||
title: Sitespeed.io 8.0 and Browsertime 4.0
|
||||
description: Today we released new sitespeed.io and browsertime with support for testing multiple pages within the same browser session.
|
||||
authorimage: /img/aboutus/peter.jpg
|
||||
intro: Finally it is here, the most wanted feature by users ... test multiple pages within the same browser session, scripting the page and choosing yourself when to run your tests.
|
||||
keywords: sitespeed.io, browsertime, webperf
|
||||
nav: blog
|
||||
---
|
||||
|
||||
# Sitespeed.io 8.0 and Browsertime 4.0
|
||||
|
||||
There are so many new and great thing in this release and we will focus on a couple of new things in this blog post. You can read about the rest of the changes in the [changelog](https://github.com/sitespeedio/browsertime/blob/master/CHANGELOG.md) for Browsertime and the [changelog](https://github.com/sitespeedio/sitespeed.io/blob/master/CHANGELOG.md) for sitespeed.io.
|
||||
|
||||
Lets talk about:
|
||||
- [Testing multiple pages within a browser session](#testing-multiple-pages-within-a-browser-session)
|
||||
- [Testing a single page application](#testing-a-single-page-application)
|
||||
- [New privacy advice in Coach 3.0](#new-privacy-advice-in-coach-30)
|
||||
- [New and improved dashboards](#new-and-improved-dashboards)
|
||||
- [New budget configuration](#new-budget-configuration)
|
||||
- [Upgrading Browsertime](#upgrading-browsertime)
|
||||
- [Upgrading sitespeed.io](#upgrading-sitespeedio)
|
||||
- [What you can do](#what-you-can-do)
|
||||
|
||||
## Testing multiple pages within a browser session
|
||||
<img src="{{site.baseurl}}/img/user-journey.png" class="pull-right img-big" alt="The user journey" width="250">
|
||||
|
||||
In versions prior 8.0 you could test one page with the browser cache cleared, you could use a ```--preURL``` to pre warm the browser cache or a script, but you could only test one page at a time. With the new version you can pass on multiple URLs and choose to access them one by one within the same browser session without clearing the cache.
|
||||
|
||||
Lets say tou want to test the following user journey: A user first visits the start page [https://www.sitespeed.io](https://www.sitespeed.io) then[https://www.sitespeed.io/documentation/ ](https://www.sitespeed.io/documentation/) and last goes to the [https://www.sitespeed.io/documentation/sitespeed.io](https://www.sitespeed.io/documentation/sitespeed.io/) page.
|
||||
|
||||
You can do that now by just adding the ```--multi``` parameter:
|
||||
|
||||
~~~bash
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} --multi https://www.sitespeed.io https://www.sitespeed.io/documentation/ https://www.sitespeed.io/documentation/sitespeed.io/
|
||||
~~~
|
||||
|
||||
If you leave out ```--multi``` each and every URL will be tested by starting a new browser session with the cached cleared between each URL.
|
||||
|
||||
With the new scripting capabilities you can do the same with a script:
|
||||
|
||||
~~~javascript
|
||||
module.exports = async function(context, commands) {
|
||||
await commands.measure.start('https://www.sitespeed.io');
|
||||
await commands.measure.start('https://www.sitespeed.io/documentation/');
|
||||
return commands.measure.start('https://www.sitespeed.io/documentation/sitespeed.io/');
|
||||
};
|
||||
~~~
|
||||
|
||||
And run it with
|
||||
~~~bash
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} --multi script.js
|
||||
~~~
|
||||
|
||||
The new scripting capabilities adds a couple of commands to make scripting easier ([see the documentation](../documentation/sitespeed.io/scripting/)). And you can still also use raw Selenium if you prefer that.
|
||||
|
||||
Let us look at a little more complicated example. We want to measure the actual login page at Wikipedia and then measure the Barack Obama page as a logged in user.
|
||||
|
||||
|
||||
~~~javascript
|
||||
module.exports = async function(context, commands) {
|
||||
// We start by navigating to the login page.
|
||||
await commands.navigate(
|
||||
'https://en.wikipedia.org/w/index.php?title=Special:UserLogin&returnto=Main+Page'
|
||||
);
|
||||
|
||||
// When we fill in a input field/click on a link we wanna
|
||||
// try/catch that if the HTML on the page changes in the feature
|
||||
// sitespeed.io will automatically log the error in a user friendly
|
||||
// way, and the error will be re-thrown so you can act on it.
|
||||
try {
|
||||
// Add text into an input field, finding the field by id
|
||||
await commands.addText.byId('login', 'wpName1');
|
||||
await commands.addText.byId('password', 'wpPassword1');
|
||||
|
||||
// Start the measurement before we click on the
|
||||
// submit button. Sitespeed.io will start the video recording
|
||||
// and prepare everything.
|
||||
await commands.measure.start('login');
|
||||
// Find the sumbit button and click it and then wait
|
||||
// for the pageCompleteCheck to finish
|
||||
await commands.click.byIdAndWait('wpLoginAttempt');
|
||||
// Stop and collect the measurement before the next page we want to measure
|
||||
await commands.measure.stop();
|
||||
// Measure the Barack Obama page as a logged in user
|
||||
return commands.measure.start(
|
||||
'https://en.wikipedia.org/wiki/Barack_Obama'
|
||||
);
|
||||
} catch (e) {
|
||||
// We try/catch so we will catch if the the input fields can't be found
|
||||
// The error is automatically logged in Browsertime and re-thrown here
|
||||
}
|
||||
};
|
||||
~~~
|
||||
|
||||
You can check out [more examples](../documentation/sitespeed.io/scripting/#examples) in the documentation.
|
||||
|
||||
## Testing a single page application
|
||||
|
||||
Yeah, you can now test a SPA! When you test a single page application you should add the ```--spa``` parameter so that Browsertime/sitespeed.io knows. That will enable:
|
||||
* Automatically handle URLs with #.
|
||||
* End testing your page load after X seconds of no activity in the Resource Timing API. This makes sure that when you navigate to different pages, the navigation ends when everything finished loading.
|
||||
|
||||
Here's an example where we navigate and measure the start page of our Grafana installation, and then measure clicking the link to see the data for the last thirty days.
|
||||
|
||||
Lets create a script file and call it *thirtydays.js*.
|
||||
|
||||
~~~javascript
|
||||
module.exports = async function(context, commands) {
|
||||
await commands.measure.start('https://dashboard.sitespeed.io/d/000000044/page-timing-metrics?orgId=1');
|
||||
try {
|
||||
await commands.click.byClassName('gf-timepicker-nav-btn');
|
||||
await commands.wait.byTime(1000);
|
||||
// We give the paghe an alias that will be used if the metrics is sent to Graphite/InfluxDB
|
||||
await commands.measure.start('pageTimingMetricsLast30Days');
|
||||
await commands.click.byLinkTextAndWait('Last 30 days');
|
||||
await commands.measure.stop();
|
||||
} catch (e) {
|
||||
// If the GUI change and a link is not there,
|
||||
// the click commands will throw an error.
|
||||
// sitespeed.io will catch, log and rethrow
|
||||
// and you can choose if you want to have a different
|
||||
// user flow
|
||||
}
|
||||
};
|
||||
~~~
|
||||
|
||||
And then you run it by passing on the script file, using ```--spa``` to notify that you are testing a single page application and ```--multi``` that you test multiple pages withing one run.
|
||||
|
||||
~~~bash
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} thirtydays.js --spa --multi
|
||||
~~~
|
||||
|
||||
Read the full [documentation](../documentation/sitespeed.io/spa/) for testing your single page application.
|
||||
|
||||
## New privacy advice in Coach 3.0
|
||||
Privacy is [important to us]({{site.baseurl}}/privacy-policy/) and we have had users complaining about the advice not to use Google Analytics: *"Our customer wants a Best Practice score 100 and they cannot get that since they use GA ...."*.
|
||||
|
||||
Well ... by using Google Analytics your customer is revealing information about a your user's behavior to Google. That's not ok. But maybe the **Best Practice** category wasn't the best place for that advice. That's why we created the **Privacy** category with the following advice:
|
||||
|
||||
* Always use [HTTPS](https://https.cio.gov/everything/).
|
||||
* Do not mix HTTPS with HTTP, since every unencrypted HTTP request reveals information about your user’s behavior.
|
||||
* Use a [Referrer Policy header](https://scotthelme.co.uk/a-new-security-header-referrer-policy/) that allows your site to control how much information the browser includes with navigations away from your page.
|
||||
* Use the [HTTP Strict-Transport-Security response header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security) to let the web site tell browsers that it should only be accessed using HTTPS, instead of using HTTP.
|
||||
* Avoid including Facebook/Google/AMP/Youtube on your page since you [give away users privacy to large companies](https://2018.ar.al/notes/we-didnt-lose-control-it-was-stolen/).
|
||||
* Avoid using third party requests since it reveals information about your user's behavior.
|
||||
|
||||
|
||||
The new privacy category is super useful for everyone and specific all our users in the public sector: Please make sure that you do not leak your user's behavior.
|
||||
|
||||
## New and improved dashboards
|
||||
|
||||
We have updated our dashboards to include new metrics like Privacy score from the Coach and added more default graphs to make it easier to find regression. The [timing metrics dashboard](https://dashboard.sitespeed.io/d/000000044/page-timing-metrics?orgId=1) now includes "Compares to last week" graphs, inspired by [Timo Tijhof](https://twitter.com/timotijhof) work at Wikimedia.
|
||||
|
||||
|
||||
{: .img-thumbnail}
|
||||
|
||||
You can get the [updated dashboards from Github](https://github.com/sitespeedio/grafana-bootstrap-docker/tree/master/dashboards/graphite) and check them out at [dashboard.sitespeed.io](https://dashboard.sitespeed.io/d/000000044/page-timing-metrics?orgId=1).
|
||||
|
||||
## New budget configuration
|
||||
One problem before 8.0 was that it was really hard to configure a performance budget: You needed to use the internal data structure and that sucks. Looking at other tools we could see that configuring a budget is usually hard. That's why we are introducing a new way in 8.0 (if you where using the old configuration pre 8.0, don't worry, that will continue to work).
|
||||
|
||||
You can configure default values and specific for a URL. In the budget file there are 5 couple of sections:
|
||||
|
||||
* timings - are Visual and technical metrics and are configured in milliseconds (ms)
|
||||
* requests - the max number of requests per type or total
|
||||
* transferSize - the max transfer size (over the wire) per type or total
|
||||
* thirdPatrty - max number of requests or trasnferSize for third parties
|
||||
* score - minimum score for Coach advice
|
||||
|
||||
|
||||
The simplest version of a budget file that will check for SpeedIndex higher than 1000 ms looks like this:
|
||||
|
||||
~~~json
|
||||
{
|
||||
"budget": {
|
||||
"timings": {
|
||||
"SpeedIndex":1000
|
||||
}
|
||||
}
|
||||
}
|
||||
~~~
|
||||
|
||||
All URLs that you test then needs to have a SpeedIndex faster than 1000. But if you have one URL that you know are slower? You can override budget per URL.
|
||||
|
||||
~~~json
|
||||
{
|
||||
"budget": {
|
||||
"https://www.sitespeed.io/documentation/": {
|
||||
"timings": {
|
||||
"SpeedIndex": 3000
|
||||
}
|
||||
},
|
||||
"timings": {
|
||||
"SpeedIndex":1000
|
||||
}
|
||||
}
|
||||
}
|
||||
~~~
|
||||
|
||||
[Read the documentation](/documentation/sitespeed.io/performance-budget/) on how to setup your budget file.
|
||||
|
||||
## Upgrading Browsertime
|
||||
There are a couple of breaking changes introduce in 4.0. This only matters if you run Browsertime as a standalone tool (without using sitespeed.io).
|
||||
|
||||
1. New structure of the result JSON. In 4.0 we introduce the ability to test multiple pages. That means that instead of returning one result object, we return an array. In 3.x the result looks like this:
|
||||
~~~json
|
||||
{
|
||||
"info": {
|
||||
"browsertime": {
|
||||
"version": "3.0.0"
|
||||
}, ...
|
||||
~~~
|
||||
And the new one returns a array, where each tested page is an result in that array.
|
||||
~~~json
|
||||
[{
|
||||
"info": {
|
||||
"browsertime": {
|
||||
"version": "4.0.0"
|
||||
}, ...
|
||||
}}]
|
||||
~~~
|
||||
2. New naming of result files. Before files was named by iteration: 1-video.mp4. In the latest version all extra files are stored in a folder structure and referenced in the JSON, starting with /pages/ (following the same pattern as sitespeed.io).
|
||||
3. New layout of Selenium scripting. We simplified the layout of the script. The new version will be able to do the exact same thing as older versions but with a simpler layout:
|
||||
|
||||
~~~javascript
|
||||
module.exports = async function(context, commands) {
|
||||
// code
|
||||
}
|
||||
~~~
|
||||
|
||||
Pre/post scripts also follows the new script format.
|
||||
|
||||
## Upgrading sitespeed.io
|
||||
|
||||
Upgrading should be pretty straight forward and work out of the box. If you used pre/post scripts, you need to upgrade them to the new signature:
|
||||
|
||||
~~~javascript
|
||||
module.exports = async function(context, commands) {
|
||||
// code
|
||||
}
|
||||
~~~
|
||||
|
||||
And read the [new documentation about scripting](/documentation/sitespeed.io/scripting/).
|
||||
|
||||
## What you can do.
|
||||
Sitespeed.io 8.0 and Browsertime 4.0 is a major major change. We need your help to try it out and please create [issues](https://github.com/sitespeedio/sitespeed.io/issues/new) when you find something that seems wrong.
|
||||
|
||||
/Peter
|
||||
|
|
@ -19,8 +19,4 @@ nav: blog
|
|||
|
||||
[>> Read more]({{site.baseurl}}{{ post.url }})
|
||||
|
||||
|
||||
|
||||
* * *
|
||||
|
||||
{% endfor %}
|
||||
{% endfor %}
|
||||
|
|
@ -0,0 +1,200 @@
|
|||
/* PrismJS 1.15.0
|
||||
https://prismjs.com/download.html#themes=prism&languages=clike+javascript+bash+docker+json&plugins=toolbar+copy-to-clipboard */
|
||||
/**
|
||||
* prism.js default theme for JavaScript, CSS and HTML
|
||||
* Based on dabblet (http://dabblet.com)
|
||||
* @author Lea Verou
|
||||
*/
|
||||
|
||||
code[class*="language-"],
|
||||
pre[class*="language-"] {
|
||||
color: black;
|
||||
background: none;
|
||||
text-shadow: 0 1px white;
|
||||
font-family: Consolas, Monaco, 'Andale Mono', 'Ubuntu Mono', monospace;
|
||||
text-align: left;
|
||||
white-space: pre;
|
||||
word-spacing: normal;
|
||||
word-break: normal;
|
||||
word-wrap: normal;
|
||||
line-height: 1.5;
|
||||
|
||||
-moz-tab-size: 4;
|
||||
-o-tab-size: 4;
|
||||
tab-size: 4;
|
||||
|
||||
-webkit-hyphens: none;
|
||||
-moz-hyphens: none;
|
||||
-ms-hyphens: none;
|
||||
hyphens: none;
|
||||
}
|
||||
|
||||
pre[class*="language-"]::-moz-selection, pre[class*="language-"] ::-moz-selection,
|
||||
code[class*="language-"]::-moz-selection, code[class*="language-"] ::-moz-selection {
|
||||
text-shadow: none;
|
||||
background: #b3d4fc;
|
||||
}
|
||||
|
||||
pre[class*="language-"]::selection, pre[class*="language-"] ::selection,
|
||||
code[class*="language-"]::selection, code[class*="language-"] ::selection {
|
||||
text-shadow: none;
|
||||
background: #b3d4fc;
|
||||
}
|
||||
|
||||
@media print {
|
||||
code[class*="language-"],
|
||||
pre[class*="language-"] {
|
||||
text-shadow: none;
|
||||
}
|
||||
}
|
||||
|
||||
/* Code blocks */
|
||||
pre[class*="language-"] {
|
||||
padding: 1em;
|
||||
margin: .5em 0;
|
||||
overflow: auto;
|
||||
}
|
||||
|
||||
:not(pre) > code[class*="language-"],
|
||||
pre[class*="language-"] {
|
||||
background: #f5f2f0;
|
||||
}
|
||||
|
||||
/* Inline code */
|
||||
:not(pre) > code[class*="language-"] {
|
||||
padding: .1em;
|
||||
border-radius: .3em;
|
||||
white-space: normal;
|
||||
}
|
||||
|
||||
.token.comment,
|
||||
.token.prolog,
|
||||
.token.doctype,
|
||||
.token.cdata {
|
||||
color: slategray;
|
||||
}
|
||||
|
||||
.token.punctuation {
|
||||
color: #999;
|
||||
}
|
||||
|
||||
.namespace {
|
||||
opacity: .7;
|
||||
}
|
||||
|
||||
.token.property,
|
||||
.token.tag,
|
||||
.token.boolean,
|
||||
.token.number,
|
||||
.token.constant,
|
||||
.token.symbol,
|
||||
.token.deleted {
|
||||
color: #905;
|
||||
}
|
||||
|
||||
.token.selector,
|
||||
.token.attr-name,
|
||||
.token.string,
|
||||
.token.char,
|
||||
.token.builtin,
|
||||
.token.inserted {
|
||||
color: #690;
|
||||
}
|
||||
|
||||
.token.operator,
|
||||
.token.entity,
|
||||
.token.url,
|
||||
.language-css .token.string,
|
||||
.style .token.string {
|
||||
color: #9a6e3a;
|
||||
background: hsla(0, 0%, 100%, .5);
|
||||
}
|
||||
|
||||
.token.atrule,
|
||||
.token.attr-value,
|
||||
.token.keyword {
|
||||
color: #07a;
|
||||
}
|
||||
|
||||
.token.function,
|
||||
.token.class-name {
|
||||
color: #DD4A68;
|
||||
}
|
||||
|
||||
.token.regex,
|
||||
.token.important,
|
||||
.token.variable {
|
||||
color: #e90;
|
||||
}
|
||||
|
||||
.token.important,
|
||||
.token.bold {
|
||||
font-weight: bold;
|
||||
}
|
||||
.token.italic {
|
||||
font-style: italic;
|
||||
}
|
||||
|
||||
.token.entity {
|
||||
cursor: help;
|
||||
}
|
||||
|
||||
div.code-toolbar {
|
||||
position: relative;
|
||||
}
|
||||
|
||||
div.code-toolbar > .toolbar {
|
||||
position: absolute;
|
||||
top: .3em;
|
||||
right: .2em;
|
||||
transition: opacity 0.3s ease-in-out;
|
||||
opacity: 0;
|
||||
}
|
||||
|
||||
div.code-toolbar:hover > .toolbar {
|
||||
opacity: 1;
|
||||
}
|
||||
|
||||
div.code-toolbar > .toolbar .toolbar-item {
|
||||
display: inline-block;
|
||||
}
|
||||
|
||||
div.code-toolbar > .toolbar a {
|
||||
cursor: pointer;
|
||||
}
|
||||
|
||||
div.code-toolbar > .toolbar button {
|
||||
background: none;
|
||||
border: 0;
|
||||
color: inherit;
|
||||
font: inherit;
|
||||
line-height: normal;
|
||||
overflow: visible;
|
||||
padding: 0;
|
||||
-webkit-user-select: none; /* for button */
|
||||
-moz-user-select: none;
|
||||
-ms-user-select: none;
|
||||
}
|
||||
|
||||
div.code-toolbar > .toolbar a,
|
||||
div.code-toolbar > .toolbar button,
|
||||
div.code-toolbar > .toolbar span {
|
||||
color: #bbb;
|
||||
font-size: .8em;
|
||||
padding: 0 .5em;
|
||||
background: #f5f2f0;
|
||||
background: rgba(224, 224, 224, 0.2);
|
||||
box-shadow: 0 2px 0 0 rgba(0,0,0,0.2);
|
||||
border-radius: .5em;
|
||||
}
|
||||
|
||||
div.code-toolbar > .toolbar a:hover,
|
||||
div.code-toolbar > .toolbar a:focus,
|
||||
div.code-toolbar > .toolbar button:hover,
|
||||
div.code-toolbar > .toolbar button:focus,
|
||||
div.code-toolbar > .toolbar span:hover,
|
||||
div.code-toolbar > .toolbar span:focus {
|
||||
color: inherit;
|
||||
text-decoration: none;
|
||||
}
|
||||
|
||||
|
|
@ -20,8 +20,8 @@ twitterdescription: Configuration for Browsertime.
|
|||
Browsertime is highly configurable, let's check it out!
|
||||
|
||||
## The options
|
||||
You have the following options when running sitespeed.io within docker (run <code>docker run sitespeedio/browsertime --help</code> to get the list on your command line):
|
||||
You have the following options when running Browsertime within docker (run <code>docker run sitespeedio/browsertime --help</code> to get the list on your command line):
|
||||
|
||||
~~~help
|
||||
~~~shell
|
||||
{% include_relative config.md %}
|
||||
~~~
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ twitterdescription:
|
|||
Use our Docker image (with Chrome, Firefox, XVFB and the dependencies needed to record a video):
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/browsertime-results sitespeedio/browsertime:{% include version/browsertime.txt %} --video --visualMetrics https://www.sitespeed.io/
|
||||
docker run --rm -v "$(pwd)":/browsertime-results sitespeedio/browsertime:{% include version/browsertime.txt %} --video --visualMetrics https://www.sitespeed.io/
|
||||
~~~
|
||||
|
||||
Or using NodeJS:
|
||||
|
|
@ -52,7 +52,7 @@ docker build -t sitespeedio/browsertime .
|
|||
And then just run it:
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/browsertime-results sitespeedio/browsertime -n 1 --video --visualMetrics https://www.sitespeed.io/
|
||||
docker run --rm -v "$(pwd)":/browsertime-results sitespeedio/browsertime -n 1 --video --visualMetrics https://www.sitespeed.io/
|
||||
~~~
|
||||
|
||||
## Connectivity
|
||||
|
|
@ -70,5 +70,5 @@ The current version doesn't support Docker so you need to [install the requireme
|
|||
If you want to set connectivity you need to use something like [Pi Network Conditioner](https://github.com/phuedx/pinc).
|
||||
|
||||
~~~bash
|
||||
browsertime --browsertime.chrome.android.package com.android.chrome https://www.sitespeed.io --video --visualMetrics
|
||||
browsertime --android https://www.sitespeed.io --video --visualMetrics
|
||||
~~~
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ docker run --shm-size=1g --rm -v "$(pwd)":/browsertime-results sitespeedio/brows
|
|||
|
||||
Then we pickup the median SpeedIndex from Browsertime and send it to your Graphite instance.
|
||||
|
||||
~~~
|
||||
~~~shell
|
||||
echo "browsertime.your.key.SpeedIndex.median" $(cat tmp/browsertime.json | jq .statistics.visualMetrics.SpeedIndex.median) "`date +%s`" | nc -q0 my.graphite.com 2003
|
||||
~~~
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png
|
|||
twitterdescription: Documentation for Browsertime.
|
||||
---
|
||||
|
||||
# Documentation v3
|
||||
# Documentation v4
|
||||
|
||||
<img src="{{site.baseurl}}/img/logos/browsertime.png" class="pull-right img-big" alt="Browsertime logo" width="200" height="175">
|
||||
|
||||
|
|
|
|||
|
|
@ -17,21 +17,21 @@ twitterdescription: Install browsertime using npm, yarn or Docker.
|
|||
{:toc}
|
||||
|
||||
# Install
|
||||
You can run Browsertime using our Docker container or using NodeJS.
|
||||
You can run Browsertime using our Docker container or using NodeJS. If you use Docker everything "just works" and you don't need to install anything extra for getting video and visual metrics to work.
|
||||
|
||||
## Docker
|
||||
|
||||
We have [Docker images](https://hub.docker.com/r/sitespeedio/browsertime/) with Browsertime, Chrome, Firefox and Xvfb. It is super easy to use (Xvfb is started automatically when you start the container). Here's how to use the container with both Firefox & Chrome (install [Docker](https://docs.docker.com/engine/installation/) first).
|
||||
We have [Docker images](https://hub.docker.com/r/sitespeedio/browsertime/) with Browsertime, Chrome, Firefox and Xvfb. It is super easy to use (Xvfb is started automatically when you start the container). Here's how to use the container with both Firefox & Chrome (install [Docker](https://docs.docker.com/install/) first).
|
||||
|
||||
### Mac & Linux
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/browsertime sitespeedio/browsertime:{% include version/browsertime.txt %} --video --visualMetrics https://www.sitespeed.io/
|
||||
docker run --rm -v "$(pwd)":/browsertime sitespeedio/browsertime:{% include version/browsertime.txt %} --video --visualMetrics https://www.sitespeed.io/
|
||||
~~~
|
||||
|
||||
### Windows
|
||||
|
||||
~~~
|
||||
~~~shell
|
||||
C:\Users\Vicky> docker pull sitespeedio/browsertime
|
||||
C:\Users\Vicky> docker run --rm -v "$(pwd)":/browsertime sitespeedio/browsertime:{% include version/browsertime.txt %} https://www.sitespeed.io -b firefox
|
||||
~~~
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ Chrome-HAR is for tool makers: Get the log from the Chrome Debugging Protocol an
|
|||
|
||||
Convert your messages to a HAR file.
|
||||
|
||||
~~~
|
||||
~~~javascript
|
||||
const parser = require('chrome-har');
|
||||
|
||||
// you already have the message from Chrome Debugging Protocol
|
||||
|
|
|
|||
|
|
@ -32,29 +32,29 @@ We love HAR files but it's hard to actually see how the page is composed only lo
|
|||
## Install
|
||||
|
||||
```bash
|
||||
$ npm install pagexray -g
|
||||
npm install pagexray -g
|
||||
```
|
||||
|
||||
## Run
|
||||
|
||||
```bash
|
||||
$ pagexray /path/to/my.har
|
||||
pagexray /path/to/my.har
|
||||
```
|
||||
|
||||
Or if you want to prettify the HAR
|
||||
|
||||
```bash
|
||||
$ pagexray --pretty /path/to/my.har
|
||||
pagexray --pretty /path/to/my.har
|
||||
```
|
||||
And if you want to get info per request/response:
|
||||
|
||||
```bash
|
||||
$ pagexray --includeAssets /path/to/my.har
|
||||
pagexray --includeAssets /path/to/my.har
|
||||
```
|
||||
|
||||
If you want to use it in node, use it like this:
|
||||
|
||||
```node
|
||||
```javascript
|
||||
const pagexray = require('pagexray');
|
||||
const har = // your HAR
|
||||
const pages = pagexray.convert(har);
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: default
|
||||
title: F.A.Q. and best practice using sitespeed.io
|
||||
description: Here we keep questions that gets asked on our Slack channel or frequently on Github.
|
||||
description: Here ewe keep questions that gets asked on our Slack channel or frequently on Github.
|
||||
keywords: best practice, faq
|
||||
nav: documentation
|
||||
category: sitespeed.io
|
||||
|
|
@ -38,7 +38,7 @@ Since 7.2.0 the best way to add a cookie is by using <code>--cookie name=value</
|
|||
If you want to test multiple URLs, you can used line them up in the cli:
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io https://www.sitespeed.io/documentation/
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io https://www.sitespeed.io/documentation/
|
||||
~~~
|
||||
|
||||
You can also use a plain text file with one URL on each line. Create a file called urls.txt (but you can call it whatever you want):
|
||||
|
|
@ -68,10 +68,10 @@ How many runs depends on your site, and what you want to collect. Pat told us ab
|
|||
|
||||
Getting timing metrics is one thing, but it’s also important to collect how your page is built. You need to keep track of the size of pages, how many synchronously loaded javascript you have and so on. For that kind of information you only need one run per URL.
|
||||
|
||||
You should also try out our new setup with WebPageReplay.
|
||||
You should also try out our new setup with [WebPageReplay](../webpagereplay/).
|
||||
|
||||
### I want to test a user journey (multiple pages) how do I do that?
|
||||
We currently don't support that but feel free to do a PR in Browsertime.
|
||||
Checkout the [scripting capabilities](../scripting/) that makes it easy to test multiple pages.
|
||||
|
||||
### I want to test on different CPUs how do I do that?
|
||||
We currently don't built in support for changing the CPU. What we do know is that you should not use the built in support in Chrome or try to simulate slow CPUs by running on slow AWS instance. What should do is what WPTAgent do. You can check the code at [https://github.com/WPO-Foundation/wptagent/blob/master/wptagent.py](https://github.com/WPO-Foundation/wptagent/blob/master/wptagent.py) and do the same before you start a run and then remove it after the run.
|
||||
|
|
@ -86,7 +86,7 @@ That means if you test *https://www.sitespeed.io* with 5 runs/iterations, the br
|
|||
|
||||
When you run <code>--preURL</code> the browser starts, then access the preURL and then the URL you want to test within the same session and not clearing the cache. Use this if you want to measure more realistic metrics if your user first hit your start page and then another page (with responses in the cache if the URL has the correct cache headers).
|
||||
|
||||
If you use the <code>--preScript</code> feature, it is the same behavior, we don't clear the cache between preScript and the URL you want to test.
|
||||
If you use the <code>--preScript</code> or <code>--multi</code> feature, it is the same behavior, we don't clear the cache between the URL you want to test.
|
||||
|
||||
### My pre/post script doesn't work?
|
||||
We use Selenium pre/post script navigation. You can [read more](/documentation/sitespeed.io/prepostscript/) about of our pre/post script setup and focus on the [debug section](/documentation/sitespeed.io/prepostscript/#debuglog-from-your-script) if you have any problem.
|
||||
|
|
@ -129,7 +129,6 @@ You can also use the <code>--urlAlias</code> if you want to give the page a frie
|
|||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} --useHash --urlAlias super --urlAlias duper https://www.sitespeed.io/#/super https://www.sitespeed.io/#/duper
|
||||
~~~
|
||||
|
||||
|
||||
## Servers
|
||||
What you should know before you choose where to run sitespeed.io.
|
||||
|
||||
|
|
|
|||
|
|
@ -91,7 +91,7 @@ When you add your command line switched you should skip the minus. For example:
|
|||
You can get the trace log from Chrome by adding ```--chrome.timeline```. Doing that you will see how much time the CPU spend in different categories and a trace log file that you can drag and drop into your devtools timeline.
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} --chrome.timeline https://www.sitespeed.io/
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} --chrome.timeline https://www.sitespeed.io/
|
||||
~~~
|
||||
|
||||
You can also choose which Chrome trace categories you want to collect by adding ```--chrome.traceCategories``` to your parameters.
|
||||
|
|
@ -108,15 +108,17 @@ You can choose which version of Chrome you want to run by using the ```--chrome.
|
|||
Our Docker container only contains one version of Chrome and [let us know](https://github.com/sitespeedio/sitespeed.io/issues/new) if you need help to add more versions.
|
||||
|
||||
## Choose when to end your test
|
||||
By default the browser will collect data until [window.performance.timing.loadEventEnd happens + aprox 2 seconds more](https://github.com/sitespeedio/browsertime/blob/d68261e554470f7b9df28797502f5edac3ace2e3/lib/core/seleniumRunner.js#L15). That is perfectly fine for most sites, but if you do Ajax loading and you mark them with user timings, you probably want to include them in your test. Do that by changing the script that will end the test (--browsertime.pageCompleteCheck). When the scripts returns true the browser will close or if the timeout time is reached.
|
||||
By default the browser will collect data until [window.performance.timing.loadEventEnd happens + aprox 5 seconds more](https://github.com/sitespeedio/browsertime/blob/d68261e554470f7b9df28797502f5edac3ace2e3/lib/core/seleniumRunner.js#L15). That is perfectly fine for most sites, but if you do Ajax loading and you mark them with user timings, you probably want to include them in your test. Do that by changing the script that will end the test (```--browsertime.pageCompleteCheck```). When the scripts returns true the browser will close or if the timeout time is reached.
|
||||
|
||||
In this example we wait 10 seconds until the loadEventEnd happens, but you can also choose to trigger it at a specific event.
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io --browsertime.pageCompleteCheck 'return (function() {try { return (Date.now() - window.performance.timing.loadEventEnd) > 10000;} catch(e) {} return true;})()'
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io --browsertime.pageCompleteCheck 'return (function() {try { return (Date.now() - window.performance.timing.loadEventEnd) > 10000;} catch(e) {} return true;})()'
|
||||
~~~
|
||||
|
||||
Yoy can also choose to end the test after 5 seconds of inactivity that happens after loadEventEnd. Do that by adding
|
||||
You can also configure how long time your current check will wait until completing with ```--pageCompleteWaitTime```. By default the pageCompleteCheck waits for 5000 ms after the onLoad event to happen. If you want to increase that to 10 seconds use ```--pageCompleteWaitTime 10000```. This is also useful if you test with *pageCompleteCheckInactivity* and it takes long time for the server to respond, you can use the *pageCompleteWaitTime* to wait longer than the default value.
|
||||
|
||||
You can also choose to end the test after 5 seconds of inactivity that happens after loadEventEnd. Do that by adding
|
||||
```--browsertime.pageCompleteCheckInactivity``` to your run. The test will then wait for loadEventEnd to happen and no requests in the Resource Timing API the last 5 seconds. Be-aware though that the script will empty the resource timing API data for every check so if you have your own script collecting data using the Resource Timing API it will fail.
|
||||
|
||||
If you add your own complete check you can also choose when your check is run. By default we wait until onLoad happens (by using pageLoadStrategy normal). If you want control direct after the navigation, you can get that by adding ```--pageLoadStrategy none``` to your run.
|
||||
|
|
@ -129,7 +131,7 @@ Each javascript file need to return a metric/value which will be picked up and r
|
|||
|
||||
For example say we have one file called scripts.js that checks how many scripts tags exist on a page. The script would look like this:
|
||||
|
||||
~~~
|
||||
~~~javascript
|
||||
(function() {
|
||||
return document.getElementsByTagName("script").length;
|
||||
})();
|
||||
|
|
@ -138,7 +140,7 @@ For example say we have one file called scripts.js that checks how many scripts
|
|||
Then to pick up the script, you would run it like this:
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io --browsertime.script scripts.js -b firefox
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io --browsertime.script scripts.js -b firefox
|
||||
~~~
|
||||
|
||||
You will get a custom script section in the Browsertime tab.
|
||||
|
|
@ -156,7 +158,7 @@ Bonus: All custom scripts values will be sent to Graphite, no extra configuratio
|
|||
Visual metrics (Speed Index, Perceptual Speed Index, First and Last Visual Complete, and 85-95-99% Visual Complete) can be collected if you also record a video of the screen. If you use our Docker container you automagically get all what you need. Video and Visual Metrics is turned on by default.
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io/
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io/
|
||||
~~~
|
||||
|
||||
On Android you need to follow [these instructions]({{site.baseurl}}/documentation/sitespeed.io/mobile-phones/#video-and-speedindex).
|
||||
|
|
|
|||
|
|
@ -35,15 +35,16 @@ You can analyse a site either by crawling or by feeding sitespeed.io with a list
|
|||
The simplest way to run sitespeed.io is to give it a URL:
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io
|
||||
~~~
|
||||
|
||||
If you want to test multiple URLs, just feed them:
|
||||
If you want to test multiple URLs, then just add them. Each page will be tested with a new browser session, browser cache cleared between each URL.
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io https://www.sitespeed.io/documentation/
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io https://www.sitespeed.io/documentation/
|
||||
~~~
|
||||
|
||||
|
||||
You can also use a plain text file with one URL on each line. Create a file called urls.txt:
|
||||
|
||||
~~~
|
||||
|
|
@ -66,38 +67,46 @@ Aliases are great in combination with sending metrics to a TSDB (such as Graphit
|
|||
And run it:
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} urls.txt
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} urls.txt
|
||||
~~~
|
||||
|
||||
You can also add alias directly from the command line. Make yore that you pass on the same amount of alias and URLs.
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} --urlAlias doc https://www.sitespeed.io/documumentation/
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} --urlAlias doc https://www.sitespeed.io/documumentation/
|
||||
~~~
|
||||
|
||||
Pass on multiple --urlAlias for multiple alias/URLs.
|
||||
|
||||
If you want to test multiple URLs in a sequence (where the browser cache is not cleared) use --multi:
|
||||
|
||||
~~~bash
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} --multi https://www.sitespeed.io https://www.sitespeed.io/documentation/
|
||||
~~~
|
||||
|
||||
If you wanna do more complicated things like log in the user, add items to a cart etc, checkout [scripting](../scripting/).
|
||||
|
||||
|
||||
### Analyse by crawling
|
||||
|
||||
If you want to find pages that are not so performant it's a good idea to crawl. Sitespeed.io will start with the URL and fetch all links on that page and continue to dig deeper into the site structure. You can choose how deep to crawl (1=only one page, 2=include links from first page, etc.):
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io -d 2
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io -d 2
|
||||
~~~
|
||||
|
||||
### How many runs per URL?
|
||||
When collecting timing metrics, it's good to test the URL more than one time (default is three times). You can configure how many runs like this (five runs):
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io -n 5
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io -n 5
|
||||
~~~
|
||||
|
||||
### Choose browser
|
||||
Choose which browser to use (default is Chrome):
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io -b firefox
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io -b firefox
|
||||
~~~
|
||||
|
||||
### Connectivity
|
||||
|
|
@ -111,13 +120,13 @@ You can set the viewport & user agent, so you can fake testing a site as a mobil
|
|||
The simplest way is to just add <code>--mobile</code> as a parameter. The viewport will be set to 360x640 and the user agent will be Iphone6. If you use Chrome it will use the preset Apple iPhone 6 device.
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io --mobile
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io --mobile
|
||||
~~~
|
||||
|
||||
You can also set a specific viewport and user agent:
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io --browsertime.viewPort 400x400 --browsertime.userAgent "UCWEB/2.0 (MIDP-2.0; U; Adr 4.4.4; en-US; XT1022) U2/1.0.0 UCBrowser/10.6.0.706 U2/1.0.0 Mobile"
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io --browsertime.viewPort 400x400 --browsertime.userAgent "UCWEB/2.0 (MIDP-2.0; U; Adr 4.4.4; en-US; XT1022) U2/1.0.0 UCBrowser/10.6.0.706 U2/1.0.0 Mobile"
|
||||
~~~
|
||||
|
||||
Mobile testing is always best on actual mobile devices. You can [test on Android phones](../mobile-phones/) using sitespeed.io.
|
||||
|
|
@ -129,12 +138,12 @@ In 4.1 we released support for recording a video of the browser screen and use t
|
|||
In 6.0 video and Visual Metrics is turned on by default, and if you want to turn them off you do like this:
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} --visualMetrics false https://www.sitespeed.io/
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} --visualMetrics false https://www.sitespeed.io/
|
||||
~~~
|
||||
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} --visualMetrics false --video false https://www.sitespeed.io/
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} --visualMetrics false --video false https://www.sitespeed.io/
|
||||
~~~
|
||||
|
||||
|
||||
|
|
@ -142,14 +151,14 @@ docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io
|
|||
You can categorise requests as first or third parties by adding a regexp. You will then get the size & requests by type both in HTML and sent to Graphite.
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} --firstParty ".ryanair.com" https://www.ryanair.com/us/en/
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} --firstParty ".ryanair.com" https://www.ryanair.com/us/en/
|
||||
~~~
|
||||
|
||||
### Output folder or where to store the result
|
||||
You can change where you want the data to be stored by setting the <code>--outputFolder</code> parameter. That is good in scenarios where you want to change the default behaviour and put the output in a specific location:
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} --outputFolder /my/folder ".ryanair.com" https://www.sitespeed.io/
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} --outputFolder /my/folder ".ryanair.com" https://www.sitespeed.io/
|
||||
~~~
|
||||
|
||||
### Configuration as JSON
|
||||
|
|
@ -158,7 +167,7 @@ You can keep all your configuration in a JSON file and then pass it on to sitesp
|
|||
|
||||
Create a config file and call it config.json:
|
||||
|
||||
~~~
|
||||
~~~json
|
||||
{
|
||||
"browsertime": {
|
||||
"iterations": 5,
|
||||
|
|
@ -178,13 +187,13 @@ Create a config file and call it config.json:
|
|||
Then, run it like this:
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} --config config.json https://www.sitespeed.io
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} --config config.json https://www.sitespeed.io
|
||||
~~~
|
||||
|
||||
If you want to override and run the same configuration but using Firefox, you just override with the CLI parameter:
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} --config config.json -b firefox https://www.sitespeed.io
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} --config config.json -b firefox https://www.sitespeed.io
|
||||
~~~
|
||||
|
||||
The CLI will always override the JSON config.
|
||||
|
|
@ -195,17 +204,17 @@ The CLI will always override the JSON config.
|
|||
You can send the result of a run to Slack. First, set up a webhook in the Slack API (https://<your team>.slack.com/apps/manage/custom-integrations) and then configure it:
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io/ --slack.hookUrl https://hooks.slack.com/services/YOUR/HOOK/URL
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io/ --slack.hookUrl https://hooks.slack.com/services/YOUR/HOOK/URL
|
||||
~~~
|
||||
|
||||
You can choose to send just a summary (the summary for all runs), individual runs (with URL), only errors, or everything, by choosing the respective <code>slack.type</code>.
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io/ --slack.hookUrl https://hooks.slack.com/services/YOUR/HOOK/URL --slack.type summary
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io/ --slack.hookUrl https://hooks.slack.com/services/YOUR/HOOK/URL --slack.type summary
|
||||
~~~
|
||||
|
||||
|
||||
{: .img-thumbnail-center}
|
||||
|
||||
### Log in the user
|
||||
We have added a [special section](../prepostscript) for that!
|
||||
We have added a [special section](../scripting) for that!
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ You can throttle the connection to make the connectivity slower to make it easie
|
|||
### Docker networks
|
||||
Here's an full example to setup up Docker network bridges on a server that has tc installed:
|
||||
|
||||
~~~bash
|
||||
~~~shell
|
||||
#!/bin/bash
|
||||
echo 'Starting Docker networks'
|
||||
docker network create --driver bridge --subnet=192.168.33.0/24 --gateway=192.168.33.10 --opt "com.docker.network.bridge.name"="docker1" 3g
|
||||
|
|
@ -61,7 +61,7 @@ docker run --shm-size=1g --network=3g --rm sitespeedio/sitespeed.io:{% include v
|
|||
|
||||
And if you want to remove the networks:
|
||||
|
||||
~~~bash
|
||||
~~~shell
|
||||
#!/bin/bash
|
||||
echo 'Stopping Docker networks'
|
||||
docker network rm 3g
|
||||
|
|
@ -87,9 +87,15 @@ sitespeed.io --browsertime.connectivity.engine throttle -c cable https://www.sit
|
|||
|
||||
You can also use Throttle inside of Docker but then the host need to be the same OS as in Docker. In practice you can only use it on Linux. And then make sure to run *sudo modprobe ifb numifbs=1* first and give the container the right privileges *--cap-add=NET_ADMIN*.
|
||||
|
||||
Firt use modprobe:
|
||||
|
||||
~~~bash
|
||||
sudo modprobe ifb numifbs=1
|
||||
~~~
|
||||
$ sudo modprobe ifb numifbs=1
|
||||
$ docker run --cap-add=NET_ADMIN --shm-size=1g --rm sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} -c 3g --browsertime.connectivity.engine=throttle https://www.sitespeed.io/
|
||||
|
||||
And then then make user you use the right privileges:
|
||||
~~~bash
|
||||
docker run --cap-add=NET_ADMIN --rm sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} -c 3g --browsertime.connectivity.engine=throttle https://www.sitespeed.io/
|
||||
~~~
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -24,10 +24,10 @@ We have a ready made container with [Chrome, Firefox & Xvfb](https://hub.docker.
|
|||
### Structure
|
||||
The Docker structure looks like this:
|
||||
|
||||
[NodeJS with Ubuntu 17](https://github.com/sitespeedio/docker-node) -> [VisualMetrics dependencies](https://github.com/sitespeedio/docker-visualmetrics-deps) ->
|
||||
[NodeJS with Ubuntu 18](https://github.com/sitespeedio/docker-node) -> [VisualMetrics dependencies](https://github.com/sitespeedio/docker-visualmetrics-deps) ->
|
||||
[Firefox/Chrome/xvfb](https://github.com/sitespeedio/docker-browsers) -> [sitespeed.io](https://github.com/sitespeedio/sitespeed.io/blob/master/Dockerfile)
|
||||
|
||||
The first container installs NodeJS (latest LTS) on Ubuntu 17. The next one adds the dependencies (FFMpeg, ImageMagick and some Python libraries) needed to run [VisualMetrics](https://github.com/WPO-Foundation/visualmetrics). We then install specific version of Firefox, Chrome and lastly xvfb. Then in last step, we add sitespeed.io and tag it to the sitespeed.io version number.
|
||||
The first container installs NodeJS (latest LTS) on Ubuntu 18. The next one adds the dependencies (FFMpeg, ImageMagick and some Python libraries) needed to run [VisualMetrics](https://github.com/WPO-Foundation/visualmetrics). We then install specific version of Firefox, Chrome and lastly xvfb. Then in last step, we add sitespeed.io and tag it to the sitespeed.io version number.
|
||||
|
||||
We lock down the browsers to specific versions for maximum compatibility and stability with sitespeed.io's current feature set; upgrading once we verify browser compatibility.
|
||||
{: .note .note-info}
|
||||
|
|
@ -37,7 +37,7 @@ We lock down the browsers to specific versions for maximum compatibility and sta
|
|||
The simplest way to run using Chrome:
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} -b chrome https://www.sitespeed.io/
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} -b chrome https://www.sitespeed.io/
|
||||
~~~
|
||||
|
||||
Note: The shm-size increases the memory for the GPU (default is 64mb and that is too small) see [https://github.com/elgalu/docker-selenium/issues/20](https://github.com/elgalu/docker-selenium/issues/20).
|
||||
|
|
@ -45,13 +45,13 @@ Note: The shm-size increases the memory for the GPU (default is 64mb and that is
|
|||
In the real world you should always specify the exact version (tag) of the Docker container to make sure you use the same version for every run. If you use the latest tag you will download newer version of sitespeed.io as they become available, meaning you can have major changes between test runs (version upgrades, dependencies updates, browser versions, etc). So you should always specify a tag after the container name(X.Y.Z). Know that the tag/version number will be the same number as the sitespeed.io release:
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} -b chrome https://www.sitespeed.io/
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} -b chrome https://www.sitespeed.io/
|
||||
~~~
|
||||
|
||||
If you want to use Firefox:
|
||||
|
||||
~~~bash
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:X.Y.Z -b firefox https://www.sitespeed.io/
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} -b firefox https://www.sitespeed.io/
|
||||
~~~
|
||||
|
||||
Using `-v "$(pwd)":/sitespeed.io` will map the current directory inside Docker and output the result directory there.
|
||||
|
|
@ -112,7 +112,7 @@ The docker containers have `x11vnc` installed which enables visualisation of the
|
|||
- You will need to run the sitespeed.io image by exposing a PORT for vnc server. By default this port is 5900. If you plan to change your port for VNC server, then you need to expose that port.
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io -p 5900:5900 sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io/ -b chrome
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io -p 5900:5900 sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io/ -b chrome
|
||||
~~~
|
||||
|
||||
- Find the container id of the docker container for sitespeed by running:
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ Starting from sitespeed.io version 4 we send a moderated number of metrics per U
|
|||
|
||||
When you store metrics for a URL in Graphite, you decide from the beginning how long and how often you want to store the data, in [storage-schemas.conf](https://github.com/sitespeedio/docker-graphite-statsd/blob/master/conf/graphite/storage-schemas.conf). In our example Graphite setup, every key under sitespeed_io is caught by the configuration in storage-schemas.conf that looks like:
|
||||
|
||||
~~~
|
||||
~~~shell
|
||||
[sitespeed]
|
||||
pattern = ^sitespeed_io\.
|
||||
retentions = 10m:60d,30m:90d
|
||||
|
|
|
|||
|
|
@ -9,33 +9,38 @@ image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png
|
|||
twitterdescription: Documentation for sitespeed.io.
|
||||
---
|
||||
|
||||
# Documentation v7
|
||||
# Documentation v8
|
||||
|
||||
<img src="{{site.baseurl}}/img/logos/sitespeed.io.png" class="pull-right img-big" alt="sitespeed.io logo" width="200" height="214">
|
||||
|
||||
Sitespeed.io is the complete toolbox to test the web performance of your web site. Use it to monitor your performance or checkout how your competition is doing. You can see all the latest changes in the [Changelog](https://github.com/sitespeedio/sitespeed.io/blob/master/CHANGELOG.md) for the project.
|
||||
|
||||
## Start
|
||||
* [Introduction](introduction/) - start here if you are new to the project or web performance testing.
|
||||
* [Installation](installation/) - install using npm, yarn or run our Docker containers.
|
||||
* [Configuration](configuration/) - there's a lot of things you can do with sitespeed.io, lets checkout how!
|
||||
* [Browsers](browsers/) - collect timings using real browsers. We support Firefox, Chrome and Chrome on Android.
|
||||
* [Configuration](configuration/) - there's a lot of things you can do with sitespeed.io, lets checkout how!
|
||||
* [Connectivity](connectivity/) - set the connectivity to emulate real users network conditions.
|
||||
* [Performance Dashboard](performance-dashboard/) - keep track of your metrics and performance.
|
||||
* [Alerts](alerts/) - send alerts (email/Slack/PagerDuty etc) when you get a performance regression.
|
||||
* [Docker](docker/) - how to use our Docker containers.
|
||||
* [F.A.Q and Best Practice](best-practice/) - here we keep track of questions we get in Slack.
|
||||
* [Scripting](scripting/) - test a user journey, test multiple URLs, test login, test adding items to the cart with scripting.
|
||||
|
||||
## More details
|
||||
* [Alerts](alerts/) - send alerts (email/Slack/PagerDuty etc) when you get a performance regression.
|
||||
* [Continuous Integration](continuous-integration/) - generate JUnit XML/TAP and use Jenkins, Circle CI, Gitlab CI, Grunt or the Gulp plugin.
|
||||
* [Developers](developers/) - start here when you want to do PRs or create a plugin.
|
||||
* [Graphite](graphite/) - how to configure and store your metrics in Graphite (and using StatsD).
|
||||
* [How to Write a Good Bug Report](bug-report/) - if you write a good bug report, we can spend more time helping you fixing the problem instead of asking you questions
|
||||
* [Lighthouse](lighthouse/) - run Lighthouse and Google PageSpeed Insights from sitespeed.io.
|
||||
* [Metrics](metrics/) - configure which metrics you want to use.
|
||||
* [Mobile phones](mobile-phones/) - test using your mobile phone (Android only).
|
||||
* [Performance Budget](performance-budget/) - make sure you are within your performance budget.
|
||||
* [Performance Dashboard](performance-dashboard/) - keep track of your metrics and performance.
|
||||
* [Plugins](plugins/) - list/disable/enable or create your own plugin.
|
||||
* [Pre/post scripting](prepostscript/) - run Selenium scripts before/after you test a URL.
|
||||
* [Setup S3](s3/) - how to setup S3 for your html result/videos and screenshots.
|
||||
* [Metrics](metrics/) - configure which metrics you want to use.
|
||||
* [Continuous Integration](continuous-integration/) - generate JUnit XML/TAP and use Jenkins, Circle CI, Gitlab CI, Grunt or the Gulp plugin.
|
||||
* [Docker](docker/) - how to use our Docker containers.
|
||||
* [Graphite](graphite/) - how to configure and store your metrics in Graphite (and using StatsD).
|
||||
* [Single Page Application](spa/) - how to test your single page application.
|
||||
* [Video](video/) - all that you can do with the video.
|
||||
* [Upgrade](upgrade/) - upgrading from 5.x to 6.0 check out our guide here.
|
||||
* [Mobile phones](mobile-phones/) - test using your mobile phone (Android only).
|
||||
* [WebPageTest](webpagetest/) - drive WebPageTest and fetch metrics and graph them.
|
||||
* [Lighthouse](lighthouse/) - run Lighthouse and Google PageSpeed Insights from sitespeed.io.
|
||||
* [WebPageReplay](webpagereplay/) - WebPageReplay is proxy that first records your web site and then replay it locally. That can help you find performance regression in the front-end code easier: Latency/server timings are constant.
|
||||
* [Developers](developers/) - start here when you want to do PRs or create a plugin.
|
||||
* [How to Write a Good Bug Report](bug-report/) - if you write a good bug report, we can spend more time helping you fixing the problem instead of asking you questions.
|
||||
* [WebPageTest](webpagetest/) - drive WebPageTest and fetch metrics and graph them.
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ You can run sitespeed.io using our Docker containers or using NodeJS.
|
|||
|
||||
## Docker
|
||||
|
||||
We have [Docker images](https://hub.docker.com/r/sitespeedio/sitespeed.io/) with sitespeed.io, Chrome, Firefox and Xvfb. It is super easy to use (Xvfb is started automatically when you start the container). Here's how to use the container with both Firefox & Chrome (install [Docker](https://docs.docker.com/engine/installation/) first).
|
||||
We have [Docker images](https://hub.docker.com/r/sitespeedio/sitespeed.io/) with sitespeed.io, Chrome, Firefox, Xvfb and all the software needed for recording a video of the browser screen and analyze it to get Visual Metrics. It is super easy to use). Here's how to use the container with both Firefox & Chrome (install [Docker](https://docs.docker.com/install/) first).
|
||||
|
||||
### Mac & Linux
|
||||
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ The summary holds information per group, or specifically per domain. If you test
|
|||
You can list the metrics that are configured by **\-\-metrics.filterList**. The list is dependent on which plugins you are loading, so you will need to do an actual run to generate the list. The list is stored in the data folder in a file named **configuredMetrics.txt**.
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io https://www.sitespeed.io --metrics.filterList
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io --metrics.filterList
|
||||
~~~
|
||||
|
||||
The file will look something like this:
|
||||
|
|
@ -53,7 +53,7 @@ browsertime.pageSummary.statistics.custom.*
|
|||
You can also list all possible metrics that you can send. You can do that by using **\-\-metrics.list**. It will generate a text file named **metrics.txt** in the data folder.
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io https://www.sitespeed.io --metrics.list
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io --metrics.list
|
||||
~~~
|
||||
|
||||
|
||||
|
|
@ -87,7 +87,7 @@ coach.pageSummary.advice.performance.adviceList.thirdPartyAsyncJs.weight
|
|||
The score is ... yes the score and the weight is how important it is. You probably only need the score, so setting a filter like this **coach.pageSummary.advice.performance.adviceList.\*.score** will send them all (setting a wildcard for the name).
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io https://www.sitespeed.io --metrics.filter coach.pageSummary.advice.performance.adviceList.*.score -n 1
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io --metrics.filter coach.pageSummary.advice.performance.adviceList.*.score -n 1
|
||||
~~~
|
||||
|
||||
The best way to test and verify on your local, is to checkout the sitespeed.io project and then start a TCP server that logs everything:
|
||||
|
|
@ -105,7 +105,7 @@ $ Server listening on :::52860
|
|||
It will output the port, so you can then use it when you run sitespeed.io:
|
||||
|
||||
~~~bash
|
||||
docker run --net host --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io --metrics.list https://www.sitespeed.io -n 1 --metrics.filter coach.pageSummary.advice.performance.adviceList.*.score --graphite.host 127.0.0.1 --graphite.port 52860
|
||||
docker run --net host --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} --metrics.list https://www.sitespeed.io -n 1 --metrics.filter coach.pageSummary.advice.performance.adviceList.*.score --graphite.host 127.0.0.1 --graphite.port 52860
|
||||
~~~
|
||||
|
||||
The the previous example it will log all metrics you send to Graphite to the console.
|
||||
|
|
@ -114,7 +114,7 @@ The the previous example it will log all metrics you send to Graphite to the con
|
|||
|
||||
By default the total score for performance, accessibility and best practice is configured to send to Graphite. Previously we looked at sending all the score for the performance advice. If you want to send all the scores for all advice, you can do that easily, by adding all three categories in the CLI:
|
||||
|
||||
~~~
|
||||
~~~shell
|
||||
--metrics.filter coach.pageSummary.advice.performance.adviceList.*.score coach.pageSummary.advice.bestpractice.adviceList.*.score coach.pageSummary.advice.accessibility.adviceList.*.score
|
||||
~~~
|
||||
|
||||
|
|
@ -140,5 +140,5 @@ Sitespeed.io does not currently have support removal of a single metric, but you
|
|||
remove all configured metrics with the parameter value *\*-*. Here is an example sending only the **coach.pageSummary.advice.performance.adviceList.\*.score** metrics.
|
||||
|
||||
~~~bash
|
||||
docker run --net host --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io --metrics.list https://www.sitespeed.io -n 1 --metrics.filter *- coach.pageSummary.advice.performance.adviceList.*.score --graphite.host 127.0.0.1 --graphite.port 52860
|
||||
docker run --net host --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} --metrics.list https://www.sitespeed.io -n 1 --metrics.filter *- coach.pageSummary.advice.performance.adviceList.*.score --graphite.host 127.0.0.1 --graphite.port 52860
|
||||
~~~
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ sitespeed.io --browsertime.chrome.android.package com.android.chrome https://www
|
|||
Remember: To test on Android using Docker you need to be on Linux (tested on Ubuntu). It will not work on OS X.
|
||||
|
||||
~~~bash
|
||||
docker run --privileged -v /dev/bus/usb:/dev/bus/usb -e START_ADB_SERVER=true --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} -n 1 --browsertime.chrome.android.package com.android.chrome --browsertime.xvfb false https://www.sitespeed.io
|
||||
docker run --privileged -v /dev/bus/usb:/dev/bus/usb -e START_ADB_SERVER=true --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} -n 1 --browsertime.chrome.android.package com.android.chrome --browsertime.xvfb false https://www.sitespeed.io
|
||||
~~~
|
||||
|
||||
You will get result as you would with running this normally with summaries and waterfall graphs.
|
||||
|
|
@ -72,7 +72,7 @@ sitespeed.io --browsertime.chrome.android.package com.android.chrome --video --s
|
|||
And using Docker (remember: only works in Linux hosts):
|
||||
|
||||
~~~bash
|
||||
docker run --privileged -v /dev/bus/usb:/dev/bus/usb -e START_ADB_SERVER=true --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} -n 1 --browsertime.chrome.android.package com.android.chrome --browsertime.xvfb false https://www.sitespeed.io
|
||||
docker run --privileged -v /dev/bus/usb:/dev/bus/usb -e START_ADB_SERVER=true --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} -n 1 --browsertime.chrome.android.package com.android.chrome --browsertime.xvfb false https://www.sitespeed.io
|
||||
~~~
|
||||
|
||||
If you want to run Docker on Mac OS X, you can follow Appiums [setup](https://github.com/appium/appium-docker-android) by creating a docker-machine, give ut USB access and then run the container from that Docker machine.
|
||||
|
|
|
|||
|
|
@ -25,12 +25,10 @@ When you run sitespeed.io configured with a budget, the script will exit with an
|
|||
|
||||
The log will look something like this:
|
||||
|
||||
~~~
|
||||
[2016-10-24 10:53:01] Failing budget pagexray.pageSummary.transferSize for https://www.sitespeed.io/ with value 184.7 KB max limit 97.7 KB
|
||||
[2016-10-24 10:53:01] Failing budget pagexray.pageSummary.contentTypes.image.transferSize for https://www.sitespeed.io/ with value 157.3 KB max limit 97.7 KB
|
||||
[2016-10-24 10:53:01] Failing budget coach.pageSummary.advice.info.domElements for https://www.sitespeed.io/ with value 215 max limit 200
|
||||
[2016-10-24 10:53:01] Failing budget coach.pageSummary.advice.info.domDepth.max for https://www.sitespeed.io/ with value 11 max limit 10
|
||||
[2016-10-24 10:53:01] Budget: 8 working and 4 failing tests
|
||||
~~~shell
|
||||
[2019-01-20 19:58:18] ERROR: Failing budget timings.firstPaint for https://www.sitespeed.io/documentation/ with value 462 ms max limit 100 ms
|
||||
[2019-01-20 19:58:18] ERROR: Failing budget size.total for https://www.sitespeed.io/documentation/ with value 23.6 KB max limit 1000 B
|
||||
[2019-01-20 19:58:18] INFO: Budget: 3 working and 2 failing tests
|
||||
~~~
|
||||
|
||||
|
||||
|
|
@ -38,17 +36,103 @@ The report looks like this.
|
|||
|
||||
{: .img-thumbnail}
|
||||
|
||||
Now let's see how you configure budgets.
|
||||
|
||||
|
||||
### The budget file
|
||||
The current version can handle min/max values and works on the internal data structure.
|
||||
In 8.0 we introduced a new way of configuring budget. You can configure default values and specific for a URL. In the budget file there are 5 couple of sections:
|
||||
|
||||
* timings - are Visual and technical metrics and are configured in milliseconds (ms)
|
||||
* requests - the max number of requests per type or total
|
||||
* transferSize - the max transfer size (over the wire) per type or total
|
||||
* thirdPatrty - max number of requests or trasnferSize for third parties
|
||||
* score - minimum score for Coach advice
|
||||
|
||||
|
||||
#### Simple budget file
|
||||
The simplest version of a budget file that will check for SpeedIndex higher than 1000 ms looks like this:
|
||||
|
||||
~~~json
|
||||
{
|
||||
"budget": {
|
||||
"timings": {
|
||||
"SpeedIndex":1000
|
||||
}
|
||||
}
|
||||
}
|
||||
~~~
|
||||
|
||||
#### Override per URL
|
||||
All URLs that you test then needs to have a SpeedIndex faster than 1000. But if you have one URL that you know are slower? You can override budget per URL.
|
||||
|
||||
~~~json
|
||||
{
|
||||
"budget": {
|
||||
"https://www.sitespeed.io/documentation/": {
|
||||
"timings": {
|
||||
"SpeedIndex": 3000
|
||||
}
|
||||
},
|
||||
"timings": {
|
||||
"SpeedIndex":1000
|
||||
}
|
||||
}
|
||||
}
|
||||
~~~
|
||||
|
||||
#### Full example
|
||||
|
||||
Here is an example of a fully configurued budget file. It shows you what yiou *can* configure (but you shouldn't configure all of them).
|
||||
|
||||
|
||||
~~~json
|
||||
{
|
||||
"budget": {
|
||||
"timings": {
|
||||
"firstPaint": 1000,
|
||||
"fullyLoaded": 2000,
|
||||
"FirstVisualChange": 1000,
|
||||
"LastVisualChange": 1200,
|
||||
"SpeedIndex": 1200,
|
||||
"PerceptualSpeedIndex":1200,
|
||||
"VisualReadiness": 200,
|
||||
"VisualComplete95": 1190
|
||||
},
|
||||
"requests": {
|
||||
"total": 89,
|
||||
"html": 1,
|
||||
"javascript": 0,
|
||||
"css": 1,
|
||||
"image": 50,
|
||||
"font": 0
|
||||
},
|
||||
"transferSize": {
|
||||
"total": 400000,
|
||||
"html": 20000,
|
||||
"javascript": 0,
|
||||
"css": 10000,
|
||||
"image": 200000,
|
||||
"font": 0
|
||||
},
|
||||
"thirdParty": {
|
||||
"transferSize": 0,
|
||||
"requests": 0
|
||||
},
|
||||
"score": {
|
||||
"accessibility": 100,
|
||||
"bestpractice": 100,
|
||||
"privacy": 100,
|
||||
"performance": 100
|
||||
}
|
||||
}
|
||||
}
|
||||
~~~
|
||||
|
||||
#### Budget configuration using the internal data structrure
|
||||
There's also an old version of settiung a budget where you can do it for all metrics collected by sitespeed.io and works on the internal data structure.
|
||||
|
||||
|
||||
You can read more about the metrics/data structure in the [metrics section]({{site.baseurl}}/documentation/sitespeed.io/metrics/).
|
||||
|
||||
|
||||
~~~
|
||||
~~~json
|
||||
{
|
||||
"browsertime.pageSummary": [{
|
||||
"metric": "statistics.timings.firstPaint.median",
|
||||
|
|
@ -98,7 +182,7 @@ You can read more about the metrics/data structure in the [metrics section]({{si
|
|||
Then run it like this:
|
||||
|
||||
~~~bash
|
||||
$ docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io https://www.sitespeed.io/ --budget.configPath myBudget.json -b chrome -n 11
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io/ --budget.configPath myBudget.json -b chrome -n 11
|
||||
~~~
|
||||
|
||||
And, if the budget fails, the exit status will be > 0. You can also choose to report the budget as JUnitXML (Jenkins) or TAP.
|
||||
|
|
@ -107,7 +191,7 @@ And, if the budget fails, the exit status will be > 0. You can also choose to re
|
|||
You can output a JUnit XML file from the budget result like this:
|
||||
|
||||
~~~bash
|
||||
$ docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io https://www.sitespeed.io/ --budget.configPath myBudget.json --budget.output junit -b chrome -n 5
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io/ --budget.configPath myBudget.json --budget.output junit -b chrome -n 5
|
||||
~~~
|
||||
|
||||
It will create a *junit.xml* in the outputFolder.
|
||||
|
|
@ -116,7 +200,7 @@ It will create a *junit.xml* in the outputFolder.
|
|||
If you would instead like to use TAP, you can do so like this:
|
||||
|
||||
~~~bash
|
||||
$ docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io https://www.sitespeed.io/ --budget.configPath myBudget.json --budget.output tap -b chrome -n 5
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io/ --budget.configPath myBudget.json --budget.output tap -b chrome -n 5
|
||||
~~~
|
||||
|
||||
It will create a *budget.tap* in the outputFolder.
|
||||
|
|
|
|||
|
|
@ -98,7 +98,7 @@ We have a small shell script that runs the tests. It is triggered from the cron
|
|||
Our *run.sh* file (we read which URLs we want to test from files):
|
||||
|
||||
## Shell script
|
||||
~~~
|
||||
~~~shell
|
||||
#!/bin/bash
|
||||
# Specify the exact version of sitespeed.io. When you upgrade to the next version, pull it down and the chage the tag
|
||||
DOCKER_CONTAINER=sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %}
|
||||
|
|
@ -128,7 +128,7 @@ docker pull $DOCKER_CONTAINER
|
|||
## Crontab
|
||||
We trigger the script from the crontab. We run the script every hour.
|
||||
|
||||
~~~
|
||||
~~~shell
|
||||
SHELL=/bin/bash
|
||||
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
|
||||
0 * * * * /root/runs.sh >> /tmp/sitespeed.io.log 2>&1
|
||||
|
|
@ -137,7 +137,7 @@ PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
|
|||
## Infinite loop
|
||||
Another way is to just run the script in an infinite loop and then have a file that you remove (so the run stops) when you want to update your instance. This example script is on Ubuntu.
|
||||
|
||||
~~~
|
||||
~~~shell
|
||||
#!/bin/bash
|
||||
LOGFILE=/tmp/s.log
|
||||
exec > $LOGFILE 2>&1
|
||||
|
|
@ -192,20 +192,20 @@ done
|
|||
|
||||
And make sure the script start on server restart. Edit the crontab <code>crontab -e</code> and add (loop.sh is the name of your loop script file):
|
||||
|
||||
~~~
|
||||
~~~shell
|
||||
@reboot rm /home/ubuntu/sitespeed.run;/home/ubuntu/loop.sh
|
||||
~~~
|
||||
|
||||
And start it like this:
|
||||
|
||||
~~~
|
||||
~~~bash
|
||||
nohup /home/ubuntu/loop.sh &
|
||||
~~~
|
||||
|
||||
## default.json
|
||||
And our default configuration is in *default.json*:
|
||||
|
||||
~~~
|
||||
~~~json
|
||||
{
|
||||
"browsertime": {
|
||||
"connectivity": {
|
||||
|
|
@ -243,7 +243,7 @@ And our default configuration is in *default.json*:
|
|||
## Docker networks
|
||||
And we set up the following Docker networks (*startNetworks.sh*):
|
||||
|
||||
~~~
|
||||
~~~shell
|
||||
#!/bin/bash
|
||||
echo 'Starting Docker networks'
|
||||
docker network create --driver bridge --subnet=192.168.33.0/24 --gateway=192.168.33.10 --opt "com.docker.network.bridge.name"="docker1" 3g
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ The most basic things you can do is list configured plugins (which are currently
|
|||
You can list the plugins that will be used when you do a run:
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} --plugins.list https://en.wikipedia.org/wiki/Barack_Obama
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} --plugins.list https://en.wikipedia.org/wiki/Barack_Obama
|
||||
~~~
|
||||
|
||||
And you will get a log entry that looks something like this:
|
||||
|
|
@ -41,19 +41,19 @@ The default plugins lives in the [plugin folder](https://github.com/sitespeedio/
|
|||
You can remove/disable default plugins if needed. For instance you may not want to output HTML and strictly send the data to Graphite.
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io --plugins.remove html
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io --plugins.remove html
|
||||
~~~
|
||||
|
||||
If you want to disable multiple plugins say you don't need the html or screenshots:
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io --plugins.remove html --plugins.remove screenshot
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io --plugins.remove html --plugins.remove screenshot
|
||||
~~~
|
||||
|
||||
At anytime if you want to verify that disabling worked, add the plugins.list to your command:
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io --plugins.remove html --plugins.remove screenshot --plugins.list
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io --plugins.remove html --plugins.remove screenshot --plugins.list
|
||||
~~~
|
||||
|
||||
## Add a plugin
|
||||
|
|
@ -62,7 +62,7 @@ You can also add a plugin. This is great if you have plugins you created yoursel
|
|||
There's a plugin bundled with sitespeed.io called *analysisstorer* plugin that isn't enabled by default. It stores the original JSON data from all analyzers (from Browsertime, Coach data, WebPageTest etc) to disk. You can enable this plugin:
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io --plugins.add analysisstorer
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://www.sitespeed.io --plugins.add analysisstorer
|
||||
~~~
|
||||
|
||||
If you want to run plugins that you created yourself or that are shared from others, you can either install the plugin using npm (locally) and load it by name or point out the directory where the plugin lives.
|
||||
|
|
@ -73,7 +73,7 @@ If you want to run plugins that you created yourself or that are shared from oth
|
|||
If you run in Docker and you should. You will need to mount your plugin directory as a volume. This is the recommended best practice. Practically you should clone your repo on your server and then mount it like this.
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} -b firefox --plugins.add /sitespeed.io/myplugin -n 1 https://www.sitespeed.io/
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} -b firefox --plugins.add /sitespeed.io/myplugin -n 1 https://www.sitespeed.io/
|
||||
~~~
|
||||
|
||||
### Relative using NodeJS
|
||||
|
|
@ -86,7 +86,7 @@ sitespeed.io https://www.sitespeed.io --plugins.add ../my/super/plugin
|
|||
### Pre-baked Docker file
|
||||
If you want to create an image of sitespeed.io with your plugins pre-baked for sharing you can also do so using the following Dockerfile.
|
||||
|
||||
~~~
|
||||
~~~docker
|
||||
FROM sitespeedio/sitespeed.io:<insert version here>
|
||||
ENV SITESPEED_IO_PLUGINS__ADD /my-custom-plugin
|
||||
|
||||
|
|
@ -111,7 +111,7 @@ docker build -t my-custom-sitespeedio .
|
|||
Finally you can run it the same way as mentioned above without the volume mount and without adding your plugin (that was automatically fixed in your Docker file).
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io my-custom-sitespeedio -b firefox --my-custom-plugin.option test -n 1 https://www.sitespeed.io/
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io my-custom-sitespeedio -b firefox --my-custom-plugin.option test -n 1 https://www.sitespeed.io/
|
||||
~~~
|
||||
|
||||
Pretty cool, huh? :-)
|
||||
|
|
@ -159,7 +159,7 @@ The open function is called once when sitespeed.io starts, it's in this function
|
|||
|
||||
The *context* holds information for this specific run that generated at runtime and looks like this:
|
||||
|
||||
~~~
|
||||
~~~javascript
|
||||
{
|
||||
storageManager, // The storage manager is what you use to store data to disk
|
||||
resultUrls,
|
||||
|
|
@ -193,7 +193,7 @@ When you start the application and feed it with URLs, each URL will generate a m
|
|||
|
||||
If you want to catch it, you can do something like this:
|
||||
|
||||
~~~
|
||||
~~~javascript
|
||||
switch (message.type) {
|
||||
case 'url':
|
||||
{
|
||||
|
|
@ -205,7 +205,7 @@ When you are finished analysing the URL, your plugin can then send a message wit
|
|||
|
||||
Here's a snippet of Browsertime sending the screenshots message (the actual screenshot is in *results.screenshots*):
|
||||
|
||||
~~~
|
||||
~~~javascript
|
||||
const messageMaker = context.messageMaker;
|
||||
...
|
||||
|
||||
|
|
@ -217,7 +217,7 @@ queue.postMessage(make('browsertime.screenshot', results.screenshots, {
|
|||
|
||||
If you want to send messages from within your plugin, you get it from the context.
|
||||
|
||||
~~~
|
||||
~~~javascript
|
||||
const messageMaker = context.messageMaker;
|
||||
~~~
|
||||
|
||||
|
|
@ -241,7 +241,7 @@ You get the log object in the context object (so there's no need to require the
|
|||
|
||||
In the [open](#opencontext-options) function you can add something like this:
|
||||
|
||||
~~~
|
||||
~~~javascript
|
||||
// Register a logger for this plugin, a unique name so we can filter the log
|
||||
// And save the log for later
|
||||
this.log = context.intel.getLogger('sitespeedio.plugin.PLUGIN_NAME');
|
||||
|
|
@ -264,7 +264,7 @@ You start by listening to the generic setup message **sitespeedio.setup**. When
|
|||
|
||||
Sending a pug looks something like this:
|
||||
|
||||
~~~
|
||||
~~~javascript
|
||||
case 'sitespeedio.setup': {
|
||||
queue.postMessage(
|
||||
make('html.pug', {
|
||||
|
|
@ -285,7 +285,7 @@ The HTML plugin will automatically pickup data sent with the types of \*.run and
|
|||
|
||||
A message can look like this (the HTML plugin will pickup messages sent by combining the id + type):
|
||||
|
||||
~~~
|
||||
~~~javascript
|
||||
queue.postMessage(
|
||||
make('gpsi.pageSummary', result, {
|
||||
url,
|
||||
|
|
@ -303,7 +303,7 @@ collect metrics.
|
|||
|
||||
You do that by in the setup phase, send the JavaScript you want to run to sitespeed.io
|
||||
|
||||
~~~
|
||||
~~~javascript
|
||||
case 'sitespeedio.setup': {
|
||||
queue.postMessage(
|
||||
make('browsertime.scripts', {
|
||||
|
|
@ -322,7 +322,7 @@ You can also let Browsertime run asynchronous scripts, follow the same pattern a
|
|||
|
||||
You can then get the metrics back by listening on **browsertime.run** messages.
|
||||
|
||||
~~~
|
||||
~~~javascript
|
||||
case 'browsertime.run': {
|
||||
console.log(message.data.yourplugin);
|
||||
break;
|
||||
|
|
@ -331,7 +331,7 @@ case 'browsertime.run': {
|
|||
|
||||
And if you want to use it in your pug template you will find it under **pageInfo.data.browsertime.run.yourplugin**. In this example, if you want to print the title you can do like this.
|
||||
|
||||
~~~
|
||||
~~~javascript
|
||||
#{pageInfo.data.browsertime.run.yourplugin.title}
|
||||
~~~
|
||||
|
||||
|
|
@ -341,7 +341,7 @@ In the *sitespeedio.config* phase (where plugins can talk to each other) make su
|
|||
|
||||
In this example we tell the budget plugin that it should collect metrics of the type *gpsi.pagesummary*.
|
||||
|
||||
~~~
|
||||
~~~javascript
|
||||
const messageMaker = context.messageMaker;
|
||||
...
|
||||
|
||||
|
|
|
|||
|
|
@ -17,106 +17,71 @@ twitterdescription: Pre/post scripts (log in the user)
|
|||
{:toc}
|
||||
|
||||
# Selenium
|
||||
Since sitespeed.io 8.0 the pre/post script has changed. You probably should use just [a script to navigate](../scripting/).
|
||||
|
||||
Before sitespeed.io loads and tests a URL you can run your own Selenium script. Do you want to access a URL and pre-load the cache or maybe you want to login as a user and then measure a URL?
|
||||
|
||||
We use the NodeJs version of Selenium, you can find the [API documentation here](http://seleniumhq.github.io/selenium/docs/api/javascript/index.html). You need to go into the docs to see how to select the elements you need to do the magic on your page.
|
||||
|
||||
Your script needs to follow a specific pattern to be able to run as a pre/post script. The simplest version of a script looks like this:
|
||||
|
||||
~~~
|
||||
module.exports = {
|
||||
run(context) {
|
||||
return context.runWithDriver((driver) => {
|
||||
// Add your own code here
|
||||
});
|
||||
}
|
||||
};
|
||||
~~~javascript
|
||||
module.exports = async function(context, commands) {
|
||||
// add your own code here
|
||||
}
|
||||
~~~
|
||||
|
||||
Move on to read about the data that is passed in the context object and how you can use it to get hold of the Selenium objects you need to interact with the page.
|
||||
|
||||
## Data to the pre/post script
|
||||
|
||||
Your pre/post script is fed with the Selenium **driver** (that you use if you need to navigate to a page) and a batch of other objects in the context object.
|
||||
Your script will get access to two objects: The *context* object that holds information about the current run and the *commands* object that has commands/shortcuts to navigate in the page,
|
||||
|
||||
~~~
|
||||
const context = {
|
||||
url,
|
||||
options,
|
||||
log,
|
||||
storageManager: this.storageManager,
|
||||
taskData: {},
|
||||
index,
|
||||
webdriver,
|
||||
runWithDriver: function(driverScript) {
|
||||
return browser.runWithDriver(driverScript);
|
||||
}
|
||||
};
|
||||
~~~
|
||||
The context object:
|
||||
* *options* - All the options sent from the CLI to Browsertime.
|
||||
* *log* - an instance to the log system so you can log from your navigation script.
|
||||
* *index* - the index of the runs, so you can keep track of which run that is running.
|
||||
* *storageManager* - The Browsertime storage manager that can help you get read/store files to disk.
|
||||
* *selenium.webdriver* - The Selenium [WebDriver public API object](https://seleniumhq.github.io/selenium/docs/api/javascript/module/selenium-webdriver/index.html).
|
||||
* *selenium.driver* - The [instantiated version of the WebDriver](https://seleniumhq.github.io/selenium/docs/api/javascript/module/selenium-webdriver/index_exports_WebDriver.html) driving the current version of the browser.
|
||||
|
||||
The important objects that you can use are:
|
||||
* *url* - The URL of the page that you are going to test
|
||||
* *options* - The options object that is created from the CLI. Here you can get hold of all paramaters you pass on to sitespeed.io
|
||||
* *log* - this is the internal log object we use in sitespeed.io to write the log output. We use [intel](https://www.npmjs.com/package/intel) for logging.
|
||||
* *index* - which index of the runs (first, second etc).
|
||||
* *webdriver* - the Selenium [Webdriver object](http://seleniumhq.github.io/selenium/docs/api/javascript/module/selenium-webdriver/index.html) that is the way to get hold of the Selenium objects that you need.
|
||||
|
||||
The commands object:
|
||||
* *navigate(URL)* - Use this if you want to use the exact way as Browsertime navigates to a new URL (same settings with pageCompleteCheck etc). But that URL will not be measured automatically.
|
||||
* *measure.start(URL)* - Start measuring and navigate to a new page in one go and measure.
|
||||
* *measure.start(URL,alias)* - Start measuring and navigate to a new page in one go and measure. And register an alias for that URL.
|
||||
* *measure.start()* - Use this when you want to start to measure a page. This will start the video and prepare everything to collect metrics. But it will not navigate to the URL.
|
||||
* *measure.start(alias)* - Use this when you want to start to measure a page. This will start the video and prepare everything to collect metrics. But it will not navigate to the URL. The next URL that will be accessed will get the alias.
|
||||
* *measure.stop()* - Collect metrics for a page.
|
||||
|
||||
## Debug/log from your script
|
||||
In your script you can get hold of the log object from sitespeed.io. This is super useful when you want to test your script and verify that everything works as it should. We use [intel](https://www.npmjs.com/package/intel) for logging.
|
||||
|
||||
~~~
|
||||
module.exports = {
|
||||
run(context) {
|
||||
return context.runWithDriver((driver) => {
|
||||
// Simple example to add a log message
|
||||
// Remember that you can log message on different levels
|
||||
context.log.info('Log message from the task');
|
||||
});
|
||||
}
|
||||
~~~javascript
|
||||
module.exports = async function(context, commands) {
|
||||
// Simple example to add a log message
|
||||
// Remember that you can log message on different levels
|
||||
context.log.info('Log message from the task');
|
||||
};
|
||||
~~~
|
||||
|
||||
If you run in Docker it can sometimes be hard to see/know what happens. To verify that your pre/post script works as they should (and the page loads as you think), you can enable a video of the full run (pre/post scripts and the test). Do that by adding: <code>--browsertime.videoParams.combine</code>
|
||||
|
||||
Then your video will include all your steps. Perfect for debugging.
|
||||
|
||||
You need to have video turned on (in Docker it is on by default) to be able to combine the video.
|
||||
{: .note .note-warning}
|
||||
|
||||
## Login example
|
||||
Create a script where you login the user. The following is an example to login the user at Wikipedia. Start by creating a file login.js with the following.
|
||||
|
||||
~~~
|
||||
module.exports = {
|
||||
run(context) {
|
||||
return context.runWithDriver((driver) => {
|
||||
// Go to Wikipedias login URL
|
||||
return driver.get('https://en.wikipedia.org/w/index.php?title=Special:UserLogin&returnto=Main+Page')
|
||||
.then(() => {
|
||||
// You need to find the form, the login input fields and the
|
||||
// password field. Just add you name and password and submit the form
|
||||
// For more docs, checkout the NodeJS Selenium version
|
||||
// http://seleniumhq.github.io/selenium/docs/api/javascript/index.html
|
||||
~~~javascript
|
||||
module.exports = async function(context, commands) {
|
||||
await commands.navigate(
|
||||
'https://en.wikipedia.org/w/index.php?title=Special:UserLogin&returnto=Main+Page'
|
||||
);
|
||||
// Add text into an input field y finding the field by id
|
||||
await commands.addText.byId('login', 'wpName1');
|
||||
await commands.addText.byId('password', 'wpPassword1');
|
||||
|
||||
// we fetch the selenium webdriver from context
|
||||
const webdriver = context.webdriver;
|
||||
// and get hold of some goodies we want to use
|
||||
const until = webdriver.until;
|
||||
const By = webdriver.By;
|
||||
// find the sumbit button and click it
|
||||
await commands.click.byIdAndWait('wpLoginAttempt');
|
||||
|
||||
// before you start, make your username and password
|
||||
const userName = 'YOUR_USERNAME_HERE';
|
||||
const password = 'YOUR_PASSWORD_HERE';
|
||||
const loginForm = driver.findElement(By.name('userlogin'));
|
||||
driver.findElement(By.id('wpName1')).sendKeys(userName);
|
||||
driver.findElement(By.id('wpPassword1')).sendKeys(password);
|
||||
const loginButton = driver.findElement(webdriver.By.id('wpLoginAttempt'));
|
||||
loginButton.click();
|
||||
// we wait for something on the page that verifies that we are logged in
|
||||
return driver.wait(until.elementLocated(By.id('pt-userpage')), 3000);
|
||||
});
|
||||
})
|
||||
}
|
||||
// we wait for something on the page that verifies that we are logged in
|
||||
return commands.wait.byId('pt-userpage',3000);
|
||||
};
|
||||
~~~
|
||||
|
||||
|
|
@ -126,55 +91,22 @@ Make sure to change the username & password if you try this on Wikipedia. And of
|
|||
Then run it like this:
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} --preScript /sitespeed.io/login.js https://en.wikipedia.org/wiki/Barack_Obama
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} --preScript /sitespeed.io/login.js https://en.wikipedia.org/wiki/Barack_Obama
|
||||
~~~
|
||||
|
||||
The script will then login the user and access https://en.wikipedia.org/wiki/Barack_Obama and measure that page.
|
||||
|
||||
|
||||
Checkout the magic row:
|
||||
|
||||
~~~
|
||||
const webdriver = context.webdriver;
|
||||
~~~
|
||||
|
||||
From the context object you get a hold of the Selenium [Webdriver object](http://seleniumhq.github.io/selenium/docs/api/javascript/module/selenium-webdriver/index.html) and the mechanisms for locating an element on the page.
|
||||
|
||||
Note: Use the supplied *driver* object to go to a specific page.
|
||||
|
||||
## Pass your own options to your pre/post scripts
|
||||
You can add your own parameters to the options object (by adding a parameter) and then pick them up in the pre/post script. The scripts runs in the context of browsertime, so you need to
|
||||
pass it on in that context.
|
||||
|
||||
For example: you wanna pass on a password to your script, you can do that by adding <code>--browsertime.my.password MY_PASSWORD</code> and then in your code get hold of that with:
|
||||
|
||||
~~~
|
||||
~~~javascript
|
||||
...
|
||||
// We are in browsertime context so you can skip that from your options object
|
||||
context.log.info(context.options.my.password);
|
||||
...
|
||||
~~~
|
||||
|
||||
## Test a page with primed cache
|
||||
One other thing you can do with a pre script is simulate a user that browsed a couple of pages and then measure the performance of a page (by default the cache is emptied when you use sitespeed.io).
|
||||
|
||||
Create a pre script (pre.js):
|
||||
|
||||
~~~
|
||||
module.exports = {
|
||||
run(context) {
|
||||
return context.runWithDriver((driver) => {
|
||||
// Go to the start page of sitespeed.io
|
||||
return driver.get('https://www.sitespeed.io/');
|
||||
});
|
||||
}
|
||||
};
|
||||
~~~
|
||||
|
||||
And then run it like this:
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} --preScript /sitespeed.io/pre.js -b chrome https://www.sitespeed.io/documentation/
|
||||
~~~
|
||||
|
||||
The browser will first access https://www.sitespeed.io/, this will fill the cache and then go to https://www.sitespeed.io/documentation/ where it will collect all the metrics.
|
||||
|
|
|
|||
|
|
@ -72,7 +72,7 @@ And then you should also make sure that all the result files (HTML/videos/screen
|
|||
## JSON configuration file
|
||||
If you use a JSON configuration file you should make sure you add this to get S3 to work:
|
||||
|
||||
~~~
|
||||
~~~javascript
|
||||
{
|
||||
...
|
||||
"resultBaseURL": "https://your.bucket.url",
|
||||
|
|
|
|||
|
|
@ -0,0 +1,401 @@
|
|||
---
|
||||
layout: default
|
||||
title: Use scripts in sitespeed.io to measure a user journey.
|
||||
description: With scripts you can simulate a user visiting to miltiple pages, clicking on links, log in, adding items to the cart ... yeah do whatever you want!
|
||||
keywords: selenium, web performance, sitespeed.io
|
||||
nav: documentation
|
||||
category: sitespeed.io
|
||||
image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png
|
||||
twitterdescription: Use scripts in sitespeed.io to measure a user journey.
|
||||
---
|
||||
[Documentation]({{site.baseurl}}/documentation/sitespeed.io/) / Scripting
|
||||
|
||||
# Scripting
|
||||
{:.no_toc}
|
||||
|
||||
* Lets place the TOC here
|
||||
{:toc}
|
||||
|
||||
# Test by scripting
|
||||
|
||||
<img src="{{site.baseurl}}/img/user-journey.png" class="pull-right img-big" alt="The user journey" width="250">
|
||||
|
||||
Test by scripting was introduced in sitespeed.io 8.0 and Browsertime 4.0 and makes it possible to measure a user journey. A user visiting multiple pages, clicking on links, log in, adding items to the cart ... yeah do whatever you want.
|
||||
|
||||
Scripting work the same in Browsertime and sitespeed.io, the documentation here are for both of the tools.
|
||||
|
||||
Your script will get access to two objects: The *context* object that holds information about the current run and the *commands* object that has commands/shortcuts to navigate in the page.
|
||||
|
||||
The simplest version of a script looks like this:
|
||||
|
||||
~~~javascript
|
||||
module.exports = async function(context, commands) {
|
||||
// add your own code here
|
||||
}
|
||||
~~~
|
||||
|
||||
Inside of that function you can use the context and commands objects.
|
||||
|
||||
The context object:
|
||||
* *options* - All the options sent from the CLI to Browsertime.
|
||||
* *log* - an instance to the log system so you can log from your navigation script.
|
||||
* *index* - the index of the runs, so you can keep track of which run that is running.
|
||||
* *storageManager* - The Browsertime storage manager that can help you get read/store files to disk.
|
||||
* *selenium.webdriver* - The Selenium [WebDriver public API object](https://seleniumhq.github.io/selenium/docs/api/javascript/module/selenium-webdriver/index.html).
|
||||
* *selenium.driver* - The [instantiated version of the WebDriver](https://seleniumhq.github.io/selenium/docs/api/javascript/module/selenium-webdriver/index_exports_WebDriver.html) driving the current version of the browser.
|
||||
|
||||
|
||||
The commands object:
|
||||
* *[navigate(URL)](#navigateurl)* - Use this if you want to use the exact way as Browsertime navigates to a new URL (same settings with pageCompleteCheck etc). But that URL will not be measured automatically.
|
||||
* *[measure.start(URL)](#measurestarturl)* - Start measuring and navigate to a new page in one go and measure.
|
||||
* *[measure.start(URL,alias)](#measurestarturl-alias)* - Start measuring and navigate to a new page in one go and measure. And register an alias for that URL.
|
||||
* *[measure.start()](#measurestart)* - Use this when you want to start to measure a page. This will start the video and prepare everything to collect metrics. But it will not navigate to the URL.
|
||||
* *[measure.start(alias)](#measurestartalias)* - Use this when you want to start to measure a page. This will start the video and prepare everything to collect metrics. But it will not navigate to the URL. The next URL that will be accessed will get the alias.
|
||||
* *[measure.stop()](#measurestop)* - Collect metrics for a page.
|
||||
|
||||
And then you have a couple of help commands:
|
||||
* *[wait](#wait)* on a id to appear or wait x amountt of ms.
|
||||
* *[click](#click)* on a link and/or wait for the next page to load.
|
||||
* *[js](#run-javascript)* - run JavaScript in the browser.
|
||||
* *[switch](#switch)* to another frame or windo.
|
||||
|
||||
|
||||
## Run
|
||||
You run your script by passing it to sitespeed.io and adding the parameter ```--multi```. If you have multiple scripts, you can just pass them on too.
|
||||
|
||||
~~~bash
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} script.js script2.js script3.js --multi
|
||||
~~~
|
||||
|
||||
## Examples
|
||||
Here are a couple of examples on how you can use the scripting capabilities.
|
||||
|
||||
### Measure the actual login step
|
||||
|
||||
~~~javascript
|
||||
module.exports = async function(context, commands) {
|
||||
// Navigate to a URL and do not measure the URL
|
||||
await commands.navigate(
|
||||
'https://en.wikipedia.org/w/index.php?title=Special:UserLogin&returnto=Main+Page'
|
||||
);
|
||||
|
||||
try {
|
||||
// Add text into an input field, finding the field by id
|
||||
await commands.addText.byId('login', 'wpName1');
|
||||
await commands.addText.byId('password', 'wpPassword1');
|
||||
|
||||
// Start the measurement and give it the alias login
|
||||
// The alias will be useds when the metrics is sent to
|
||||
// Graphite/InfluxDB
|
||||
await commands.measure.start('login');
|
||||
|
||||
// Find the sumbit button and click it and wait for the
|
||||
// page complete check to finish on the next loaded URL
|
||||
await commands.click.byIdAndWait('wpLoginAttempt');
|
||||
// Stop and collect the metrics
|
||||
return commands.measure.stop();
|
||||
} catch (e) {
|
||||
// We try/catch so we will catch if the the input fields can't be found
|
||||
// The error is automatically logged in Browsertime an rethrown here
|
||||
}
|
||||
};
|
||||
~~~
|
||||
|
||||
### Measure the login step and more pages
|
||||
|
||||
~~~javascript
|
||||
module.exports = async function(context, commands) {
|
||||
// We start by navigating to the login page.
|
||||
await commands.navigate(
|
||||
'https://en.wikipedia.org/w/index.php?title=Special:UserLogin&returnto=Main+Page'
|
||||
);
|
||||
|
||||
// When we fill in a input field/click on a link we wanna
|
||||
// try/catch that if the HTML on the page changes in the feature
|
||||
// sitespeed.io will automatically log the error in a user friendly
|
||||
// way, and the error will be re-thrown so you can act on it.
|
||||
try {
|
||||
// Add text into an input field, finding the field by id
|
||||
await commands.addText.byId('login', 'wpName1');
|
||||
await commands.addText.byId('password', 'wpPassword1');
|
||||
|
||||
// Start the measurement before we click on the
|
||||
// submit button. Sitespeed.io will start the video recording
|
||||
// and prepare everything.
|
||||
await commands.measure.start('login');
|
||||
// Find the sumbit button and click it and then wait
|
||||
// for the pageCompleteCheck to finish
|
||||
await commands.click.byIdAndWait('wpLoginAttempt');
|
||||
// Stop and collect the measurement before the next page we want to measure
|
||||
await commands.measure.stop();
|
||||
// Measure the Barack Obama page as a logged in user
|
||||
await commands.measure.start(
|
||||
'https://en.wikipedia.org/wiki/Barack_Obama'
|
||||
);
|
||||
// And then measure the president page
|
||||
return commands.measure.start('https://en.wikipedia.org/wiki/President_of_the_United_States');
|
||||
} catch (e) {
|
||||
// We try/catch so we will catch if the the input fields can't be found
|
||||
// The error is automatically logged in Browsertime and re-thrown here
|
||||
}
|
||||
};
|
||||
~~~
|
||||
|
||||
### Measure one page after you logged in
|
||||
|
||||
Testing a page after you have logged in:
|
||||
First create a script that logs in the user (login.js):
|
||||
|
||||
~~~javascript
|
||||
module.exports = async function(context, commands) {
|
||||
await commands.navigate(
|
||||
'https://en.wikipedia.org/w/index.php?title=Special:UserLogin&returnto=Main+Page'
|
||||
);
|
||||
|
||||
try {
|
||||
await commands.addText.byId('login', 'wpName1');
|
||||
await commands.addText.byId('password', 'wpPassword1');
|
||||
// Click on the submit button with id wpLoginAttempt
|
||||
await commands.click.byIdAndWait('wpLoginAttempt');
|
||||
// wait on a specific id to appear on the page after you logged in
|
||||
return commands.wait.byId('pt-userpage', 10000);
|
||||
} catch (e) {
|
||||
// We try/catch so we will catch if the the input fields can't be found
|
||||
// The error is automatically logged in Browsertime and re-thrown here
|
||||
};
|
||||
~~~
|
||||
|
||||
Then access the page that you want to test:
|
||||
|
||||
~~~bash
|
||||
sitespeed.io --preScript login.js https://en.wikipedia.org/wiki/Barack_Obama
|
||||
~~~
|
||||
|
||||
#### More complicated login example
|
||||
|
||||
~~~javascript
|
||||
module.exports = async function(context, command) {
|
||||
await command.navigate(
|
||||
'https://example.org'
|
||||
);
|
||||
try {
|
||||
// Find the sign in button and click it
|
||||
await command.click.byId('sign_in_button');
|
||||
// Wait some time for the page to open a new login frame
|
||||
await command.wait.byTime(2000);
|
||||
// Switch to the login frame
|
||||
await command.switch.toFrame('loginFrame');
|
||||
// Find the usenrmane fields by xpath (just as an example)
|
||||
await command.addText.byXpath(
|
||||
'peter@example.org',
|
||||
'//*[@id="userName"]'
|
||||
);
|
||||
// Click on the necx buttin
|
||||
await command.click.byId('verifyUserButton');
|
||||
// Wait for the gui to display the password field so we can select it
|
||||
await command.wait.byTime(2000);
|
||||
// Wait for the actual password field
|
||||
await command.wait.byId('password', 5000);
|
||||
// Fill in the password
|
||||
await command.addText.byId('dejh8Ghgs6ga(1217)', 'password');
|
||||
// Click the submit button
|
||||
await command.click.byId('btnSubmit');
|
||||
// In your implementation it is probably better to wait for an id
|
||||
await command.wait.byTime(5000);
|
||||
// Measure the next page as a logged in user
|
||||
return command.measure.start(
|
||||
'https://example.org/logged/in/page'
|
||||
);
|
||||
} catch(e) {
|
||||
// We try/catch so we will catch if the the input fields can't be found
|
||||
}
|
||||
};
|
||||
~~~
|
||||
|
||||
### Measure multiple pages
|
||||
|
||||
Test multiple pages in a script:
|
||||
|
||||
~~~javascript
|
||||
module.exports = async function(context, commands) {
|
||||
await commands.measure.start('https://www.sitespeed.io');
|
||||
await commands.measure.start('https://www.sitespeed.io/examples/');
|
||||
return commands.measure.start('https://www.sitespeed.io/documentation/');
|
||||
};
|
||||
~~~
|
||||
|
||||
### Log from your script
|
||||
|
||||
You can log to the same log output as sitespeed.io:
|
||||
|
||||
~~~javascript
|
||||
module.exports = async function(context, commands) {
|
||||
context.log.info('Info logging from your script');
|
||||
context.log.error('Error logging from your script');
|
||||
};
|
||||
~~~
|
||||
|
||||
### Pass your own options to your script
|
||||
You can add your own parameters to the options object (by adding a parameter) and then pick them up in the script. The scripts runs in the context of browsertime, so you need to pass it on in that context.
|
||||
|
||||
For example: you wanna pass on a password to your script, you can do that by adding <code>--browsertime.my.password MY_PASSWORD</code> and then in your code get hold of that with:
|
||||
|
||||
~~~javascript
|
||||
module.exports = async function(context, commands) {
|
||||
// We are in browsertime context so you can skip that from your options object
|
||||
context.log.info(context.options.my.password);
|
||||
}
|
||||
~~~
|
||||
|
||||
|
||||
## Commmands
|
||||
|
||||
All commands will return a promise and you should await it to fullfil. If some command do not work, we will log that automatically and rethrow the error, so you can catch that and can act on that.
|
||||
|
||||
### Measure
|
||||
The measure command will prepare everything for measuring a new URL (clearing internal metrics, starting the video etc). If you give an URL to the measure command it will start to measure and navigate to that URL.
|
||||
|
||||
If you do not give it a URL, it will prepare everything and start the video. So it's up to you to navigate/click on a link/submit the page. You also need to stop the measurement so that Browsertime/sitespeed.io knows that you want the metrics.
|
||||
|
||||
#### measure.start(url)
|
||||
Start and navigate to the URL and then automatically call the stop() function after the page has stopped navigating decided by the current pageCompleteCheck.
|
||||
|
||||
#### measure.start(url, alias)
|
||||
Start and navigate to the URL and then automatically call the stop() function after the page has stopped navigating decided by the current pageCompleteCheck. The page will also get the alias that will be used when you send the metrics to Graphite/InfluxDB. Use it when you have complex URLs.
|
||||
|
||||
#### measure.start()
|
||||
Start to measure. Browsertime/sitespeed.io will pick up the next URL and measure that. You need to call the stop() function yourself.
|
||||
|
||||
#### measure.start(alias)
|
||||
Start to measure. Browsertime/sitespeed.io will pick up the next URL and measure that. You need to call the stop() function yourself. The page will also get the alias that will be used when you send the metrics to Graphite/InfluxDB. Use it when you have complex URLs.
|
||||
|
||||
#### measure.stop()
|
||||
Stop measuring. This will collect technical metrics from the browser, stop the video recording, collect CPU data etc.
|
||||
|
||||
### Click
|
||||
The click command will click on links.
|
||||
|
||||
All click commands have two different versions: One that will return a promise when the link has been clicked and one that will return a promise that will be fullfilled when the link has been clicked and the browser navigated to the new URL and the pageCompleteCheck says ok.
|
||||
|
||||
If it do not find the link, it will throw an error, so make sure to catch if you want an alternative flow.
|
||||
{: .note .note-warning}
|
||||
|
||||
#### click.byName(name)
|
||||
Click on element that is found by name attribute that has the given value.
|
||||
|
||||
#### click.byNameAndWait(name)
|
||||
Click on element that is found by name attribute that has the given value and wait for the pageLoadCompoleteCheck to happen.
|
||||
|
||||
#### click.byClassName(className)
|
||||
Click on element that is found by specific class name.
|
||||
|
||||
#### click.byClassNameAndWait(className)
|
||||
Click on element that is found by specific class name and wait for page load complete check to finish.
|
||||
|
||||
#### click.byLinkText(text)
|
||||
Click on link whose visible text matches the given string.
|
||||
|
||||
#### click.byLinkTextAndWait(text)
|
||||
Click on link whose visible text matches the given string and wait for pageCompleteCheck to finish.
|
||||
|
||||
#### click.byPartialLinkText(text)
|
||||
Click on link whose visible text contains the given substring.
|
||||
|
||||
#### click.byPartialLinkTextAndWait(text)
|
||||
Click on link whose visible text contains the given substring and wait for pageCompleteCheck to finish.
|
||||
|
||||
#### click.byXpath(xpath)
|
||||
Click on link that matches a XPath selector.
|
||||
|
||||
#### click.byXpathAndWait(xpath)
|
||||
Click on link that matches a XPath selector and wait for page load complete check to finish.
|
||||
|
||||
#### click.byJs(js)
|
||||
Click on a link located by evaluating a JavaScript expression. The result of this expression must be an element or list of elements.
|
||||
|
||||
#### click.byJsAndWait(js)
|
||||
Click on a link located by evaluating a JavaScript expression. The result of this expression must be an element or list of elements. And wait for page complete check to finish.
|
||||
|
||||
#### click.byId(id)
|
||||
Click on link located by the ID attribute. This locator uses the CSS selector *[id="$ID"], not document.getElementById.
|
||||
|
||||
#### click.byIdAndWait(id)
|
||||
Click on link located by the ID attribute. This locator uses the CSS selector *[id="$ID"], not document.getElementById. And wait for page complete check to finish.
|
||||
|
||||
### Wait
|
||||
There are two help commands that makes it easier to wait. Either you can wait on a specific id to appear or for x amount of milliseconds.
|
||||
#### wait.byTime(ms)
|
||||
Wait for x ms.
|
||||
|
||||
#### wait.byId(id,maxTime)
|
||||
Wait for an element with id to appear before maxTime. If the elemet do not appear within maxTime an error will be thrown.
|
||||
|
||||
#### byXpath(xpath, maxTime) {
|
||||
Wait for an element founmd by xpath to appear beforeYo maxTime. If the elemet do not appear within maxTime an error will be thrown.
|
||||
|
||||
### Run JavaScript
|
||||
You can run your own JavaScript in the browser from your script.
|
||||
|
||||
#### js.run(javascript)
|
||||
Run JavaScript. Will throw an error if the JavaScript fails.
|
||||
|
||||
#### js.runAsync(javascript)
|
||||
Run async JavaScript. Will throw an error if the JavaScript fails.
|
||||
|
||||
### Navigate
|
||||
Navigate/go to a URL without measuring it.
|
||||
|
||||
#### navigate(url)
|
||||
Navigate to a URL and do not measure it. It will use the default pageCompleteCheck.
|
||||
|
||||
### Add text
|
||||
You can add text to input elements.
|
||||
|
||||
#### addText.byId(text, id)
|
||||
Add the *text* to the element with the *id*. If the id is not found the command will throw an error.
|
||||
|
||||
#### byXpath(text, xpath)
|
||||
Add the *text* to the element by using *xpath*. If the xpath is not found the command will throw an error.
|
||||
|
||||
### Switch
|
||||
You can switch to iframes or windows if that is needed.
|
||||
|
||||
If frame/window is not found, an error will be thrown.
|
||||
{: .note .note-warning}
|
||||
|
||||
#### toFrame(id)
|
||||
Switch to a frame by its id.
|
||||
|
||||
#### toWindow(name)
|
||||
Switch to window by name.
|
||||
|
||||
#### toParentFrame
|
||||
Switch to the parent frame.
|
||||
|
||||
### Use Selenium directly
|
||||
You can use Selenium directly if you need to use things that are not availible through our commands.
|
||||
|
||||
You get hold of the Selenium objects through the context.
|
||||
The *selenium.webdriver* that is the Selenium [WebDriver public API object](https://seleniumhq.github.io/selenium/docs/api/javascript/module/selenium-webdriver/index.html). And *selenium.driver* that's the [instantiated version of the WebDriver](https://seleniumhq.github.io/selenium/docs/api/javascript/module/selenium-webdriver/index_exports_WebDriver.html) driving the current version of the browser.
|
||||
|
||||
Checkout this example to see how you can use them.
|
||||
|
||||
~~~javascript
|
||||
module.exports = async function(context, commands) {
|
||||
// we fetch the selenium webdriver from context
|
||||
const webdriver = context.selenium.webdriver;
|
||||
const driver = context.selenium.driver;
|
||||
// before you start, make your username and password
|
||||
const userName = 'YOUR_USERNAME_HERE';
|
||||
const password = 'YOUR_PASSWORD_HERE';
|
||||
const loginForm = driver.findElement(webdriver.By.css('form'));
|
||||
const loginInput = driver.findElement(webdriver.By.id('wpName1'));
|
||||
loginInput.sendKeys(userName);
|
||||
const passwordInput = driver.findElement(webdriver.By.id('wpPassword1'));
|
||||
passwordInput.sendKeys(password);
|
||||
// this example skips waiting for the next page and validating that the login was successful.
|
||||
return loginForm.submit();
|
||||
}
|
||||
~~~
|
||||
|
||||
If you need help with Selenium, checkout [the official Selenium documentation](https://www.seleniumhq.org/docs/).
|
||||
|
|
@ -0,0 +1,72 @@
|
|||
---
|
||||
layout: default
|
||||
title: Test a single page application - SPA
|
||||
description: Instructions on how to use scripting to test your Single Page Application.
|
||||
keywords: selenium, web performance, sitespeed.io
|
||||
nav: documentation
|
||||
category: sitespeed.io
|
||||
image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png
|
||||
twitterdescription: Test a single page application - SPA
|
||||
---
|
||||
[Documentation]({{site.baseurl}}/documentation/sitespeed.io/) / Single page applicatiom
|
||||
|
||||
# Test a single page application
|
||||
{:.no_toc}
|
||||
|
||||
* Lets place the TOC here
|
||||
{:toc}
|
||||
|
||||
# Test by scripting
|
||||
To test a single page application you probably want to measure more pages than the first page (that loads the framework). Add you do that by using the Browsertime command/scripting. Either you use our commands or Selenium scripts.
|
||||
|
||||
When you test a single page application you should add the ```--spa``` parameter to your test pages, so that Browsertime/sitespeed.io knows. That will enable:
|
||||
* Automatically handle URLs with #.
|
||||
* End testing your page load after X seconds of no activity in the Resource Timing API. This makes sure that when you navigate to different pages, the navigation ends when everything finished loading.
|
||||
|
||||
|
||||
## Metrics
|
||||
Using a single page application make it harder to measure how fast a page load since since the navigation timing API will not work. Instead you can use the User Toming API and pick up visual metrics and metrics from the CPU.
|
||||
|
||||
### Navigation timing metrics
|
||||
The navigation timing metrics are only useful for the first page that you test. The following pages in your SPA will not populate new navigation timing metrics.
|
||||
|
||||
### Visual Metrics
|
||||
Visual Metrics will work fine but depending on how you navigate *First Visual Change* can be when you click your link, so focus on *Last Visual Change* instead.
|
||||
|
||||
### User Timing
|
||||
You need to instrument your code yourself or use a framework that do that automatically. [Read how LinkedIn](https://engineering.linkedin.com/blog/2017/02/measuring-and-optimizing-performance-of-single-page-applications) use User Timings to measure their SPA.
|
||||
|
||||
### CPU metrics
|
||||
If you run your tests with Chrome and enables ```--chrome.timeline``` you will also get metrics where Chrome spends it times rendering and executing JavaScript.
|
||||
|
||||
## Example: Performance test Grafana
|
||||
In this example we navigate and measure the start page of our Grafana installation, and then measure clicking the link to see the data for the last thirty days.
|
||||
|
||||
Lets create a script file and call it *thirtydays.js*.
|
||||
|
||||
~~~javascript
|
||||
module.exports = async function(context, commands) {
|
||||
await commands.measure.start('https://dashboard.sitespeed.io/d/000000044/page-timing-metrics?orgId=1');
|
||||
try {
|
||||
await commands.click.byClassName('gf-timepicker-nav-btn');
|
||||
await commands.wait.byTime(1000);
|
||||
// We give the paghe an alias that will be used if the metrics is sent to Graphite/InfluxDB
|
||||
await commands.measure.start('pageTimingMetricsLast30Days');
|
||||
await commands.click.byLinkTextAndWait('Last 30 days');
|
||||
await commands.measure.stop();
|
||||
} catch (e) {
|
||||
// If the GUI change and a link is not there,
|
||||
// the click commands will throw an error.
|
||||
// sitespeed.io will catch, log and rethrow
|
||||
// and you can choose if you want to have a different
|
||||
// user flow
|
||||
}
|
||||
};
|
||||
~~~
|
||||
|
||||
And then you run it by passing on the script file, using ```--spa``` to notify that you are testing a single page application and ```--multi``` that you test multiple pages withing one run.
|
||||
|
||||
~~~bash
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} thirtydays.js --spa --multi
|
||||
~~~
|
||||
|
||||
|
|
@ -1,11 +1,11 @@
|
|||
---
|
||||
layout: default
|
||||
title: Upgrade from sitespeed.io 5.x to 6.x
|
||||
description: This guide helps you upgrade from sitespeed.io 5.x to 6.0
|
||||
title: Upgrade from sitespeed.io 7.x to 8.0
|
||||
description: This guide helps you upgrade from sitespeed.io 7.x to 8.0
|
||||
keywords: upgrading, documentation, web performance, sitespeed.io
|
||||
nav: documentation
|
||||
image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png
|
||||
twitterdescription: Upgrade 5 -> 6
|
||||
twitterdescription: Upgrade 7 -> 8
|
||||
---
|
||||
[Documentation]({{site.baseurl}}/documentation/sitespeed.io/) / Upgrade
|
||||
|
||||
|
|
@ -15,72 +15,5 @@ twitterdescription: Upgrade 5 -> 6
|
|||
* Lets place the TOC here
|
||||
{:toc}
|
||||
|
||||
Upgrading to 6.x from 5.x? There are a couple of important things that have changed that you should read before you do the switch.
|
||||
Upgrading to 8.0 from 7.x? There are a couple of important things that have changed that you should read before you do the switch.
|
||||
|
||||
## Regular user
|
||||
As a regular user there are a couple of changes you need to know about. Nothing will break there's a few configuration changes you should do.
|
||||
|
||||
### Default 30 fps for the video
|
||||
In older versions the default frames per second for the video was 60. On cloud services that could be too much, introducing unstable metrics. If you still want to use 60fps you can do that by adding ```--videoParams.framerate 60``` to your run.
|
||||
|
||||
Do a test run with 30fps and check what happens to your Visual Metrics.
|
||||
|
||||
### Graphite users
|
||||
We have switched to Graphite 1.x by default (from Graphite 0.x). When Graphite moved to 1.0 they changed how annotations is handled. If you use 0.x version you and send annotations through sitespeed.io you need to add ```--graphite.arrayTags false``` to make it continue to work as before.
|
||||
|
||||
### Video and Speed Index default in the Docker containers
|
||||
In the new version we have video and Speed Index turned on by default when you run in our Docker containers. If you want to turn them off add ```--video false``` and ```--speedIndex false``` to your run.
|
||||
|
||||
### npm/yarn
|
||||
If you don't use our Docker containers (you should!) and install via npm/yarn, we know use latest LTS of NodeJS 8.9.1 (so you should upgrade your NodeJS version too).
|
||||
|
||||
### Assets timings with more in details info
|
||||
For 99.9% of the users this will not change anything but if you are sending assets timings to Graphite/InfluxDB (as we told you **not** to do) we changed so instead of getting the total time you now get: blocked, dns, connect, send, wait and receive timings [#1693](https://github.com/sitespeedio/sitespeed.io/pull/1693).
|
||||
|
||||
### GPSI users
|
||||
We have moved the GPSI outside of sitespeed.io and you can find it [here](https://github.com/sitespeedio/plugin-gpsi). To run in along with sitespeed.io you just follow [the instructions how to add a plugin](https://www.sitespeed.io/documentation/sitespeed.io/plugins/#add-a-plugin). We moved it outside of sitespeed.io to make the code base cleaner and with the hope that we can find a maintainer who can give it more love.
|
||||
|
||||
## Plugin makers
|
||||
We have made some changes to plugins to make it possible for plugins to generate HTML and to talk to each other before sitespeed.io starts to test URLs.
|
||||
|
||||
### No more hooks, say hello to new messages on the queue
|
||||
|
||||
In 5.X we relied on hooks for plugins, but we remove them and changed to use messages.
|
||||
|
||||
In 6.x your plugin should have an *open* function (called on startup), *processMessage* (getting all messages that are passed around in the queue) and *close* (optional).
|
||||
|
||||
We now have three messages sent by the queue:
|
||||
|
||||
- **sitespeedio.setup** - The first message on the queue. A plugin can pickup this message and communicate with other plugins (send pugs to the HTML plugin, send JavaScript to Browsertime etc).
|
||||
- **sitespeedio.summarize** (old message **summarize**) that tells the plugins that all URLs are analysed and you can now summarise the metrics.
|
||||
- **sitespeedio.render** which tells the plugins to render content to disk. The HTML plugin pickup **sitespeedio.render**, render the HTML and then sends a **html.finished** message, that then other plugins can pickup.
|
||||
|
||||
We changed name of the old message **summarize** to **sitespeedio.summarize**.
|
||||
|
||||
This means you need to remove your hooks and act on the messages instead.
|
||||
|
||||
You can check out the changes in [#1732](https://github.com/sitespeedio/sitespeed.io/pull/1732) [#1758](https://github.com/sitespeedio/sitespeed.io/pull/1758).
|
||||
|
||||
|
||||
### No generic Datacollector
|
||||
One of the bad design in the old 5.x code was the [DataCollector](https://github.com/sitespeedio/sitespeed.io/blob/5.x/lib/plugins/datacollector/index.js) (generic collector of data). We removed that now and that means each and every plugin needs to collect the data it needs themselves.
|
||||
|
||||
You can checkout how we do in the [HTML plugin](https://github.com/sitespeedio/sitespeed.io/blob/master/lib/plugins/html/index.js) and the [Slack plugin](https://github.com/sitespeedio/sitespeed.io/blob/master/lib/plugins/slack/index.js).
|
||||
|
||||
The easiest (but a little ugly) way to migrate is to move the old [DataCollector code](https://github.com/sitespeedio/sitespeed.io/blob/5.x/lib/plugins/datacollector/index.js)) to your own plugin. The better way is to cherry pick the metrics/data that your plugin needs.
|
||||
|
||||
You can see the changes we did in
|
||||
[#1731](https://github.com/sitespeedio/sitespeed.io/pull/1731) and [#1767](https://github.com/sitespeedio/sitespeed.io/pull/1767).
|
||||
|
||||
|
||||
### StorageManager API changes
|
||||
|
||||
Several parts of the [StorageManager](https://github.com/sitespeedio/sitespeed.io/blob/master/lib/core/resultsStorage/storageManager.js) API have been updated to fit better together. The following changes may break code written using the 5.x API:
|
||||
|
||||
- `createDataDir(directoryName)` is now `createDirectory(...directoryNames)` and takes any number of directory names (which will be joined together) as arguments.
|
||||
- `writeData(filename, data)` has reversed the order of its arguments. It is now `writeData(data, filename)`.
|
||||
- `writeHtml(filename, html)` has reversed the order of its arguments. It is now `writeHtml(html, filename)`.
|
||||
- `writeDataForUrl(data, filename, url, subDir)` no longer has a fifth argument indicating whether output should be gzipped.
|
||||
- `writeHtmlForUrl(html, filename, url)` no longer has a fourth argument indicating whether output should be gzipped.
|
||||
|
||||
Note that all compression functionality has been removed. If you need compressed output, your plugin should handle gzipping itself. See the [`harstorer` plugin](https://github.com/sitespeedio/sitespeed.io/blob/56bfc48bac7ccfe1cfe35c829b4dd11987a375e4/lib/plugins/harstorer/index.js#L19-L28) for an example.
|
||||
|
|
|
|||
|
|
@ -51,8 +51,8 @@ You need to give Docker access to the network with `--cap-add=NET_ADMIN` so that
|
|||
|
||||
To run a simple test:
|
||||
|
||||
```
|
||||
docker run --cap-add=NET_ADMIN --shm-size=1g --rm -v "$(pwd)":/sitespeed.io -e REPLAY=true -e LATENCY=100 sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} -n 5 -b chrome https://en.wikipedia.org/wiki/Barack_Obama
|
||||
```bash
|
||||
docker run --cap-add=NET_ADMIN --rm -v "$(pwd)":/sitespeed.io -e REPLAY=true -e LATENCY=100 sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} -n 5 -b chrome https://en.wikipedia.org/wiki/Barack_Obama
|
||||
```
|
||||
|
||||
Remember to verify the HAR files produced so that it looks like it should: Verify that WebPageReplay replays your website correct. If it does, then use it :)
|
||||
|
|
@ -63,13 +63,13 @@ Using WebPageReplay in Docker and your Android phone only works on Linux. This i
|
|||
|
||||
Using sitespeed.io:
|
||||
|
||||
```
|
||||
```bash
|
||||
docker run --privileged -v /dev/bus/usb:/dev/bus/usb -e START_ADB_SERVER=true --cap-add=NET_ADMIN --shm-size=1g --rm -v "$(pwd)":/sitespeed.io -e REPLAY=true -e LATENCY=100 sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} https://en.m.wikipedia.org/wiki/Barack_Obama --browsertime.chrome.android.package com.android.chrome --browsertime.xvfb false --browsertime.chrome.args ignore-certificate-errors-spki-list=PhrPvGIaAMmd29hj8BCZOq096yj7uMpRNHpn5PDxI6I= --browsertime.chrome.args user-data-dir=/data/tmp/chrome -n 11
|
||||
```
|
||||
|
||||
Using Browsertime:
|
||||
|
||||
```
|
||||
```bash
|
||||
docker run --privileged -v /dev/bus/usb:/dev/bus/usb -e START_ADB_SERVER=true --cap-add=NET_ADMIN --shm-size=1g --rm -v "$(pwd)":/browsertime -e REPLAY=true -e LATENCY=100 sitespeedio/browsertime:{% include version/browsertime.txt %} https://en.m.wikipedia.org/wiki/Barack_Obama --chrome.android.package com.android.chrome --xvfb false --chrome.args ignore-certificate-errors-spki-list=PhrPvGIaAMmd29hj8BCZOq096yj7uMpRNHpn5PDxI6I= --chrome.args user-data-dir=/data/tmp/chrome -n 11
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -47,14 +47,14 @@ If you need anything else adding your own CLI parameter will propagate to the We
|
|||
Example: So say that you want to change the user agent of your test. In the API you can do that with <code>--useragent</code>. Pass the same to sitespeed.io by prefixing webpagetest like so <code>--webpagetest.useragent</code> in the cli.
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io --webpagetest.host my.wpt.host.com --webpagetest.useragent "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.59 Safari/537.36" https://www.sitespeed.io
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io --webpagetest.host my.wpt.host.com --webpagetest.useragent "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.59 Safari/537.36" https://www.sitespeed.io
|
||||
~~~
|
||||
|
||||
## Default configurations
|
||||
|
||||
The default configuration for WebPageTest looks like this:
|
||||
|
||||
~~~
|
||||
~~~json
|
||||
{
|
||||
pollResults: 10,
|
||||
timeout: 600,
|
||||
|
|
@ -75,7 +75,7 @@ WebPageTest has scripting capability where you can easily automate a multi-step
|
|||
|
||||
You can create your script file (checkout [WebPageTest documentation](https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/scripting) for what you can do). It can look something like this (wptScript.txt):
|
||||
|
||||
~~~
|
||||
~~~shell
|
||||
logData 0
|
||||
|
||||
// put any urls you want to navigate
|
||||
|
|
@ -91,7 +91,7 @@ navigate news.aol.com/world
|
|||
Then change your URL you want test (probably the last one) to \{\{\{URL\}\}\} and then all occurrences of \{\{\{URL\}\}\} will then be replaced with the current URL that should be tested. Now run sitespeed.io with the additional parameters:
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io --webpagetest.file /sitespeed.io/wptScript.txt --webpagetest.host my.wpt.host.com http://example.org
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} --webpagetest.file /sitespeed.io/wptScript.txt --webpagetest.host my.wpt.host.com http://example.org
|
||||
~~~
|
||||
|
||||
It is also possible to pass the WebPageTest script as a string into the `--webpagetest.script` flag. You can use the `scriptToString()` method provided in [webpagetest-api](https://github.com/marcelduran/webpagetest-api/#module-1) to create a string from a JSON object.
|
||||
|
|
@ -99,14 +99,14 @@ It is also possible to pass the WebPageTest script as a string into the `--webpa
|
|||
{% assign bashURLString = '{{{URL}}}}' %}
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io --webpagetest.script "navigate \t www.aol.com \n navigate \t {{bashURLString}}" --webpagetest.host my.wpt.host.com http://example.org
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} --webpagetest.script "navigate \t www.aol.com \n navigate \t {{bashURLString}}" --webpagetest.host my.wpt.host.com http://example.org
|
||||
~~~
|
||||
|
||||
### Custom metrics
|
||||
|
||||
Hey we love custom metrics and you can fetch them using WPT. Checkout the [metrics docs](https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/custom-metrics) for WPT and then create a file containing your metrics:
|
||||
|
||||
~~~
|
||||
~~~shell
|
||||
[iframe-count]
|
||||
return document.getElementsByTagName("iframe").length;
|
||||
|
||||
|
|
@ -128,7 +128,7 @@ return viewport;
|
|||
You can then run sitespeed.io to pick up the new custom metrics:
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io --webpagetest.custom /sitespeed.io/myScriptFile.txt --webpagetest.host my.wpt.host.com https://www.sitespeed.io
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} --webpagetest.custom /sitespeed.io/myScriptFile.txt --webpagetest.host my.wpt.host.com https://www.sitespeed.io
|
||||
~~~
|
||||
|
||||
## Run WebPageTest without Browsertime
|
||||
|
|
@ -136,12 +136,5 @@ docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io
|
|||
Sometimes you want to only collect data from WebPageTest and not from Browsertime. The best way to do that is to disable the Browsertime plugin with *--plugins.remove browsertime*
|
||||
|
||||
~~~bash
|
||||
docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io --webpagetest.host my.wpt.host.com --plugins.remove browsertime https://www.sitespeed.io
|
||||
docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:{% include version/sitespeed.io.txt %} --webpagetest.host my.wpt.host.com --plugins.remove browsertime https://www.sitespeed.io
|
||||
~~~
|
||||
|
||||
## Advanced dashboards
|
||||
|
||||
If you use the grafana dashboards, you will notice that by default some of them can be empty. You must set to true two options
|
||||
|
||||
* `webpagetest.timeline` : It activates chrome tracing, if you're running chrome. It contains super useful metrics like the Navigation Timing API and chrome specific metrics like FirstMeaningfulPaint.
|
||||
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ docker run --shm-size=1g --rm -v "$(pwd)":/browsertime sitespeedio/browsertime:{
|
|||
|
||||
It will generate a HAR file, a video and a browsertime.json that hold all the metrics.
|
||||
|
||||
~~~
|
||||
~~~json
|
||||
{
|
||||
"info": {
|
||||
"browsertime": {
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 152 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 86 KiB |
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
Loading…
Reference in New Issue