Bulleted lists are supported
Second Items
Nested 1
Nested 2
Back at top level
Child 1
Child 2
First Item
Second
Third
First Nest
Second Nest
Deeply nested
Third Nest
Last
Lists
First Item
Item 1
Nested
Nested
Item 2
Second Point
Third Point
This is code block.
System.out.println("Hello, world!"); System.out.println("Hello, world!"); System.out.println("Hello, world!");
This is nest block.
This is bulleted block
This is bulleted block :D
This is list block
This is list block :D
This is nest list block
This is nest list block twice
Who am i ?
The main advantages of this approach as opposed to proxying Notion's public HTML rendering include:
Performance
Notion's public hosting features are woefully unoptimized for standalone hosting.
Notion has some fundamental constraints around supporting fine-grained access control at the page, block, and asset level that any Notion-hosted site will have to contend with. By accessing Notion's API and rendering these pages and assets ourselves, we can bypass all of this fine-grained access control with site-wide access control that makes a lot more sense for hosting public websites.
We've spent a lot of time focusing on the performance of our hosted sites. For starters, we perform aggressive caching both at the API and Next.js levels for Notion data and pre-rendered pages respectively. We also rewrite all Notion image assets to go through a Cloudflare Worker for caching, image optimization, and use some neat tricks like identifying Unsplash images and adding some special imgix query params to them to ensure that all image assets load instantly. 💯
There's definitely room for improvement here as well. One of our roadmap items that I'm most excited about is experimenting with moving from SSR to incremental SSG. The difficult part of this will be keeping these statically generated pages up-to-date as edits are made in Notion, but I believe that this can mostly be addressed with content-based addressing.
What are the advantages of your custom approach to rendering Notion pages?
The main advantages of this approach as opposed to proxying Notion's public HTML rendering include:
Performance
Notion's public hosting features are woefully unoptimized for standalone hosting.
Notion has some fundamental constraints around supporting fine-grained access control at the page, block, and asset level that any Notion-hosted site will have to contend with. By accessing Notion's API and rendering these pages and assets ourselves, we can bypass all of this fine-grained access control with site-wide access control that makes a lot more sense for hosting public websites.
We've spent a lot of time focusing on the performance of our hosted sites. For starters, we perform aggressive caching both at the API and Next.js levels for Notion data and pre-rendered pages respectively. We also rewrite all Notion image assets to go through a Cloudflare Worker for caching, image optimization, and use some neat tricks like identifying Unsplash images and adding some special imgix query params to them to ensure that all image assets load instantly. 💯
There's definitely room for improvement here as well. One of our roadmap items that I'm most excited about is experimenting with moving from SSR to incremental SSG. The difficult part of this will be keeping these statically generated pages up-to-date as edits are made in Notion, but I believe that this can mostly be addressed with content-based addressing.
Flexibility
Using structured Notion data as the source of truth gives us a lot more flexibility around rendering than if we were to use the unstructured HTML pre-rendered by Notion as the source of truth.
This makes it relatively easy for us to offer multiple themes, dark mode support, extensions like site-wide search, and interop with a large community of existing React components and NPM modules.