Earth Notes: On the MachMetrics Site Speed Monitoring Tools: Review
Updated 2024-03-09.MachMetrics was [archive] retired on 2021-06-30.
Product: MachMetrics Site Speed Monitoring Tools
- Brand: MachMetrics
- MPN: Free Plan
Review summary
- MachMetrics Site Speed Monitoring Tools
- Does what it says on the tin, effectively and reliably. Gathers metrics daily for me for two views of my site. Had a very quick initial payoff, helped me keep an eye on the results of various styling changes over a year, and may just have spotted a subtle creeping DNS issue. Nothing to fault at all!
- Rating: 5/5
- Published:
- Updated:
I use or have tried many site speed test tools with EOU, some of the best of which I list, such as: WebPageTest, PageSpeed Insights from Google, Pingdom Website Speed Test, and GTMetrix.
Signup
I saw MachMetrics, and being a cheapskate, signed up for the free plan, April 2018, with the maximum of 4 tests. I test the home pages of the desktop/www and lite/m-dot EOU sites, as desktop and mobile.
I had a good initial experience when MachMetrics helped me to very quickly see where some fat (~30% of page weight) needed trimming, hurrah!
The site is fast and responsive and easy to navigate.
Site: Online Reports
The site opens at login to the All Urls
dashboard view, with more detailed views for each URL monitored, "m" and "www" in my case.
Each of those has tabs for "Overview", "Resources", "Improve" and "Log". I mainly spend my time in the Overview, but Resources lets you see the (slowest) resources loaded to render the page by time and bytes, and Log lists all the timings and lets you click through to the underlying measurement platform (Web Page Performance Test, aka WebPageTest) for recent entries.
By default data is shown for the last 7 days, but a simple menu pull-down can set that to 30 or 90 days, or a full year. Simples!
(I'm writing this review while still just within the first year window. It would be nice to be able to for example download the first year's log data before it starts expiring, but I can't currently see how without scraping it, which I'd rather not.)
Currently full home page weight is reported on the dashboard as 28kB for m-dot and 67kB for desktop, with page display time a little over 0.5s for desktop and a little under for m-dot.
One of the nicer charts (though I wish that it was not suggesting an upward drift) is that of various metrics (for www and for m-dot) from TTFB to "page complete", over time. Lots of tools show them; this view is especially easy to absorb!
Various graphs and tables and summaries are shown; useful stuff, no fluff. Someone has thought hard about this. Well done.
Sample Weekly Email Reports
MachMetrics' sends simple, brief and to-the-point emails with the important bits in text. (And only a very little light marketing/sales messaging stirred in, be still my GDPR beating heart...)
There are embedded images, but I never see them since I have all such remote content in emails blocked to prevent tracking. (Having manually checked them for the most recent email, they look useful.)
From 2018-04-23:
Your 2 urls combined earn a GRADE A+. Their average speed of 0.49 s is in the 99th percentile of the 584 urls being tested. You are trending THE SAME compared to the previous week (0.45 s to 0.45 s).
From 2019-03-18:
Your 2 urls combined earn a GRADE A+. Their average speed of 0.56 s (last 30 days) is in the 100th percentile of all urls being tested. You are trending THE SAME compared to the previous week's average (0.55 s last week to 0.58 s this week).
TTFB Puzzler
I was provoked to start writing this piece because of a curious feature in one of the metrics reported, for both www and m-dot sites. The TTFB (Time To First Byte) is shown as rising from about July 2018. But why?
My HTML pages have been getting a little bigger as I have been adding a few more images and a bit more structured markup metadata to most of them. However, the files should be being served precompressed as binaries with no work to do up-front, so this should have no bearing.
The number of pages I'm hosting is going up slightly, so is directory search time going up when pages are being served? Seems unlikely.
Is an increasing volume of robotic break-in attempts by bad actors slowing things down? Seems unlikely, since they are sporadic, and there should be plenty of capacity.
Is my SD card wearing out and about to fail? I hope not!
Is MachMetrics' server (or network route to me) getting slower? Difficult to tell!
Is the stat being shown as TTFB actually TTLB (Time To Last Byte), or something else, especially as it seems to be higher than the 'interactive' metric in a few places!
MachMetrics lets you click through the logs to the Web Page (Performance) Test backend results pages, for which it seems to hold about 3 months' worth. The TTFB looks genuine. What may be going on, looking at data for mobile access to the m-dot site (2019-01-23 DNS Lookup: 30 ms Initial Connection: 62 ms Time to First Byte: 73 ms Content Download: 10 ms Bytes In (downloaded): 6.4 KB Uncompressed Size: 16.3 KB, vs 2019-03-24 DNS Lookup: 110 ms Initial Connection: 61 ms Time to First Byte: 70 ms Content Download: 9 ms Bytes In (downloaded): 6.4 KB Uncompressed Size: 16.4 KB) is that DNS resolution is getting slower, and that should be checked out!
If MachMetrics has spotted a real subtle creeping performance problem, then it will have demonstrated its worth.
Excerpts from MachMetrics Response
I received a swift (allowing for timezones) and very kind response from Shane at MachMetrics when I shared my review with them. Shane also gave me access to download those logs, which I gather I would not otherwise have access to on "free": thanks!
Wow, thanks so much for the review! I loved hearing your perspective and the screenshots really get your points across. Glad that you've found it so useful :) ...
In regards to your TTFB mystery, I can assure you that the testing agents are not getting slower ... [screenshot showing the opposite] ...
I wish I could spend time looking into this further with you and giving you some optimization suggests, but honestly you have such a killer fast speed already that there's very little to do to optimize. I see DNS lookups as fast as 30ms, which is great - and having a TTFB of below 200ms is pretty stellar. Be proud of this!!
...
Lastly, I saw your comment on the Time to Interactive being faster than TTFB in some cases, and I have to admit that looks wrong. I'm digging into this right now - my hunch is there's a bug collecting that stat from WebPageTest.
For his amusement I replied to point out that "this site (and others, plus mail server, repos etc) runs on an off-grid solar-powered Raspberry Pi in my kitchen cupboard. I don't always beat Cloudflare when serving content to UK customers, but I often do!"
A few days later Shane came back to me and said:
You were correct about the Time to Interactive being off. Sometimes WPT can't calculate it (probably if it's too fast!) and returns 0.
I've updated our system so it will exclude those 0 from averages and graphs. Your new yearly chart looks like this.
Interesting! I shall have to look out for that effect when using WPT directly.
Later
2019-06-22: TTFB creeping down
Reported TTFBs seem to be creeping down to/under 200ms without any significant action on my part, and seem to be quite variable anyway, which inclines me to think that the rise was a WPT artefact. The only intervention that may have made a difference is running by hand a few times weeks apart sudo fstrim --verbose /local or equivalent, and there was no immediate difference seen afterwards. Other tests, without simulated throttling, see TTFBs well under 200ms.
2019-08-31: TTFB back to 200ms
Reported TTFB seems to be back down to ~200ms now. And parameters other than 'Interactive' are better than a year ago. It's all a mystery...
2020-05-14: Bye-bye Frankfurt
I have moved the servers from which the tests are being run from Europe-Central (Frankfurt) to Europe-West (London), as more representative of typical EOU users.
2020-07-19: Chrome 84 speed-up
There seems to be a significant drop (~33%: from 2.1s to 1.4s) in time to (on-) load for mobile with the change from Chrome 83 to 84.
The load now seems to happen actually when the HTML and JS is loaded and run but no longer all the images. On load now seems to follow very closely behind DOM content loaded. This lets post-doc-load stuff happen sooner such as loading the social-media buttons and favicon, in parallel.
The drop in page complete time is less dramatic than doc/on load, at ~2.5s to ~2.1s, but is still welcome.