Page summary

Summary

Metric	Value
Page metrics
Performance Score	98
Total Page Transfer Size	155.7 KB
Requests	11
Timing metrics
TTFB [median]	83 ms
First Paint [median]	190 ms
Fully Loaded [median]	354 ms
Google Web Vitals
TTFB [median]	83 ms
First Contentful Paint (FCP) [median]	190 ms
Largest Contentful Paint (LCP) [median]	382 ms
Cumulative Layout Shift (CLS) [median]	0.00
Total Blocking Time [median]	18 ms
Max Potential FID [median]	68 ms
CPU metrics
CPU long tasks [median]	1
CPU longest task duration	79 ms
CPU last long task happens at	257 ms
Visual Metrics
First Visual Change [median]	233 ms
Speed Index [median]	274 ms
Visual Complete 85% [median]	400 ms
Visual Complete 99% [median]	400 ms
Last Visual Change [median]	400 ms

Timings Summary

Waterfall

Run 2 SpeedIndex median

Video

Filmstrip

Use--filmstrip.showAll to show all filmstrips.

0 s

0.2 sFirst Contentful Paint 190 msuserTimingHeader 194 ms

0.3 suserTimingFooter 214 msDOM Content Loaded Time 228 msPage Load Time 230 msFirst Visual Change 233 msLayout Shift 0.00037 272 msFully Loaded 292 ms

0.4 sLCP <IMG> 364 msLast Visual Change 367 msVisual Complete 85% 367 msVisual Complete 95% 367 msVisual Complete 99% 367 ms

Coach

The coach helps you find performance problems on your web page using web performance best practice rules. And gives you advice on privacy and best practices.

Coach score

• Total score 99
• Performance score 98
• Privacy score 100
• Best practice score 100

Performance advice (98)

Show/hide details

Title	Advice	Score
Don't scale images in the browser (avoidScalingImages)	The page has 4 images that are scaled more than 100 pixels. It would be better if those images are sent so the browser don't need to scale them.	60
Description: It's easy to scale images in the browser and make sure they look good in different devices, however that is bad for performance! Scaling images in the browser takes extra CPU time and will hurt performance on mobile. And the user will download extra kilobytes (sometimes megabytes) of data that could be avoided. Don't do that, make sure you create multiple version of the same image server-side and serve the appropriate one.
Offenders: https://www.sitespeed.io/img/sitespeed-logo-2c.png https://www.sitespeed.io/img/pippi.png https://www.sitespeed.io/img/dashboard-front.png https://www.sitespeed.io/img/public.png
Inline CSS for faster first render (inlineCss)	The page has both inline CSS and CSS requests even though it uses a HTTP/2-ish connection. If you have many users on slow connections, it can be better to only inline the CSS. Run your own tests and check the waterfall graph to see what happens.	95
Description: In the early days of the Internet, inlining CSS was one of the ugliest things you can do. That has changed if you want your page to start rendering fast for your user. Always inline the critical CSS when you use HTTP/1 and HTTP/2 (avoid doing CSS requests that block rendering) and lazy load and cache the rest of the CSS. It is a little more complicated when using HTTP/2. Does your server support HTTP push? Then maybe that can help. Do you have a lot of users on a slow connection and are serving large chunks of HTML? Then it could be better to use the inline technique, becasue some servers always prioritize HTML content over CSS so the user needs to download the HTML first, before the CSS is downloaded.
Have a fast largest contentful paint (largestContentfulPaint)	You can add importance="high" to the image to increase the load priority that is rolling out soon in Chrome.	95
Description: Largest contentful paint is one of Google Web Vitals and reports the render time of the largest image or text block visible within the viewport, relative to when the page first started loading. To be fast according to Google, it needs to render before 2.5 seconds and results over 4 seconds is poor performance.
Avoid CPU Long Tasks (longTasks)	The page has 1 CPU long task with the total of 79 ms. The total blocking time is 29 ms . However the CPU Long Task is depending on the computer/phones actual CPU speed, so you should measure this on the same type of the device that your user is using. Use Geckoprofiler for Firefox or Chromes tracelog to debug your long tasks.	80
Description: Long CPU tasks locks the thread. To the user this is commonly visible as a "locked up" page where the browser is unable to respond to user input; this is a major source of bad user experience on the web today. However the CPU Long Task is depending on the computer/phones actual CPU speed, so you should measure this on the same type of the device that your user is using. To debug you should use the Chrome timeline log and drag/drop it into devtools or use Firefox Geckoprofiler.
Offenders: self

Best practice advice (100)

Your best practice score is perfect!

Privacy advice (100)

Your privacy score is perfect!

Page info

Page info
Title	Welcome to the wonderful world of Web Performance
Width	1350
Height	4022
DOM elements	370
Avg DOM depth	8
Max DOM depth	13
Iframes	0
Script tags	4
Local storage	0 b
Session storage	0 b
HTML vs AMP	Plain good HTML page

Technologies used to build the page.

Data collected using Wappalyzer.  Use --browsertime.firefox.includeResponseBodies htmlor --browsertime.chrome.includeResponseBodies htmlto help Wappalyser find more information about technologies used.

Technology	Confidence	Category
Netlify	100	PaaS CDN
Clipboard.js 2.0.4	100	Miscellaneous

Data from run 2

Visual Metrics

Browser Metrics

Largest Contentful Paint

When in time the page main content is rendered (collected using the Largest Contentful Paint API). Read more about Largest Contentful Paint.

Element type	IMG
Element/tag	<img src="/img/team.png" alt="sitespeed.io Logo with My Little Pony style cats" elementtiming="logo">
Render time	364 ms
Load time	229 ms
URL	https://www.sitespeed.io/img/team1px.png
Size (width*height)	216500
DOM path
main > div:eq(0) > div > div:eq(0) > picture > img> main > div:eq(0) > div > div:eq(0) > picture > img>

The largest contentful paint is highlighted in the image. If no element is highlighted the element was removed before the screenshot or the LCP API couldn't find the element.

The Largest Contentful Paint API highlighted this image as a part of the LCP.

Detected Cumulative Layout Shift

0.00037 cumulative layout shift collected from the Cumulative Layout Shift API.

These HTML elements contribute most to the Cumulative Layout Shifts of the page. The higher score, the more layout shift.

Score	HTML Element
0.00037	<div class="grid"></div>
body > nav > div > div

The elements that have shifted place is highlighted in the image (that have a higher value than 0.01). If the element shifted outside of the viewport, you will not see it there. It can be hard to understand what content that has shifted, if that's the case, checkout the video or the filmstrip of the run.

Element timings

Id	URL	Image	Tag	Render time	Load time	Natural width	Natural height
header-logo	https://www.sitespeed.io/img/sitespeed-logo-2c.png		IMG	190 ms	161 ms	324	100
logo	https://www.sitespeed.io/img/team1px.png		IMG	364 ms	229 ms	500	433

Server timings

There are no Server Timings.

Custom metrics collected through JavaScript

There are no custom configured scripts.

Extra metrics collected using scripting

There are no custom extra metrics from scripting.

CDP Performance

PageXray

How the page is built.

Largest assets on the page (by transfer size)

Requests and sizes per content type

Data per domain

Expires and last modified statistics

Requests loaded after onLoad event

Requests loaded after onContentLoad

Includes requests done after onLoad.

Render blocking requests

Render blocking information directly from Chrome.

Render information

Third party

Third party requests categorised by Third party web.

First party requests and sizes per content type

Calculated using .*sitespeed.* (use --firstParty to configure).

Third party requests and sizes per content type