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.
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.
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 just spent some significant effort fighting against Next.js and its bundles just to go from a 68 -> 90 for my own project
The difference was day and night on a real phone on 3g
This [1] demo scores 81 and this[2] has a 68.
[0] - https://developers.google.com/speed/pagespeed/insights/?url=...
[1] - https://developers.google.com/speed/pagespeed/insights/?url=...
[2] - https://developers.google.com/speed/pagespeed/insights/?url=...