Previously new uncached requests for Open graph share-card images were generated in Chrome, sometimes taking up to 5 seconds to generate. (They were then stored in cache for 12 hrs).
Because we're now using Satori powered og images, they render almost immediately and we don't have to own the problem of having Chrome deployed within the 50mb lambda limitation. I'm pretty happy about that.
We're currently using Heroku for app hosting, while evaluating fly.io, render.com and railway.app. All three have had exceptional reviews from other customers and differ slightly on their service offerings and setups. All seem like viable alternatives so far!
I've left significant levels of details about pagespeed on the lighthouse issue tracker over the last few months. It's really frustrating to see the lighthouse team being blamed for something that isn't operationally even theirs… but that's a big company for you.
The biggest contributing factor to unstable pagespeed scores is the power of the machines that do the tests. Last time I checked the scores / bench mark scores for pagespeed were all over the place. … All the same, it's really important to understand how it all works. Hopefully the post had something for you?
… but to answer your question better. It sucks that Google's own services don't live up to the performance expectations of tools made in other parts of Google.
Lighthouse definitely has some improvements to make for the audit suggestions that offer advice to improve the score. I think people get a little bit frustrated/blinded by the advice when there's nothing that can be done about third parties (I know I do!).
Our product Calibre (mentioned in the bottom of the post) has a n adblocking/third party blocking feature that allows you to compare your pages with or without third party scripts gunking up performance metrics (here's the release post: https://calibreapp.com/blog/release-notes-apr-2019/).
We've seen really good success in separating the two because it sends a clear signal of what a site WOULD score without ads. This is good because it makes it clear to PMs, management and decision makers that tracking tools incur a really visible cost.
The App itself is boring old rails, with postgres (get me started on how much I like postgres and I will literally bore you to tears.) The original views were all haml and sass delivered via the asset pipeline. I sprinkled in angular here or there as the application grew.
Today, I'm slowly tearing away the angular. I've moved to webpack for JavaScript, and React for all new UIs. I've been really enjoying both the speed of development, and how solid everything feels.
Over time, I'm writing less and less ActiveRecord, and more and more sequel… still learning, but getting better.
The app is run on Heroku, and its been A++ would recommend to everyone.
The Calibre agent is node and websockets talking to Chrome®, theres other bits of ruby, and even some golang now.
I use terraform and ansible (although, the ansible may as well have been bash scripts) through a buildkite (https://buildkite.com — the best fucking CI service on the planet) pipeline. AMIs are built, shipped to different regions, then based on some config are rolled out.
Papertrail for logs - omg, logging! Essential. I run thousands of tests per day (I don't know this number off the top of my head, but its a lot)… and the nature of the internet is THERE IS ALWAYS FAILURE. Having logging at my fingertips has always made my job building Calibre easier. I think I pay $20 per month right now, and its the most important thing I pay for.
--
Ok. Whew. Could probably keep going, but I'm not sure how much you wanna know. Happy to answer specific things though!
I do everything. No contractors. Although @fox has been recently helping me with my writing (her native language is Polish, and she writes waayyy better than me - and most others).
Web page test is a succhhh a great tool, and its really great for one off tests. Calibre will automatically hit your site daily (or, when you ping the snapshot api), and you'll have a full history of what happened and when.
With Calibre the aim is to make it a part of your toolchain (read: integrations) — so it should be visible to your entire team, or build system, or slack channel.
Without being super familiar with the tech that any of these companies are running —
The biggest thing that sets Calibre apart is that its entirely built using the Chrome developer tools APIs. I like to think about it as someone on your team who opened devtools after every deploy, and kept a neat spreadsheet of all the changes that had occurred. In short, all the data is ready and available for the taking.
This also has the added benefit that I have the power of the Chrome browser to play with. Projects like Google's Lighthouse (https://developers.google.com/web/tools/lighthouse/ — Which I'm currently integrating into Calibre!) have meant that a lot more powerful tools/metrics/resources/etc are coming along strongly, and this will only help make Calibre more powerful too.
Calibre is firmly focused on what your users actually experience, and helping you get to the bottom of 'why' quickly and efficiently. So while technically focused tools are imperative for any team, many of them aren't focused on the most important people in the equation.
Yeah… that animation isn't what it should be for a performance product—luckily, after this (and the lighthouse integration I'm working on right now), I'll have all-new marketing too!
Hi HN! I'm Ben, the solo founder of Calibre Analytics: https://calibreapp.com. Calibre monitors websites and applications in a clean-room testing environment from all over the world. Up until January Calibre has been an "inbetween other things" / evenings / holidays kind of project. (Only, oops—I did that for four years.).
Last year I knuckled down to get into the position where I could work on it full time. I've spent the last 8 weeks working on "Test profiles" (The launch post is here: https://medium.com/get-calibre/announcing-test-profiles-and-...) — It allows you to emulate hardware devices (cpu speed, user-agents and screen dimensions), as well as limit the bandwidth (latency, download and upload speeds), and set cookies (you could use this to log into your app, test a staff-shipped feature, or maybe turn off advertising and see the performance impact.)
I think I've finally got the basis of a really powerful tool, and I'm keen to share it with… everyone! I do everything myself, so if you've any questions, I'm here to answer them!
Right now, Firefox 29, Aurora and Nightly are the only browsers that have CSS Variables shipped. (Although, there is still no CSSOM implementation present — that'll come later.)
The idea kind of came along when I was extracting Gallery CSS from the project that I built it for — I realised that people probably wouldn't understand the library, or the need for it… but I didn't want the cool tech result to go unnoticed.
Originally it was going to be an ebook… if I'd have done that, it would've been released about 3 weeks ago, but the knowledge transfer is far more challenging VS a screencast.
Previously new uncached requests for Open graph share-card images were generated in Chrome, sometimes taking up to 5 seconds to generate. (They were then stored in cache for 12 hrs).
Because we're now using Satori powered og images, they render almost immediately and we don't have to own the problem of having Chrome deployed within the 50mb lambda limitation. I'm pretty happy about that.