Rebuilding Intercom’s homepage with a new CMS

I was the tech lead on this project, on Team Web! Our new marketing site has lots of goodies from the development side of things that I'm excited to talk about. I also just want to gush about my team a bit. (⬇️ thread) https://t.co/ui8bgrAjxj

— steven petryk (@stevenpetryk) May 30, 2019

Not only is this a rebrand, it's also a new architecture for us. Our old site is a Rails application, which required engineering effort whenever we wanted to change a page. We wanted to use a CMS, and we made the right choice of using a headless CMS (no WYSIWYG, just data).

— steven petryk (@stevenpetryk) May 30, 2019

The entire site is a server-side rendered React application (built using @zeithq's Next.js) that pulls all of the content from @contentful (the CMS). We don't have any content in the site's repo, and the site gets compiled to plain HTML, CSS, and JS at build time.

— steven petryk (@stevenpetryk) May 30, 2019

In Contentful, editors lay out all of the content and "think in components", a lot like engineers. By composing and arranging components, they can build pages entirely from scratch. In fact, the site today has NO bespoke components for any specific page.

— steven petryk (@stevenpetryk) May 30, 2019

Now, this always carries a risk—what if somebody makes a change in Contentful that could break the site? This is where @typescript comes into play. We use Contentful's APIs to introspect the CMS's schema and generate a bunch of TypeScript interfaces.

— steven petryk (@stevenpetryk) May 30, 2019

This way, when we wire up React components to Contentful components, if there is suddenly a mismatch in what our code expects and what Contentful is serving us, TypeScript will fail to compile, and the site will not deploy.

— steven petryk (@stevenpetryk) May 30, 2019

This means that our site is extremely resilient to changes in our CMS—an author would find it very difficult to "break" the site for customers by making risky changes. They can edit with confidence. We'll be open sourcing this codegen soon.

— steven petryk (@stevenpetryk) May 30, 2019

Also, since we pull in all of the content at compile/build time (instead of on the client side), that means we don't have to share our Contentful API keys with the world, and we are *very* well below our monthly API rate limits. Our site also kinda works with JS disabled (wip).

— steven petryk (@stevenpetryk) May 30, 2019

In the coming weeks, we want to really improve the process of Contentful editors finding out when their change caused a failed deploy so that they can resolve the issue quickly, eliminating even more need for engineering intervention. We have lots of other plans in the works too!

— steven petryk (@stevenpetryk) May 30, 2019

The engineering effort to get this launched was immense. While the spike of the initial architecture was relatively quick (thanks to Next.js), it took a huge effort interacting with our brand team, marketing teams, analytics teams, our purchase flow team, etc. to get this ready.

— steven petryk (@stevenpetryk) May 30, 2019

The folks on Team Web did an amazing job. There is SO MUCH to a marketing site that you wouldn't imagine, because it touches so much of the business. All 3 engineers I work with learned the system so thoroughly, coordinated with stakeholders, wrote a bunch of docs, etc.

— steven petryk (@stevenpetryk) May 30, 2019

From an ops perspective, we:

* Reduced deploy time from 20 minutes to about 90 seconds
* Made the site's time-to-interactive about a second faster
* We achieved >90 in all lighthouse audit scores (with a 100 in accessibility!)
* We shipped an architecture that's new to us pic.twitter.com/XeD9QFpCst

— steven petryk (@stevenpetryk) May 30, 2019

These last few months have been a wild ride, and so much fun. If you like what you see, why not join @IntercomEng? https://t.co/J8KmBykj1u (ironically, one of the few pages that hasn't been rebuilt yet 😝)

— steven petryk (@stevenpetryk) May 30, 2019