Soasta on how they deal with real user monitoring in AngularJS:
First, we now listen for AngularJS routing events, such as $routeChangeStart. Once we see that the visitor is about to view new content, we start listening in preparation for gathering performance metrics for the soft navigation.
Second, and most importantly, when the page is first loading, and when a soft navigation starts, we begin monitoring the HTML document for any new downloadable resources that get inserted. We do this via a MutationObserver.
Real user monitoring techniques for single page apps are becoming a big deal, and don’t easily have a one size fits all solution.
MapLatency.com: global checks for ping, dns, page load, and HTTP GET.
Wondering what CSS properties trigger paint, layout, and composite? Then CSS Triggers is for you.
stats.js is a nifty little performance monitor:
This class provides a simple info box that will help you monitor your code performance.
– FPS Frames rendered in the last second. The higher the number the better.
– MS Milliseconds needed to render a frame. The lower the number the better.
– MB MBytes of allocated memory. (Run Chrome with –enable-precise-memory-info)
The FPS monitor looks like this:
A common data point I see brought in web performance discussions is a reference to a test Google ran to test the impact of slower search results on the number of searches a user performs. I found the original blog post at Speed Matters:
Our experiments demonstrate that slowing down the search results page by 100 to 400 milliseconds has a measurable impact on the number of searches per user of -0.2% to -0.6% (averaged over four or six weeks depending on the experiment).
The impact extends beyond the initial test period:
Users exposed to the 400 ms delay for six weeks did 0.21% fewer searches on average during the five week period after we stopped injecting the delay.
If you are going to reference this test and the corresponding data, please link back to original Google blog post. Hopefully that will save others the time of having to hunt down the original information.
This PHP 7 performance infographic ( something about the term infographic just doesn’t sit well with me ) has been making the rounds:
Take these exact data points with a sufficiently large grain of salt. My hope is that the performance increase puts PHP 7 in the same ball park as HHVM.
The Verizon / AOL deal has brought up an interesting data point: AOL still has 2.1 million dial customers ( page 4 in the PDF ).
Combined this with the number of Internet users in the United States ( ~279 million ) you get: ~1% of United States Internet users are on AOL dial up.
I ran www.google.com through WebPageTest, comparing Cable ( 5 Mbps down, 1Mbps up, 28ms RTT ) to 56k dialup ( 49Kbps down, 30Kbps up, 120ms RTT ). The result:
And google.com is fast compared to most sites, nearly every modern web site is going to be horribly painful on a dialup connection.