You can’t manage what you can’t measure. As devices grow in capacity and innovations allow us to do more with web apps, the complexity of our pages has grown, too. It becomes a balancing act to increase functionality while maintaining a performant and responsive site. Just like a great recipe, too much of any one ingredient can throw it off.
What’s inside matters.
Page load time is a sum of its parts, and DOM complexity can strain rendering of pages on end-user devices. “As the number of elements — text, titles, images — on a page goes from 400 to 6,000, the probability of conversion drops 95%” (source: Google). Measuring the volume of HTTP requests can give you the ability to seek opportunities to reduce any requests that are unnecessary and drive greater efficiency.
To the same end, the ability to measure resource size by type provides actionable information to aid a critical understanding of how the relative size of various resource types could be optimized to reduce their impact on page load times.
As part of the Spring 2018 mPulse release, we’re adding page construction metrics to help you understand which elements in your page might be impacting your performance. For all of the different resource types — CSS, JS, IMAGE, HTML, FONT, BEACON, XHR, OTHER, TOTAL (sum of everything), and PAGE (just the root HTML page) — we will break down the following metrics:
Transfer Size – the total download size of the page, including headers, also known as aggregate transfer size. The smaller the download size, the faster your page will transfer and load. You can reduce your total transfer size by ensuring you don’t have any unnecessary resources and using compression techniques. Depending on the resource type — text, images, fonts, and so on — there are many different techniques to choose from: generic tools that can be enabled on the server, pre-processing optimizations for specific content types, and resource-specific optimizations that require input from the developer (source: Google).
Browser Cache/Hit Ratio – percentage of resources that were already in the browser’s cache. The more resources that are cached, the smaller your transfer size and faster your page will load.
Decoded Body Size – another indicator of the “weight” of the page, but includes the original size of resources that are compressed and/or cached, and does not include the headers.
Compression Ratio – percentage that tells you how much of your page is compressed. Your compression ratio is 100% when all resources are compressed. So if your compression ratio is less than 100%, you potentially have room to decrease your total transfer size! Compression ratio is found by comparing your encoded transfer size, or the total transfer size without the headers (not tracked by mPulse), to your decoded transfer size.
HTTP Request Count – lets you know the total requests that were necessary to render the page. Reducing the total # of requests improves performance and improves DOM complexity.
With the mPulse Spring 2018 release, you have the information to create the most performant web page recipe for your site!
To read more about measuring what matters and all the new capabilities in mPulse, check out these related posts:
- mPulse: Measure What Matters — New Metrics to Improve User Experiences
- Perception Matters — Measure Perceived Performance
- How You Get There Matters — Middle-mile Visibility to Drive CDN Strategy
*** This is a Security Bloggers Network syndicated blog from The Akamai Blog authored by Lauren Younger. Read the original post at: http://feedproxy.google.com/~r/TheAkamaiBlog/~3/8MHDLdd8aaY/whats-inside-matters-page-construction-metrics.html