Paragraph

Today, we have some exciting news to share regarding the evolution of our company.

We’re rebranding, and changing our name from **Papyrus** to **Paragraph**. This new brand better reflects our long-term vision and focus - helping creators publish content, reach their audience, build closer communities, and get paid directly from their users.

 ![](https://storage.googleapis.com/papyrus_images/5005182c0ae4fdbd2386de5979a25e6a)

## Why ‘Paragraph’?

Beyond the obvious reference to writing, *graphs* are used in mathematics and computer science to represent relationships. Relationships play a large role in the creator economy - musicians have listeners, streamers have viewers, and writers have readers (or newsletter subscribers).

Web3 is fundamentally changing how creators own, manage, and monetize these relationships. As we outlined in a [recent post](https://paragraph.xyz/@blog/web3-tools-for-future-of-creator-economy), we believe this direction is the future, so we intend on continuing to build novel ways of connecting creators with their audience. 

## What This Means for Our Users

All links - including all blogs and posts - will permanently (HTTP 308) redirect from https://papyrus.so to https://paragraph.xyz starting from today.

All newsletters were previously sent by *your-newsletter@papyrus.so.* Now, they’ll be sent by *your-newsletter@your-newsletter.paragraph.xyz.*

If you have a custom domain, there should be no changes for how you or your readers continue accessing your blog.

If you have any questions, we’re happy to help - just reach out on [Discord](discord.gg/yMCfGRuENg) or via email (hello@paragraph.xyz).

## The Path Ahead for Paragraph

This rebranding represents the first of many steps towards [our vision](https://paragraph.xyz/@blog/web3-tools-for-future-of-creator-economy) of the future of the creator economy. We’re just at the tip of the iceberg - we have big plans to continue changing how publishers grow and get paid, and how closer communities get built. Token-gated access, recurring crypto payments, wallet-to-wallet newsletters, and more ways to engage with readers & writers are just a few upcoming product features on the roadmap.

We also have some exciting news to share in the next few weeks that will help accelerate our goals - stay tuned!

As always, we’re incredibly grateful for your never-ending support, and we’re thrilled to have you along on our journey.

Papyrus is now Paragraph

Welcome to the Paragraph blog!

We’ll post updates about the platform, deep-dives on the interesting tech we use, or general thoughts about the writing ecosystem as a whole on here.

You can also find us on [Twitter](https://twitter.com/papyrus_xyz) or on our [Discord](https://discord.com/invite/ZRqz7V5vdq).

Be sure to hit Subscribe above to never miss a post.

About Paragraph

At [Papyrus](https://papyrus.so), we’ve been building tools to support creators since our inception.

We’ve built a platform that lets creators write content, create paid newsletters, and build a community. We’ve helped thousands of writers connect with tens of thousands of readers since we’ve launched.

Over the years, advances in technology have unlocked new methods of producing and monetizing digital content - from crowdfunding companies like Patreon to digital subscription services like Spotify, there’s been a consistent stream of disruptive technology that enables new forms of monetization and growth for  creators.

Today, we at Papyrus believe that **web3 and NFTs** will continue the trend of disruption, fundamentally changing how creators can provide utility, foster relationships, and build wealth *alongside* their audience.

We’re at the start of a broad shift from the creator economy to the **ownership economy** - creators will no longer simply produce content and hand it off to a platform to monetize as they see fit; instead, the creator and their audience will have ownership and stake in these creations, as well as ownership in the user-run platforms where these creations exist.

We believe Papyrus will help play a key role in empowering both creators and their readers during this transition.

\
 ![](https://storage.googleapis.com/papyrus_images/ef60f6e989008b24b94039d2eb2cee95)

\
# **How will web3 help writers & content creators?**

Historically, creators have gone through one or more of the following steps when producing content:

* **Funding:** Creator self-funds their creation by working other jobs, or (very rarely) getting an advance from a publishing company.
* **Content creation:** Creator produces something of value - a long-form article, a piece of investigative journalism, a comic book, an interview.
* **Monetization:** Creator tries to get paid for their creation - either by selling it directly, placing ads on their website, paid subscriptions, or relying on donations.
* **Growth:** Creator relies on traditional methods for growth (tweeting about it, posting on Reddit, …)

Web3 introduces mechanics that are fundamentally changing how this process works. Digital scarcity via NFTs, utility via social tokens, community ownership via DAOs, and economic growth incentives via royalties are just a handful of example of the technological shift.

Let’s explore how web3 could influence these steps, and where we believe the future of content creation lies.

## Funding

Creator’s have historically self-funded their creations. They work a 9-5 job, then come home and work on their true passions. Unless the creator has a large amount of savings or outside funding, it’s challenging for them to take the plunge and work on content creation full-time. (In rare circumstances, funds or publishing companies do provide up-front financing to the creator, but this is an exception and not the norm).

In addition, certain types of long-form pieces of content - like a comic book - can require many expenses, including artists, editors, graphic designers, and marketers, further limiting the number of creators that go all-in.

We want to change this by providing two different methods of receiving funding (*even before content is produced*): crowdfunding via **social tokens**, and equitably distributing funding via a **DAO.**

### Social tokens

Creators can mint and sell social tokens, which provide utility (such as access to their token-gated content, similar to a paid subscription), in addition to other special features (including royal incentives).

For example, a new creator on Papyrus could choose to mint 3 different tiers of tokens…

|    | Access token | Patron token | Super-fan token |
|----|----|----|----|
| Quantity | ∞ | 100/100 | 5/5 |
| Cost (ETH) | 0.05 | 0.5 | 2 |
| Royalty incentives | - | 0.1% | 1% |
| Other benefits | N/A - just access to all token-gated posts | Access to token-gated Discord | Signed, limited-edition physical merch |

Due to the fixed number of Patron and Super-fan tokens (and the possibility of return on investment), there’s incentive for supporters & speculators alike to buy these tokens early on, before content is even produced.

### Community owned & operated DAO

A percentage of all transaction profits on the platform could be directed to a community-owned treasury. All Papyrus token-holders could then periodically vote on which creators should receive funding. The more tokens you own, the more ownership you have, and thus the more say you’ll get over the direction of the  platform.

This is in contrast to monolithic companies themselves deciding who to fund, which has historically [encountered controversy](https://www.vox.com/recode/22338802/substack-pro-newsletter-controversy-jude-doyle) and has favored large creators that *already had* a massive audience, leading to unequal wealth distribution: the top 10 creators on Substack are earning more than $20m per year, but the vast majority of other creators are earning magnitudes less. DAOs could change this by more equitably distributing funding based on community ownership & governance.

## Content Creation & Monetization

Existing forms of monetization have problems - ads incentivize clickbait rather than high-quality content, and require large amounts of traffic. Paid subscriptions are challenging to grow without pre-existing audiences - the vast majority of subscribers [come from tweets](https://www.niemanlab.org/2021/09/what-i-learned-from-a-year-on-substack/), and if you don’t have a large Twitter following you’re at a disadvantage.

We want to supplement paid subscriptions with two new forms of monetization - **token-gated content** and **selling published content as NFTs** (which introduces an aspect of digital scarcity)**.**

### NFTs minted from written content

The signed, first-edition copy of The Hobbit sold for [over $200,000](https://news.artnet.com/market/first-edition-copy-hobbit-sells-210500-304991). I could go to the library and borrow a copy of The Hobbit for free - and it has the exact same story - so why is so much value placed on this one copy?

The answer is scarcity and status - there’s only one copy of the first-edition of The Hobbit, there will only ever be one, and it will only ever be owned by one person (or entity). Sure, I could photocopy every page of that first-edition, but I still wouldn’t own the first edition. Collectors and super-fans place very high value on scarce things they’re passionate about, or that can give them some kind of status.

NFTs introduce digital scarcity. When creators produce content, they can mint a fixed number of NFTs from this content. This can be sold to super-fans, providing a new stream of revenue to the content creator.

These NFTs can also be traded on third-party open marketplaces, with royalties continuously given back to the original creator, meaning this revenue stream is recurring and in addition to their token sales or paid subscriptions. This type of open-market trading also opens up a new type of audience that was previously inaccessible to the creator - speculators.

### Token-gated content

Creators will have the option of token-gating their posts, similar to how a creator paywalls their post today. Readers can purchase tokens that grant access to these posts.

Note that these tokens **work beyond Papyrus** since they’re based on Ethereum. You can use any other web3 platform, today or in the future, to continue providing new features and functionality to these token-holders. For example - you could create a token-gated Discord that’s only accessible to your token holders, fostering an even closer community with the most loyal of your audience.

## Growth

We believe that a creator’s audience should profit by helping the creator grow. In other words - wealth should be built with the creator and their audience hand-in-hand, rather than just the creator alone.

We do so by providing **economic incentives** for the reader to grow the creator.

### Incentivized growth

Since tokens can provide royalties, and a larger audience means larger royalties, token-holders are **economically incentivized** to help grow the creator. They have ownership and a financial stake in the success of the creator!

# What’s next for Papyrus?

Everything described above is just a small glimpse into where we believe the future is heading, and we couldn’t be more excited to help pave the way. So, over the next few months, we’ll be adding a layer of functionality on top of Papyrus that allows creators to connect their wallets and opt-in to crypto functionality.

The eventual goal is to decentralize as much as possible, but we’re starting with an approach that allows us to move quickly while enabling early adopters to take advantage of crypto features on Papyrus.

# Interested in getting in touch?

If any of this sounds interesting to you, we’d love to hear from you - regardless if you’re an engineer looking to join our team, or a content creator looking to onboard. You can find us at hello@papyrus.so, on [Twitter](https://twitter.com/papyrus_xyz), or on our [Discord](https://discord.com/invite/ZRqz7V5vdq) (no token needed to access 😉).

Papyrus and web3: building better tools for the future of the creator economy

We’re pleased to announce support for custom domains!

Custom domains are important for both SEO and branding, and are a necessity for serious bloggers looking to really make their blog their own. Rather than accessing your blog at `https://papyrus.so/@<YourUsername>`, you and your readers can access it at `blog.yoursite.com` or even `yoursite.com` directly!

For a one-time fee of $50, you can unlock the ability to use custom domains for your Papyrus blog.

## How do custom domains on Papyrus work?

You need to already own a custom domain in order to use it with Papyrus. There are plenty of domain name registrars you can use to buy custom domains directly, such as [Google Domains](https://domains.google/).

After you have a domain name in your possession, we charge a $50 one-time fee that unlocks custom domains permanently for your account. This means that you can add or remove custom domains, as many times as you’d like, on your blog. In other words, the purchase is tied to your blog, not to any specific custom domain.

You can use subdomains, such as `blog.yoursite.com`; or top level domains, such as `yoursite.com` (or switch between them and decide which you prefer!)

## Setting up a custom domain

In your [Papyrus blog settings](https://papyrus.so/settings/blog), get started by purchasing the custom domain feature via Stripe checkout.

Then, add your domain to your Papyrus account, and you’ll be instructed to update your DNS settings. The exact steps here vary depending on your domain name provider.

If you’re adding a **subdomain**, such as `blog.yoursite.com`, you’ll need to update your DNS settings as follows:

| DNS Type | DNS Name | DNS Value |
|----|----|----|
| CNAME | blog (*or, whatever subdomain you add)* | papyrus.so. |

If you’re adding an **apex domain**, such as `yoursite.com`, you’ll need to update your DNS settings as follows:

| **DNS Type** | **DNS Name** | DNS Value |
|----|----|----|
| A | @ | 76.76.21.21 |

After that, it may take some time to propagate, but when it does your blog settings will show that it’s verified!

## What happens to your old blog URL?

After you add a custom domain, we set up a permanent redirect from your old URL to your custom domain. This means your SEO shouldn’t be affected - the next time your web page is crawled, the bots will follow the redirect and crawl your domain.

## Any other questions?

Not to worry - just shoot us an email at hello@papyrus.so and we’ll be happy to help.

Adding Support for Custom Domains

*Papyrus is a blazing-fast, privacy-first, no-frills-attached blogging & newsletter platform. [Sign up](https://papyrus.dev?utm_source=papyrus&utm_medium=blogpost&utm_campaign=nextjs_blog) and start writing posts just like this one.*


***

[Papyrus.dev](https://papyrus.dev) is built on Next.js, which is a production-grade framework for React. It comes with a handful of opinionated and sensible defaults. Plus, it lets you produce static pages - just HTML, CSS and JS - from React code.

Static pages in particular are something we use heavily. For pages that rarely change - like blogposts - there’s no reason why 1) servers need to be involved at serving time, or 2) the response size is larger than a few hundred kB.

Ideally, we’d hit the API once (at build time, or every time the blog content is updated), insert the API response into the HTML, bundle up the minimal set of JS and CSS required to render the page, and serve the bundle globally on CDNs. Next.js makes it easy to do this.

Since we rely on static pages so much, we wanted to ensure we were doing everything in our power to guarantee they were small and fast - so, when Next.js started shaming us for our large static page sizes, we knew we had some optimization work to do:

 ![Red = bad!](https://storage.googleapis.com/papyrus_images/5714676ef299d623c0b9ace3bd33574a)Large page sizes means slower loading, and this is bad: they lead to a poor user experience, high bounce rate, and [negatively affected SEO](https://moz.com/learn/seo/page-speed).

*(\~500 kB first load JS is actually pretty small relative to the average JS a website loads in 2021, but we still think it’s unnecessarily large for a simple blog page).*

Our performance issues were confirmed by our less-than-ideal Google Lighthouse scores:

 ![Yellow = also bad](https://storage.googleapis.com/papyrus_images/3f023e79a74c4fed8b1582d223b8d353)The scores in isolation aren’t necessarily a conclusive way to determine a page’s performance, but they can provide some actionable guidance on what could be improved.

This blogpost is documenting some of the things we discovered. In the end, we successfully **achieved a 98 Performance Lighthouse score**, and reduced our largest **first-load-JS size by 3.5x**. In addition, we also implemented a handful of best practices along the way, such as image optimization.

Let’s dive into it.

## Analyzing Packages

A handful of tools are available to provide some clues on where we can focus our size-reduction efforts.

`@next/bundle-analyzer` is one such tool - it’s used to analyze the bundle size of your Next.js components, pages, and third party dependencies. Install it into your dev dependencies with  `yarn add -D @next/bundle-analyzer`, and add the following to `next.config.js` to run it using the `ANALYZE` environment variable:

```javascript
const withBundleAnalyzer = require("@next/bundle-analyzer")({
  enabled: process.env.ANALYZE === "true",
})

module.exports = withBundleAnalyzer({{{
  // This is just your regular next.config.js options. For example:
  // images: {
  //  domains: ["storage.googleapis.com"],
  //},
})
```

To actually begin the analysis, run `ANALYZE=true next build`, or, alternatively, add it to your `package.json` as a new script to keep it handy and accessible via `yarn analyze`:

```javascript
// package.json
{
  // ...
  "scripts": {
    "analyze": "ANALYZE=true next build",
  },
  // ...
}
```

When you run it, you’ll see the normal Next.js build process, but your browser will open with a very colorful page like this:

 ![](https://storage.googleapis.com/papyrus_images/64f7d90a65caa133d445f04f98f621cc)There’s a lot of info here, but one thing that sticks out is that `highlight.js` (in particular the languages contained within) is massive. We use `react-syntax-highlighter` to highlight syntax in our blogposts, and it depends on `highlight.js`.

So, what can we do to improve this? Luckily, `react-syntax-highlighter` makes it easy to defer loading the languages until we need it. This is called dynamic importing.

## Dynamic Imports

Dynamic imports are an [ES2020 feature](https://github.com/tc39/proposal-dynamic-import) (also [supported by default in Next.js](https://nextjs.org/docs/advanced-features/dynamic-import)) that enables dynamically loading JS at runtime, possibly based on some conditional logic. For example - we can load a search library only after a user clicks on a searchbox.

You can imagine how this can be used broadly to reduce the page first-load size: defer libraries until after the page loads (or, ideally, until they are needed). `react-syntax-highlighter` makes this even easier, as [they provide](https://github.com/react-syntax-highlighter/react-syntax-highlighter#async-build) an out-of-the-box import statement which defers loading the languages.

After switching our syntax highlighter to the dynamic-imported package, let’s see how that affected our page size:

 ![](https://storage.googleapis.com/papyrus_images/5dd6f410730c5e814b7762eb1b501b7c)Pretty significantly! This reduced the blogpost dynamic route (/\[blogname\]/\[noteId\]) first-load JS size by **nearly 2.5x**.  (The blog homepage didn’t change though, but we’ll fix that next).

And, when running `yarn analyze` again we can see the languages are no longer present:

 ![](https://storage.googleapis.com/papyrus_images/4038b91ac209c83af879e42ec734c2ae)Good progress so far, but let’s keep pushing onward.

## Remove Unused Code

Unused exports are removed at build-time, but if you’re *actually* using a package in a codepath that *does nothing*, the package will still be bundled but it will still be …doing nothing!

Let me explain via an example: during a major refactor of our codebase, we created an environment variable boolean that controlled if a new version of the blog page was to be displayed. If it was set to a false we displayed an older component, but if we flipped it to true we displayed a newer one.

Our code looked something like this:

```javascript
import NoteView from "components/public/NoteView"
import NewNoteView from "components/public/NewNoteView"

// ...

return (
  <div>
     { ENV_DEPLOY_NEW == true ? <NewNoteView /> : <NoteView /> }
   </div>
)
```

We gradually ramped this up, and after it was fully set to `true` for all users, we promptly …forgot about this flag.

This meant that `NoteView` was imported, and **never actually used**. Let’s remove it and see how this influences the page size:

 ![](https://storage.googleapis.com/papyrus_images/ee7b2f0ae493751ec8add02967ccccd6)Again, this significantly reduced the pagesize (of the blog dynamic route, /\[blogname\]) and resulted in a 3.5x decrease in size!

## Purge Unused CSS

One thing that stuck out in the Next build analysis was the massive CSS file shared by all pages:

 ![](https://storage.googleapis.com/papyrus_images/8777b9723f42ca6e7c891785a53054f3)354kb of CSS?!

We use Tailwind for Papyrus, and by default it comes with **lots** of utility classes. If you don’t strip these from your production build, you’ll have a large CSS file with a good portion of classes not used.

Let’s follow the [Tailwind guide on optimizing for production](https://tailwindcss.com/docs/optimizing-for-production), and add a `purge` entry to our `tailwind.config.js` file:

```javascript
module.exports = {
  purge: [
    "./pages/**/*.tsx",
    "./pages/**/*.js",
    "./pages/**/*.ts",
    "./components/**/*.tsx",
    "./components/**/*.js",
    "./components/**/*.ts",
  ],
  // ...
}
```

Re-running `yarn build` shows another large improvement (in the CSS size - the other metrics, including first load JS, naturally didn’t change):

 ![](https://storage.googleapis.com/papyrus_images/46b65922e2a57c11d57bf2e92bea457f)

## Disable Prefetching

Google Lighthouse complained of an unused javascript from a JS file called `index-c78019c9dfd0b22f4016.js`.

It turns out this is a **prefetched version** of the Papyrus homepage (the `index` page).

When using the Next-provided `Link` component, Next automatically prefetches all pages in the viewport (or, when the user hovers over the link). This enables ultra-fast navigation, but it’s also viewed as unnecessary JS by Lighthouse.

We use the Link component to link to our homepage via our logo, which is displayed on every blogpost page. Depending on the likelihood blog visitors will click the link it could make sense to kept his prefetched, but for the sake of optimization let’s disable it. We can do this by using the `prefetch`  prop:

```javascript
<Link href="/" prefetch={false}>
       <Logo
         className="w-auto h-10"
       />
</Link>
```

This didn’t impact our first-load pagesize (providing by `yarn build`), but it did bump up our lighthouse scores pretty significantly as will be seen below.

## Optimize Images

Next has [built-in image optimization](https://nextjs.org/docs/basic-features/image-optimization) via the `next/image` library and `<Image />` component.

This allows for resizing, compressing, and serving images in optimized formats (such as WebP, when the browser supports it). This also enables lazy-loading - only images that are requested are optimized on-demand then served.

We had a custom Logo component that looked something like this:

```javascript
export default function Logo(props: Props) {
  return (
     <img src="/logo.jpg" className="h-12 w-12" />
  )
}
```

We can refactor this to begin using image optimization:

```javascript
import LogoImg from "public/logo.jpg"
import Image from "next/image"

export default function Logo(props: Props) {
  return (
     <Image src={LogoImg} priority placeholder="blur" height={12} width={12} />
  )
}
```

We did a few different things in the above code:

* **Imported the image statically** (from `public/logo.jpg`). This needs to be a static import  in order to use blurring.
* **Blurred the image upon loading**, via the `placeholder=”blur”` prop. When the image is displayed, a low-resolution image is first displayed and blurred until the full-resolution one has loaded, so you get a neat fade-in effect. If you import the image directly, as above, this happens automatically; otherwise, you need to provide the [blurDataUrl field](https://nextjs.org/docs/api-reference/next/image#blurdataurl).
* **Preloaded the image**, via the `priority` prop. This instructs next to pre-load images that we consider high priority. The logo is displayed above-the-fold on pretty much every page, so it makes sense to pre-load.

Unfortunately, this didn’t actually affect any of our metrics - neither the Lighthouse score or Next build size budged - but this may be because the logo we have is already appropriately sized and small (\~5kb). If we did this on much higher-resolution images,  this may move the needle more drastically.

This did get us a neat blur-in effect, though!

Let’s see what all of these tweaks got us.

## Results & Final Thoughts

The results, after applying all the above fixes:

 ![](https://storage.googleapis.com/papyrus_images/3cfd3fdd1f2996c9266a5fe26269e31b)      ![](https://storage.googleapis.com/papyrus_images/b50bea47e7db7b13b39a9d33506ac989)Success! We went from a **79 to a 98 Lighthouse Performance score**, and reduced our largest JS first-load size by **3.5x (468kB to 181kB)**.

This list of optimizations is not exhaustive, and we can likely do better than  181kB - NextJS is still shaming us with red - but for an afternoon spent on fixing these low-hanging fruit, we achieved a pretty decent reduction in page size.

How we reduced Next.js page size by 3.5x and achieved a 98 Lighthouse score

*Papyrus is a blazing-fast, privacy-first, no-frills-attached platform for blogs & newsletters. [Sign up](https://papyrus.so?utm_source=papyrus&utm_medium=blogpost&utm_campaign=what_were_excited_about_next12) and start writing posts just like this one.*


---

At Papyrus, we’re a heavy user of [Next.js](https://nextjs.org/). We take advantage of features like image optimization, link prefetching, and incremental static regeneration to give readers of our blogs an ultra-fast page experience (read more about all our Next optimizations [here](https://papyrus.so/@PapyrusBlog/how-we-reduced-next.js-page-size-by-3.5x-and-achieved-a-98-lighthouse-score)).

So, when Next.js [announced Next.js version 12](https://nextjs.org/blog/next-12) at Next.js Conf, you can bet we were excited about all the new performance optimizations and features that come with it!

This blogpost goes over a few of the things we’re excited about, and how we’re already using them (or planning to use them) at Papyrus.

**Aside:** As with most Next upgrades, this was painless given the backward-compatibility and [minimal breaking changes](https://nextjs.org/blog/next-12#breaking-changes) in v12. The only thing we had to change was a bit of custom CSS targeting the `next/image` component (the generated `div` changed to a `span`); but other than that, we were up-and-running quickly.

## SWC - New Rust Compiler

During development, anything that slows down the pace of actually testing your changes in the browser can become a painpoint.

We don’t have a very large codebase yet, but even so, certain Next.js pages can take upwards of 10+ seconds to compile using Babel. This slows down our developers and prevents us from iterating as quickly as we’d like.

Next.js 12 announced a Babel replacement - SWC - as the default compiler. It’s based on Rust, and Next claims it’s **up to 17x faster** than Babel. In our anecdotal testing we’ve certainly noticed a drastic speedup in compilation time!

## Middleware

Deploying Next.js on Vercel has a ton of benefits, but also a handful of limitations compared to something like Next.js behind regular ol’ Nginx. In particular, anything involving more advanced server-side logic that runs pre-request - proxying, authentication, etc - has been challenging to do.

No more! Next.js 12 supports middleware using Vercel Edge Functions, which run before the request. This opens up a slew of functionality which was not possible before, using just Next.js and Vercel without the need for a server.

We intend on rewriting our authentication logic - which relies on cookies - to begin using middleware. Since we use incremental static regeneration, all of our blog post pages are just static HTML - no backends are used in the actual serving path - so we have historically not been able to (for example) check cookies pre-request in order to auth our users. We’ve had to instead check on the client-side, after the page has fully loaded (which can lead to a less-than-ideal user experience - the page fully loads, then after the auth check the URL gets redirected).

Using middleware, we can now perform server-side pre-request checks like this - even for statically generated pages!

\
 ![](https://storage.googleapis.com/papyrus_images/763ccd68c8186c652e05e9e97e045921)

## Optimized Images

Blogging platforms are image-heavy, so anything we can do to broadly reduce image size across the board will benefit bandwidth and reduce page load times. Next.js 12 announced improvements in image optimization, using a next-gen format called AVIF which is a 20% improvement over WebP.

We tested this, and actually saw a greater than 20% improvement when comparing AVIF images on our homepage with WebP:

\
 ![AVIF](https://storage.googleapis.com/papyrus_images/43dd695a8144d577eca79f31eda2bf48)

\
\
\
 ![](https://storage.googleapis.com/papyrus_images/c8a277b2e8d1e8839173e9fe8a59a4de)

\
Smaller images means faster loading webpages, less bandwidth, and happier users - everyone wins.

## Conclusion

These are just a handful of the features we’re excited about, but this isn’t an exhaustive list by any means. Check out [the announcement blogpost](https://nextjs.org/blog/next-12) to see all the new functionality coming up in Next 12.

What We're Excited About in Next.js 12

Hi there! 😄

You’re reading this post on Papyrus: a new, privacy-focused blogging & newsletter platform.

We set out to build a platform that was a joy for blog owners to use - and, for their visitors, an even bigger joy to read.

This means…

### Privacy-first

You’ll find no trackers, tracking cookies, or GDPR consent banners here. We vow never to track our users or sell any of our user’s data.

### No lock-in

Your data is truly yours: all your blogposts are exportable at any time with a single click.

### Blazing-fast

Papyrus has no feature bloat or plugins. We focused on the most important usecase, and tried to do it well: writing content and sharing it with your visitors.

Since we rely on static pages, aggressive caching and intelligent prefetching, everything is ultra-fast. Pages load instantly (<100kb per page) and navigation is instantaneous.

### SEO optimized

Fast-loading pages, SEO best practices, and accessibility means that you’ll always rank as a high as possible in search engines.


---

Think of Papyrus as a cross between static site generators (Hugo, Jenkins) and more advanced, Cloud-hosted blogging platforms (Medium, [Dev.to](http://Dev.to)).

This is the first release of Papyrus, so we still have a long ways to go, but we hope you’ll join us on this journey on giving users a better way to create blogs & newsletters.

Thanks,

The Papyrus Team

Welcome to Papyrus!

After deploying a new function on Google Cloud Functions, when attempting to run it you may encounter a stack trace like so:

```javascript
Function execution took 11 ms, finished with status: 'error'
 at processTicksAndRejections (internal/process/task_queues.js:95:5)
 at /layers/google.nodejs.functions-framework/functions-framework/node_modules/@google-cloud/functions-framework/build/src/invoker.js:199:28
 at Array.forEach (<anonymous>)
 at exports.scheduledFirestoreExport (/workspace/index.js:7:31)
 at FirestoreAdminClient.databasePath (/workspace/node_modules/@google-cloud/firestore/build/src/v1/firestore_admin_client.js:904:57)
 at /workspace/node_modules/google-gax/build/src/pathTemplate.js:120:29

TypeError: Cannot read property 'charCodeAt' of undefined at peg$parsetemplate (/workspace/node_modules/google-gax/build/src/pathTemplateParser.js:304:17) at Object.peg$parse [as parse] (/workspace/node_modules/google-gax/build/src/pathTemplateParser.js:633:18) at new PathTemplate (/workspace/node_modules/google-gax/build/src/pathTemplate.js:55:54)
 at PathTemplate.render (/workspace/node_modules/google-gax/build/src/pathTemplate.js:114:23)
```

This isn’t the most descriptive stack trace, but it means that the first parameter in the following method call is undefined:

```javascript
  const databaseName = client.databasePath(
     process.env.GCLOUD_PROJECT,
    '(default)'
  );
```

`process.env.GCLOUD_PROJECT` is undefined. But why?

Well, if you’re running a NodeJS runtime of 10 or above (which, if your Cloud Function is using NodeJS, you almost certainly are!) Google Cloud [removed this as an environment variable](https://cloud.google.com/functions/docs/migrating/nodejs-runtimes#environment_variable_changes).

So, to fix this, just use your *actual* project ID when constructing the databasePath:

```javascript
  const databaseName = client.databasePath(
     'my-nifty-googlecloud-project-id',
    '(default)'
  );
```

And voila! Problem solved.

*Credit to this [GitHub thread](https://github.com/googleapis/nodejs-automl/issues/107) for clearing things up.*