Papyrus is a blazing-fast, privacy-first, no-frills-attached platform for blogs & newsletters. Sign up and start writing posts just like this one.
At Papyrus, we’re a heavy user of Next.js. 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).
So, when Next.js announced Next.js version 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 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!
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!
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:
Smaller images means faster loading webpages, less bandwidth, and happier users - everyone wins.
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 to see all the new functionality coming up in Next 12.