It looks like most of the guidance on Pagespeed for large images, and layout shift due to images. The guidance to fix is to set fixed images sizes for these elements, and to re-encode images into more efficient image formats, at their displayed size instead of their maximum source size. Potion probably doesn't currently know the correct width for an image because they give their users kind of unlimited style control to choose the image's size and layout, so they request the image at maximum size to make sure it's as sharp as possible. The images are still coming straight from Notion.so, and aren't served, transformed, or cached by Potion.
The rest of the page is fast - it's static HTML pre-generated or incrementally generated using Next.js, with a bit of JS on top, which is faster than Notion's fully dynamic thick client Javascript app. The example sites look good!
On the subject of Pagespeed's image guidance, Notion gets one out of two correct - when viewing these images from a Notion doc, we request & serve images at their displayed size using a query parameter, but we don't currently transcode the image to a more efficient format based on the browser's image support.
Where does adding the ability for Notion to transcode images sit in y'all's backlog? As much as it's not Notion's fault here and an underlying issue of image (re)sizing, it still gives the impression that Notion is slow.
To be honest, 42 isn't actually that bad. PageSpeed Insights scores are incredibly strict (that's a good thing) and not at all linear with visitor perception of loading speed.
news.ycombinator.com has a 100 score, but if you compare the actual "Lab Data" it's not a massive difference.
First Contentful Paint: news.ycombinator.com: 1.3s, potion.so: 2.7s
The biggest difference is Time to Interactive: news.ycombinator.com: 1.4s, potion.so: 11.2s
That 11.2s is pretty bad, but PageSpeed Insights doesn't take into consideration which interactions work before all the JavaScript has loaded. In the case of potion.so, the HTML is rendered on the server (or perhaps statically generated), and the vast majority of important interactions on the homepage are simple HTML links that work even with JavaScript disabled. The 2 big exceptions (and probably the biggest contributors to that terrible Time to Interactive metric) are the third-party embedded video and chat widget.
I just did a test on my production WordPress site with a dozen plugins and dozens of images on the home page. I got 97 performance, oh and I'm 9000 miles away from the server and tethered to my phone
To be fair I'm using Cloudflare and the static assets were all probably cached at the edge but the initial HTML page itself is always fetched from the server (I'd have to pay for their APO product to do that which I tested out and it works well but introduces the usual cache issues)
I doubt that’s an issue if people seek out your website and use it. Unless your primary growth strategy is Google SEO, I doubt that tweaking your PageSpeed Insights score is going to do much in cases like this where the site actually does load quickly in practice.
It looks like most of the guidance on Pagespeed for large images, and layout shift due to images. The guidance to fix is to set fixed images sizes for these elements, and to re-encode images into more efficient image formats, at their displayed size instead of their maximum source size. Potion probably doesn't currently know the correct width for an image because they give their users kind of unlimited style control to choose the image's size and layout, so they request the image at maximum size to make sure it's as sharp as possible. The images are still coming straight from Notion.so, and aren't served, transformed, or cached by Potion.
The rest of the page is fast - it's static HTML pre-generated or incrementally generated using Next.js, with a bit of JS on top, which is faster than Notion's fully dynamic thick client Javascript app. The example sites look good!
On the subject of Pagespeed's image guidance, Notion gets one out of two correct - when viewing these images from a Notion doc, we request & serve images at their displayed size using a query parameter, but we don't currently transcode the image to a more efficient format based on the browser's image support.