DEV Community: drew.tech

Hey CTO — A Core Web Vitals Strategy for your business.

drew.tech — Tue, 30 Mar 2021 17:13:00 +0000

Hey there, CTO!

Hope your Q1 is wrapping up nicely and those burn-down charts are looking burnt.

How’s your Q2 roadmap planning going?

Gotcha — lots of new features and a little bit of time for tech debt.

Ahh, and the SEO team says you need to work on “improving our web vitals”?

Do you have a plan for how you’re going to tackle them? It’s kind of a whole shift in performance measurement.

No? And you have a meeting tomorrow about it?

Okay, you can copy mine. Just make sure you change some stuff up so we don't get caught.

Here it is 👇

How might we...

How might we track Core Web Vitals effectively at our company so that engineering is consistently on top of performance, users experience a fast site, and Google ranks our content highly?

First, what are Web Vitals?

Core Web Vitals is an initiative from Google to create clarity on what metrics matter most to users and for SEO.

Here's what Google has to say about Vitals:

Web Vitals is an initiative by Google to provide unified guidance for quality signals that are essential to delivering a great user experience on the web. - web.dev/vitals

Core Web Vitals are a subset of Web Vitals. Google has picked out three as the core main focus. If you get these three right, the rest of the metrics should naturally fall into place.

Cumulative Layout Shift (CLS)

Avoiding shifting the page around as it loads is very important in giving your users a positive experience.

Cumulative Layout Shift is the metric that measures these shifts.

Check out this recording Google showed to emphasize the importance of CLS:

How is CLS measured?

Anytime an element changes size and causes the start position of other elements to change, you've contributed to the CLS.

Below are the ranges for CLS:

For more info, check out:

Largest Contentful Paint (LCP)

The perceived performance of your site is probably one of the most important metrics – Largest Contentful Paint tries to measure just that.

The Largest Contentful Paint (LCP) metric reports the render time of the largest image or text block visible within the viewport. - web.dev/lcp

How is LCP measured?

The paint time is saved for each of the elements in your initial viewport.

The following qualify for LCP measurement:

Images of all types
Videos
Background images loaded via CSS
All text blocks

This means any of these elements that take up a lot of space in the initial viewport should load very quickly.

Below are the ranges for LCP:

For more info, check out:

First Input Delay (FID)

Responding to user input quickly is critical to a positive user experience.

The First Input Delay (FID) metric helps measure your user's first impression of your site's interactivity and responsiveness. - web.dev/fid

This encourages a few things:

Shipping the minimum amount of required HTML/CSS/JS
Lazy loading where possible
Keeping the main thread less busy

How is FID measured?

First Input Delay measures the time between when a user interacts with an input and when the event handler actually starts to process that input.

Below are the ranges for FID:

For more info, check out:

Why are Web Vitals important?

Core Web Vitals measure:

site performance
user experience
SEO (soon)

Site performance

Because Web Vitals are measured in the field, they represent the real experience your users are having.

Lighthouse audits are great, but they don't represent what it's really like to visit your site in the wild.

This means metrics are representative of your audience as well (at least the ones using Chrome).

Think of these new Vitals as mini-Lighthouse audits that each visitor runs locally and reports the results.

User experience

Google made sure that the Core Web Vitals measure user-centric outcomes. CLS, LCP, and FID all impact UX and are generally safe from the vanity metric problem.

CLS is arguably entirely focused on creating a positive UX.

Designers – please don't let your engineers forget about loading states.

SEO (soon)

Google has announced they will rank you based on your Core Web Vitals, just not yet.

When will the switch happen? May 2021.

Google said in a recent blogpost that they won't switch to the new ranking until 2021.

So do you need to start fixing these issues now?

Not technically.

But here's why you should: each Core Web Vital is impacted by many metrics Google already ranks you on.

Time to first byte (TTFB) greatly impacts Largest Contentful Paint (LCP)
First Contentful Paint (FCP) pretty closely mirrors LCP
Total Blocking Time (TBT) looks quite a bit like First Input Delay (FID)

How to Track Web Vitals

Lighthouse & PageSpeed Insights

You can track your Web Vitals in Lighthouse audits, but only to an extent. To have a complete picture of your Core Web Vitals, you must track data both in the lab and in the field.

Local Lighthouse audits will point you in the right direction, but are only lab-based results.

To measure Core Web Vitals in the field, Google pulls data from the Chrome User Experience report. This is data from real users.

By running a PageSpeed Insight report, you can look at both lab and field data.

Chrome Extension

The Google team has made an extension that helps track Core Web Vitals as you browse and develop your site.

This extension works in any Chromium-based browser. I've used it in both Chrome and Brave. It's a great addition to my developer workflow.

You can download it here.

Google Search Console

Part of the reason Google introduced Web Vitals was to standardize metrics across all their tools, developer and marketing alike.

In Google Search Console (GSC), the metrics are grouped into both Mobile and Desktop. These reports will highlight areas for improvement and even point you to the specific pages with issues.

While Google Search Console is normally not part of the developer workflow, GSC is currently the best tool for finding and fixing Core Web Vital issues. I highly recommend getting access to your site's console.

CrUX API

Google gets its Core Web Vital data from visitors to your site that are using Chrome. By using Chrome, these users are unwittingly contributing to Google's Real User Monitoring (RUM) data set.

https://developers.google.com/web/tools/chrome-user-experience-report/api/reference

This API has two options:

Report the entire origin
Report on a specific page

This is useful for tracking a single page, but makes tracking groups of pages difficult. The path forward for tracking with this API is as follows:

Find representative pages for each section of the site
Identify the highest and lowest traffic pages for that site section
Track those pages (cache hit test, cache miss test)

This ensures that we have covered our most important pages and our slowest edge cases.

DIY Tracking (send to GA)

While it is more effort, you can setup a DIY solution to measuring, collecting, and analyzing the Core Web Vitals for your site.

It is possible to track Vitals and get them into Google Analytics. We are currently near our event limit and adding four events per page load would push us significantly over our current tier.

Sitemap based or traffic based

The CrUX API above uses a traffic-based approach for tracking Vitals. This means that the reported scores account for the density of our traffic on each page. This weighted score represents closer to what our average user experiences.

The other approach is Sitemap-based. Google Search Console displays your Vitals that correlate with each page, having no difference between our most popular page and the least popular page.

The second approach ensures there are no bad pages, whereas the first page ensures most users get a good experience most of the time.

per URL approach

percentage of traffic based approach (data from CrUX API)

How can we Monitor our scores?

The best way for us to stay on top of this is to get our Vitals scores into Slack*.

*unless Slack is down

Google has created a few sources we can query on a regular basis and send to our chat alerts channel, but it would take quite a bit of dev work to do.

Once a week, we could send a snapshot of Core Web Vital performance to each squad.

Build vs. Buy?

Well, we could totally build this internally. We'd have to decide if we want to use Google's data as the source of truth or collect our Core Web Vitals ourselves. We could integrate with the CRuX API mentioned above and get a good 28-day average view of individual pages and our site as a whole.

A basic version

The goal of this product would be to keep the engineering team in the loop on our vital scores. It should ideally integrate with Microsoft Teams or Slack. We should know how different sections of our site are doing on a weekly, monthly, and quarterly basis.

Build

would take at least a sprint or two to build (medium to large t-shirt size)
would take teams off of feature work
we could open source it eventually
more flexible and custom

Buy

would likely cost at least $100/mo
would free up engineering time so they can remain focused
solution would improve over time and keep up with Google's changes "for free"

A complex version

Vitals are very powerful, and we could build a very advanced monitoring suite around them. If we sample our visitors and collect vitals for some percentage of them, we could know our site's performance in near real-time. This system would be much more complex.

Build

would take a long time to build (three sprints minimum) and maintenance would be more here
would take one whole squad off of feature work & likely some of the DevOps team's time
would be costly to run (cost grows as our site gets more traffic)

Buy

would likely cost $400+ a month depending on volume
would free up a ton of time building + maintenance
solution would improve over time and keep up with Google's changes "for free"

Final recommendation

I think the smartest path forward is to start with the basic version and see if building/buying a more advanced tool is worth it.

We could either spend a sprint or two ramping up and engineer on the project or go buy something off of the shelf and spend a day or two integrating it.

With how much feature work we're trying to get done this quarter, I'd say let's opt for the "buy" option here.

The end

I could give you a detailed rundown of all the competitors in the space (hint: there aren't many), but that seems like a great topic for a new blog post 🙂

Is this a problem your company is having?

If so, I'd love to talk with you about Core Web Vitals and making FitVitals the best tool for monitoring Core Web Vitals.

Book a time and let's chat.

How to declare Twitter DM bankruptcy

drew.tech — Mon, 29 Mar 2021 13:57:03 +0000

Look, we get it. You have too many messages and it's easier to lock down your DMs than respond to all of them. But is that the solution?

Why declare DM bankruptcy

Kelly Vaughn 🐞

@kvlly

I have so many unread DMs from the past week or so that I am officially declaring DM bankruptcy.

I'm sorry if I missed your DM. I promise it was nothing personal.

The good news is I do actually check my email and have a public email where I'm easier to access:

✉️kelly@hey.com

22:15 PM - 08 Mar 2021

First off, congrats! You are popular on Twitter, popular enough to get a lot of the benefits that come from having a larger audience.

You can ask questions out into a void and actually get responses. When you tweet out a link to a project you're working on, people actually give you feedback. Amazing!

But what about the downsides?

Well, first off — sorry about the reply-guys. We can't fix those.

The Twitter DM UX is not great, but you probably already knew that. But on the bright side, some of the DMs you get are super awesome. Thoughtful internet strangers are the best type of strangers.

So how do you handle the bad DM UX?

One option is to declare DM bankruptcy and funnel all well-meaning followers to contact you via email. Even though your email is still public, this extra step often stops most junk but allows for incoming messages if the sender cares enough.

Decided you want to declare DM bankruptcy? Okay, let's get started.

The steps

1. Write a tweet

Filing for Twitter bankruptcy is considerably easier than the real thing. First, write a tweet as Kelly did above, letting your followers know that you won't be responding to their DMs.

Be sure to include your email. Bonus points for using an email provider like Hey.com, which lets you control who can and cannot message you.

2. Pin your bankruptcy tweet

Next, pin your bankruptcy tweet to your Twitter profile. Only a fraction of your followers see the bankruptcy tweet when you post it, so pinning it to your profile is important to keep all your followers in the loop.

3. Create an automated DM with Twitter's API (optional)

Okay, so now we're getting into the really cool part. This is the problem PlzDM.me solves, but I'm going to show you how to do it using Twitter's API instead.

First, what's a Twitter welcome message?

So Twitter created welcome messages to help brands deal with the large influx of DMs they get. They just never rolled it out to you and me.

But, it's in their API docs.

Let's use it.

Set up Twurl

Twurl is a lot like curl, except it's specifically for querying the Twitter API. Configure it once for auth and you're good to go.

Okay, so we're going to be using RubyGems to install Twurl.

First, run:

gem install twurl

Apply for Twitter developer access

The next step is to apply for access to the API. Do that here: https://developer.twitter.com/en/apply-for-access

Generate tokens

After you've been accepted (which should happen rather quickly), you'll need to generate and set up your tokens for Twurl.

To do that, head to the portal here: https://developer.twitter.com/en/portal/projects-and-apps.

I've already got a few apps, but this section will be empty for you. Click the "Create App" button.

Name that app whatever you're feeling like (but it does have to be unique globally).

Authorize Twurl

Next, you need to configure Twurl to pass your secrets that you just created on the last step, like this:

twurl authorize --consumer-key key       \
                --consumer-secret secret

Test out Twurl to be sure it's working:

twurl /1.1/statuses/home_timeline.json

Create your welcome message

Now that we're configured, let's start creating your automated welcome message.

Head over to the Twitter docs if you'd like a more detailed explanation of what we're doing.

Each page of Twitter API documentation normally comes with a copy-and-paste ready Twurl example.

twurl -A 'Content-type: application/json' /1.1/direct_messages/welcome_messages/new.json -d '{"name": "simple_welcome-message 01", "welcome_message": {"message_data": {"text": "Your welcome message goes here!"}}}'

The response should look something like this:

{
  "welcome_message": {
    "id": "1375945329892278289",
    "created_timestamp": "1616885905131",
    "message_data": {
      "text": "Your welcome message goes here!",
      "entities": {
        "hashtags": [],
        "symbols": [],
        "user_mentions": [],
        "urls": []
      }
    },
    "source_app_id": "19958039"
  },
  "apps": {
    "19958039": {
      "id": "19958039",
      "name": "Twurl Drew Local"
    }
  }
}

After you create it, be sure to take note of the welcome message id, you'll need this later.

Creating a welcome message rule

Welcome message rules are what makes Twitter automatically show someone a welcome message when they message you for the first time.

Be sure to use the id from the last step.

twurl -A 'Content-type: application/json' -X POST /1.1/direct_messages/welcome_messages/rules/new.json -d '{"welcome_message_rule": {"welcome_message_id": "YOUR_ID_FROM_LAST_STEP"}}'

Now when someone new messages you, they'll see this message automatically directing them to email you instead. Now you don't have to use that precious pinned tweet space to inform people you're not checking your DMs!

Is there an easier option?

Sometimes mucking around with the API isn't fun, I get that. That's why I've been building a tool to help everyone create these Twitter Welcome messages.

We're building PlzDM.me to help make declaring Twitter bankruptcy as easy as possible.

The ability to create Twitter welcome messages is on our free tier.

Comment on this post and I'll reach out to you when we launch later this week.

I built a Next.js job board with Next. Find your Next JS dream job!

drew.tech — Sun, 22 Nov 2020 01:34:49 +0000

UPDATE: this job board is no longer active. Please check out the hiring section of the Next.js Discord

I attended Next.js Conf last month and was impressed by the high quality content, updates, and virtual conference setup (yay global pandemics).

It even inspired me to build a new product, Next.js Jobs – but more on that below.

The content, updates, and setup

The production level of this conference was waay better than I was anticipating.

The keynote along with each of the individual presentations showed a level of polish while still feeling like a conference talk. I think this was accomplished by pre-recording talks, but requiring a "one-take" policy, meaning the video had to be recorded in one sitting with no edits.

Next.js 10 is great, and so are its accompanying features from Vercel. Check out my post on the highlights of Next.js Conf.

All of this happened on an awesome YouTube-powered live streaming conference setup with multiple "stages". Cool stuff.

The community

But what I was mostly impressed with was the community.

Tons of people registered, over 75k. And about half of them actually showed up!

I joined the community Discord server and was overwhelmed by the volume of channels and messages.

Check out just how many "job" channels there were:

By the way, you can totally still join the Discord if you're interested: https://discord.gg/KNKF84E

The realization

And then after the conference, all of those extra job channels got cleaned up. That left me thinking, where are all these job posts going to go? I searched around, but there was really home for them.

Current job boards barely treat Next.js as a first class citizen, but rather emphasize React. That's probably fine for most cases for the hiring mangers, as a good React dev can be taught Next.js.

But what about the developers looking for Next.js jobs?

There's not much outside of the single "#jobs" channel in the Discord now, which is very noisy. It's full of job seekers trying to find a job that uses Next.js.

The product

That's why I created Next.js Jobs – a job board for Next.js enthusiasts. A job board that helps developers find their Next(.js) job.

https://jobs.nextjsnotes.com

How does it work?

If you're looking for a job:

Sign up with your email (If you're already subscribed to NextjsNotes, you're on the list)
Companies submit jobs that use Next.js
I manually moderate the job post and make sure they actually use Next.js
Each Tuesday, an automated email goes out with links to each job and their descriptions

If you're submitting a job:

Submit a job on the site
I'll moderate it and reach out to you with any questions
If approved, your job post will be sent out to developers the following Tuesday morning

The future

There are a lot of missing features right now, but rather than build them, I want to validate there is actually market demand here.So test it out, let me know what you think!

I'm not planning on monetizing this until it's a self-sustainable platform. Right now I'm manually finding Next.js jobs and adding them to the site. In the future, I hope to charge about $99/mo for a job posting. Well under what LinkedIn is asking, and generally in line with what I've seen in terms of "standard pricing" for job boards.

I hope I can help you find your Next JS dream job! (pun totally intended)

See you on the other side,

Drew

Next.js Conf Highlights

drew.tech — Thu, 29 Oct 2020 02:47:00 +0000

Next.js Conf was streamed all around the world by over 34,500 viewers on a custom platform this week on Tuesday. It was full of great news for the Next.js framework and ecosystem.

We'll do a deep dive of some Next.js 10.0 features later, but for now, this update includes a short overview of each.

Here's the keynote:

So that keynote covered quite a few releases. Next 10 is out, Next.js Analytics launched, and Next.js starter kits were introduced with Commerce being the first.

Let's briefly get into these.

Next.js 10.0

This announcement was somewhat expected. There were lots of indicators pointing to Next.js 10 being released at this conference. Coordinating planned secretive launches while working on open-source software in public is nearly impossible.

What I was surprised by was how many updates were included in Next 10.

They introduced 20 new features while reducing the bundle size by 16% 🤯

Let's talk about the feature 👇

Next.js Image optimization

According to the Next.js 10 release blog post, images take up 50% of the total bytes on web pages.

When looking for performance optimizations, the first place I generally look is the images:

Are images properly sized?
Are images served with modern formats?
Are we serving images using a CDN?

The Next.js Image Component takes care of a lot of that.

The Next.js image component is exactly what we have been wanting for images in React.

Pass it a path - local or remote - and it just works. Specify sizes, formats or Image services (cloudinary, imgix...)

this is so awesome! pic.twitter.com/PN7yytFF1T

— Wes Bos (@wesbos) October 28, 2020

The Next.js team, with help from the Chrome team at Google, came up with an RFC for the component only 55 days ago:

[RFC] Image Component for Next.js · Discussion #16832 · vercel/next.js

Think of the Image component as mostly a drop-in replacement for the existing HTML element.

Read more about it on the release blog post.

Next.js Internationalization

One of the most common use cases for needing a custom server (opting out of the "Pit of success" of Next.js) is internationalization.

Translating your site into multiple languages is critical to many business' success, yet it's often treated as an afterthought.

This release of Next.js makes internationalization a first-class citizen.

Now, you won't need to create a custom server to handle i18n routing, content, etc.

Check out the RFC, release notes, and documentation to learn more.

Next.js Analytics

I'm probably most excited about this added feature. Core Web Vitals are going to be a big deal & making it easy for developers to track them is a huge win.

Vercel launched Next.js Analytics yesterday, which are built right into both Next.js and the Vercel platform.

Right now, you can enable Next.js Analytics on any app that's on version 10.

There is a catch though; you only get one app per Hobby account.

This makes tons of sense, though. Recording and processing all of this real-time data is very hard, both in terms of processing and storage.

To have an unlimited collection of Core Web Vitals, you'll likely have to be on one of the higher paying tiers at Vercel.

A few quick questions below 👇

Is this feature Vercel only? For now, yes.

Is there a limit on how much data I can collect? Yes. Right now, only a single day view exists on Hobby tiers. I'd assume that limit is larger for paid plans.

Can I track Core Web Vitals some other way? Totally! Under the hood, it's very likely this feature uses the existing reportWebVitals function that I wrote about a while back:

Monitoring performance in Next.js

I'm excited to see where Next.js Analytics goes!

Next.js Commerce

Next.js Commerce is borrowing the idea of headless CMS sites and applying it to ecommerce.

Next.js Commerce

The all-in-one starter kit for high-performance ecommerce sites.

This is a great option for people who want a custom front end with the performance and reliability of a platform like Shopify or BigCommerce

BigCommerce is the first to partner with the Next.js team and right now you can configure a headless BigCommerce deployment with a custom Next.js site with just a few clicks.

I believe this will become the de facto starting point when building brand new Next.js ecommerce sites in the future.

Other updates

Below are some notable updates that tackle performance and improving developer experience.

React 17 support was added
as properties no longer needed on href
Improved CSS loading for 3rd party components
Blocking mode for getStaticPaths
Codemod CLI (expect one soon for the Image Component)
Fast Refresh enabled for .mdx files

FAQ

Q: Can I view the talks online yet?

A: ~~Not yet, they're working on getting them all uploaded to their~~ Some of them are uploaded now. Check out their YouTube channel.

Q: I heard there was swag. Where can I get it?

A: You can grab any remaining swag at nextjs.org/give. I'm personally hyped about these clogs.

P.S. - They're donating the profit to some great charities (check at the bottom of the /give page).

Q: What was the theme of this release of Next.js?

A: I'd say it's pretty clear the Next.js team cares a lot about performance. Almost every feature ties back to performance in some way.

While the Commerce launch doesn't explicitly talk about performance, they did mention how important page speed is for conversion rates on ecommerce sites.

Not only were features added in Next.js 10, but the overall bundle size decreased as well.

Q: I heard there is a Next.js Discord. Where can I join?

A: Here's an invite link: https://discord.gg/KNKF84E

Q: Where can I get more info on Next.js Analytics/Commerce/Image Component?

A: Hey, glad you asked! I'm doing a deep dive into each of these features in the coming weeks. If you're not already, subscribe at the bottom of the page to get notified when they go out.

For now, the Next.js docs do a pretty good job:

Conclusion

Overall, I'd say it's a great time to be a Next.js developer. The ecosystem is growing quite rapidly & the folks at Vercel seem to have the backing of quite a few tech giants (AWS, Google, Shopify, and Facebook to name a few).

Next.js has a lot of momentum right now – I'm excited to see what happens next (pun intended).

Monitoring performance in Next.js

drew.tech — Tue, 08 Sep 2020 15:35:00 +0000

Before we jump into how to measure performance, let me convince you that it's worth it.

Already convinced you should be measuring performance? Jump to the "In the lab" implementation section below.

Each 100ms decrease in homepage load speed increases session conversion by 1.11%

At least, that was the case for Mobify. Quite a few sites saw dramatic increases in conversion by improving performance.

The team at Google came up with a list of reasons that performance matters.

https://web.dev/why-speed-matters

Their reasoning can be broken up into these four categories:

1. Money

Let's say improving performance increases your conversion rate one percent. How big of an impact might that have on your profit?

Return on ad spend (ROAS) is a very important metric when doing any paid marketing. It's basically the measure of how efficient your ad spend is.

https://docs.google.com/spreadsheets/d/11UwZ3o55u_B-bjKZyc7XIz3otk0B7Cq6YzIKGW-jklA/edit?usp=sharing

If you have a budget of $4000 and a conversion rate of 5%, you're dramatically outperforming your competition with double the budget if their conversion rate is 1%.

High conversion rates are the difference between success and failure, especially in low-margin businesses.

2. UX

Ever browsed a slow, jumpy, and bloated site?

Did you have a good time?

Exactly.

Core Web Vitals encourage prioritizing visual and technical accessibility across teams.

User experience is not solely the responsibility of the Design and UX team, it's something we all contribute to.

3. SEO

It's always been a bit of a secret how much Google thinks performance matters for search rank.

With the recent release of Core Web Vitals, I think they are making their stance more clear. Performance matters and will mater more and more over time.

Google has been signaling these metrics are very important.

Core Web Vitals are:

Built into all Google tools
Documented very thoroughly on web.dev
Prominently displayed in Google Search Console
Delayed launching Vitals due to COVID-19

To that last point, the delay: why would they need to delay the launch if it wasn't going to make a big impact?

While much of this is speculation, I think the signals are showing that Google is going to skew rankings heavily based on Vitals.

4. Tech debt

I'm assuming this audience is pretty aware of what tech debt is.

While having good performance isn't a great indicator of no tech debt, bad performance usually means there's some form of tech debt hanging around.

Are you:

Loading your images in a really weird way that none of your developers understand?
Using a complicated architecture so measuring and thinking about performance is tricky for a single developer to think about?
Relying on old tech and not updating to newer standards?

Building a culture that continuously improves performance will have the highest ROI over time.

Monitoring Core Web Vitals in Next.js

If you aren't familiar with Core Web Vitals, they're a new set of metrics Google released to update their guidance on what a quality website performs like.

Intro to Core Web Vitals

In the lab

Front end performance monitoring and Lighthouse audits have been inseparable for quite some time.

Lighthouse is an open-source tool for monitoring performance and finding areas of opportunity in your site.

A screenshot of the green circles has become the goal of many engineering teams around the world.

These audits are a form of lab testing.

Lab testing is exactly what it sounds like: testing in controlled conditions.

The approach a lot of teams are taking to solve performance woes is to run more audits.

Common options include:

frequent local audits in Chrome
paying for a SaaS monitoring tool
as a step in the CI/CD process

These are all a step in the right direction. As I said earlier, the highest ROI fix is simply to change the engineering culture around performance.

I see lab testing as the low-hanging fruit for most engineering teams.

It gets developers thinking about:

front end performance
keeping payloads smaller
back end request response times

While not perfect, consistent Lighthouse audits can get you 80% of the way to a performant site.

Setting up automated Lighthouse audits

If you're hosting on Vercel, it's as simple as adding the Lighthouse integration to your site:

The integration automatically audits each deploy.

If you're not hosting in Vercel, you can use a step in your CI process (GitHub Actions).

This action provides many options for configuring:

pull request comments
Slack alerts
failing a build on too low of scores

Simply add the action to the repo you'd like to test.

If you don't want to manage all this yourself, there are good paid SaaS solutions that get the job done. I'm currently using Calibre at my day job, and we've had success with that.

What's the catch?

Earlier I mentioned that Lighthouse audits aren't perfect. Why?

Well, lab data isn't representative. The map is not the territory.

"It works on my machine" is the perfect example of why lab data isn't the best solution.

Consider a visitor of your site that lives in another country, far away from the AWS region you chose. Is their experience captured in your Lighthouse audit?

In the field

So say you're doing pretty well on your Lighthouse audits. How might you upgrade your performance monitoring game?

Field data.

Core Web Vitals will change the way we think about performance monitoring, specifically in the field.

I wrote about it here:

The Ripple of Web Vitals

Collecting performance data from real users is more representative than lab audits.

Thankfully, Next supports collecting Core Web Vitals in the field directly in the framework.

Setting up field tracking of Core Web Vitals in Next

Google Analytics is a very simple place to send Core Web Vitals.

You can use the added metrics to see how performance impacts:

Conversion rate
Bounce rate
Time on site

and confirm the importance of performance for yourself.

You can even create custom alerts that will warn you each day/week/month if you've exceeded your performance budget.

Setup a Google Analytics property

Head to analytics.google.com and click the "admin" button in the bottom left.

Then click "Create property" to get started.

Select "Web property".

Add your production URL and set your timezone.

After creating your property, it will give you a Property Id.

It should look something like UA-73089861-6.

Install `analytics`

To interact with Google Analytics in our Next.js app, I like to use analytics, an open-source library that supports tons of analytics providers.

https://getanalytics.io/

We need to install it into our app as well as the Google Analytics plugin.

npm install analytics @analytics/google-analytics --save

Configure analytics

Now we need to configure analytics and import it into our app.

First, create a file named analytics.js and configure it with your property Id.

It should look something like this:

import Analytics from 'analytics';
import googleAnalyticsPlugin from '@analytics/google-analytics';
import Router from 'next/router';

// Initialize analytics and plugins
// Documentation: https://getanalytics.io
const analytics = Analytics({
  debug: process.env.NODE_ENV === 'production',
  plugins: [
    googleAnalyticsPlugin({
      trackingId: 'UA-73089861-6', // use your trackingId
    }),
  ],
});

// Track initial pageview
if (typeof window !== 'undefined') {
  analytics.page();
}

// Track pageview on route change
Router.events.on('routeChangeComplete', (url) => {
  analytics.page();
});

export default analytics;

GitHub source link.

(P.s. - that snippet is borrowed from Divjoy, a React code generator that is totally worth buying in my opinion)

Configuring _app.js

In order to get this snippet to load on every page, we need to add it to our custom _app.js.

We also need to add the Core Web Vital reporting function, reportWebVitals.

That leaves us with something like this:

import '../styles/globals.css';
import analytics from '../util/analytics';

function MyApp({ Component, pageProps }) {
  return <Component {...pageProps} />;
}

export function reportWebVitals({ id, name, label, value }) {
  analytics.track(name, {
    category: label === 'web-vital' ? 'Web Vitals' : 'Next.js custom metric',
    value: Math.round(name === 'CLS' ? value * 1000 : value), // values must be integers
    label: id, // id unique to current page load
    nonInteraction: true, // avoids affecting bounce rate.
  });
}

export default MyApp;

GitHub source link

If you don't want to use the analytics library, the Next team great has documentation for that.

Success?

Time to test it out!

Deploy your code, or switch the debug value in analytics.js to

debug: process.env.NODE_ENV !== 'production',

Then, when you visit pages you should be firing events to Google Analytics.

Hop over to Reports , Realtime , and Events to see if it's working.

To view historical data, go to Behavior , Events , Top Events and select Event Action as the primary.

Optional: set up alerts

If you want to set up daily email alerts for your Vitals in Google Analytics, head to Admin , Custom Alerts.

Set it up like so:

Now I'll get alerted anytime my CLS goes above 0.1 on a daily basis.

Conclusion

While I'd recommend the field performance monitoring approach, my ultimate recommendation is to simply start.

Don’t let the perfect be the enemy of the good

Both options provide ample information to start improving your performance today.

Learn more

If you're interested in Core Web Vitals, performance monitoring, or everything Next.js, sign up to get new articles like this one delivered to your inbox here

I also tweet @dbredvick on Twitter. Feel free to DM me or email me at drewb@hey.com.

Rome wasn't built in a day, and neither was my SaaS app

drew.tech — Tue, 18 Aug 2020 14:27:07 +0000

We overestimate what we can do in a week and underestimate what we can do in a year.

Building Rome

I took a week of vacation to work on my side project, Fit Vitals. I set out with the goal of "being able to onboard my first customer".

While that's technically possible right now, the product is no where near where I want it to be.

This is partially because the problem Fit Vitals solves is more complex than I originally thought. Fit Vitals enables engineers and marketers to monitor and alert on Core Web Vitals.

While that idea is simple, the complexity comes from the sheer amount of data involved.

Each pageview creates at minimum two API calls. While solving this for small sites is simple, sites that get a million views a day are more complicated.

Aaannd guess who has the budget to afford this SaaS? That's right. Sites with millions of views.

So I'm no where near finished yet.

And I'm learning that it's okay for things to take awhile.

I made progress that I'm proud of:

I have a great looking brand (thanks to my fiancée)
I'm able to process data in real time in Kinesis
Configured auth and a GraphQL API with AWS Amplify
Built an API with API Gateway
Prototyped an npm module for sending the analytics

That's good enough as long as I continue making progress.

I think many of us are familiar with the phrase "Rome wasn't built in a day", but James Clear added a clause to the end that makes it even more powerful.

"Rome wasn't built in a day, but they were laying bricks every hour."

In his blog post, Lay a Brick, Clear warns about using the phrase to warrant delaying action.

It's more important to lay the next brick than it is to think of the ideal finished state.

Motivation

While we do solve a lot of technical problems, I'd argue our biggest challenges are mental. At least for me they are.

Here's how I'm thinking about my motivation and mental headspace while building.

Stair Step Approach

The Stair Step Approach to Bootstrapping is a framework made popular by Rob Walling back in 2015.

I think this framework solves a very important problem in the bootstrapper world – motivation.

By building a SaaS app right off of the bat, I'm trying to start on Step 3.

I'll need to be extra patient if I want to succeed.

I'm also on the lookout for a one-time product involving Core Web Vitals to help build momentum.

Start small, or at least be patient with yourself if you start big.

Building in public

I'm building Fit Vitals in public on IndieHackers.

https://www.indiehackers.com/post/a-week-of-vacation-to-work-on-my-side-project-e77adbe8fa

Posting about my product and getting feedback from other IndieHackers is very motivating.

Build in public, it's worth it.

Scratching your own itch

At work, I've been looking into performance monitoring for the last two months. Fit Vitals was born out of endless hours of research looking for a Web Vitals monitoring tool and finding nothing.

The first customer for this product is me.

If I make a great solution and it fixes my issues I'll be happy. Anything else is upside.

Build for yourself.

Follow along

I'm excited to continue building a profitable SaaS product in the performance monitoring space.

Instead of focusing on perfection, I'm going to work on "laying a brick" every day.

I'll be shifting my focus to starting small, building in public, and continuing to scratch my own itch.

I share almost everything I learn on Twitter.

I'm also documenting the more business-type pieces on IndieHackers.

I'll post my technical findings here.

If you prefer email you can sign up on my blog.

See you on the other side,

Drew

Intro to Core Web Vitals

drew.tech — Sun, 26 Jul 2020 23:30:00 +0000

What are Web Vitals?

Core Web Vitals is an initiative from Google to create clarity on what metrics matter most to users and for SEO.

Google says:

Web Vitals is an initiative by Google to provide unified guidance for quality signals that are essential to delivering a great user experience on the web. - web.dev/vitals

Core Web Vitals are a subset of Web Vitals. Google has picked out three as the core main focus.

If you get these three right, the rest of the metrics should naturally fall into place.

Cumulative Layout Shift (CLS)

Avoiding shifting the page around as it loads is very important in giving your users a positive experience.

Cumulative Layout Shift is the metric that measures these shifts.

Check out this recording Google showed to emphasize the importance of CLS:

How is CLS measured?

Anytime an element changes size and causes the start position of other elements to change, you've contributed to the CLS.

Below are the ranges for CLS:

For more info, check out:

Largest Contentful Paint (LCP)

The perceived performance of your site is probably one of the most important metrics.

Largest Contentful Paint tries to measure just that.

The Largest Contentful Paint (LCP) metric reports the render time of the largest image or text block visible within the viewport. - web.dev/lcp

How is LCP measured?

The paint time is saved for each of the elements in your intial viewport.

The following qualify for LCP measurement:

Images of all types
Videos
Background images loaded via CSS
All text blocks

This means any of these elements that take up a lot of space in the initial viewport should load very quickly.

Below are the ranges for LCP:

For more info, check out:

First Input Delay (FID)

Responding to user input quickly is critical to a positive user experience.

The First Input Delay (FID) metric helps measure your user's first impression of your site's interactivity and responsiveness. - web.dev/fid

This encourages a few things:

Shipping the minimum amount of required HTML/CSS/JS
Lazy loading where possible
Keeping the main thread less busy

How is FID measured?

First Input Delay measures the time between when a user interacts with an input and when the event handler actually starts to process that input.

Below are the ranges for FID:

For more info, check out:

Why are they important?

Core Web Vitals measure:

site performance
user experience
SEO (soon)

Site performance

Because Web Vitals are measured in the field, they represent the real experience your users are having.

Lighthouse audits are great, but they don't represent what it's really like to visit your site in the wild.

This means metrics are representative of your audience as well (at least the ones using Chrome).

Think of these new Vitals as mini-Lighthouse audits that each visitor runs locally and reports the results.

User experience

Google made sure that the Core Web Vitals measure user-centric outcomes. CLS, LCP, and FID all impact UX and are generally safe from the vanity metric problem.

CLS is arguably entirely focused on creating a positive UX.

Designers – please don't let your engineers forget about loading states.

SEO (soon)

Google has announced they will rank you based on your Core Web Vitals, just not yet.

When will the switch happen? It's too early to say.

Google said in a recent blogpost that they won't switch to the new ranking until next year. They will provide at least six months of lead time after making an official statement.

So do you need to start fixing these issues now?

Not technically.

But here's why you should: each Core Web Vital is impacted by many metrics Google already ranks you on.

Time to first byte (TTFB) greatly impacts Largest Contentful Paint (LCP)
First Contentful Paint (FCP) pretty closely mirrors LCP
Total Blocking Time (TBT) looks quite a bit like First Input Delay (FID)

Get started today.

What's next?

If you're looking for more information on Core Web Vitals, check out Google's educational site: web.dev/vitals.

I'm making a guide to help developers with practical Vitals issues like:

How to track Core Web Vitals (Next, Nuxt, & Gatsby)
Quick fixes for CLS
Quick fixes for LCP
Quick fixes for FID

I'll be building tools and documenting what I learn about Web Vitals over the next few months.

Consider following me here or on Twitter @dbredvick you're interested in learning more.

Are you measuring your Core Web Vitals yet?

3,000+ words on why you should use Next.js

drew.tech — Wed, 01 Jul 2020 21:20:00 +0000

TLDR; in this article, I claim it's best for folks who know React to start with Next.js from the beginning. We also get into why it would be a sound financial decision. Disclaimer: not everyone has to use React/Next.js nor does it fit every use case. Enjoy the article 🙂

I originally published this essay at https://nextjsnotes.com/why-nextjs/

Next.js is a fast-growing React framework that is used by almost 100,000 repositories now [source]. Next.js has a broad set of features that both IndieHackers and Fortune 500 companies love. Check out the large number of sites in their showcase.

This post is an investigation that attempts to answer the following:

Why React?
What has made Next.js successful?
What are the pros and cons of Next.js?

First, why React?

To understand the success of Next.js, we need to first look at the success of React.

The numbers

Is React really that popular? Let's check out some data points.

Installs

As of this writing, React gets about 7.75 million weekly installs and is a dependency to over 3.9 million GitHub repositories [installs source, dependencies source].

That's a lot of npm install react@latest going on.

If we look historically at this weekly download metric on npmtrends.com, the lead React has is staggering.

React compared to Vue, Angular, and Angular core from npmtrends.

Three notes from this graph:

WOW, things really shut down in December.
GitHub stars mean less than you think they do.
Angular is hard to measure because of the split (angular.js vs angular explanation).

I started building applications using React in late 2017. It wasn't until mid-2018 that my job fully embraced React and started building a shareable internal component library.

Speaking of work, let's talk about employment.

Jobs

Another proxy for popularity is the number of jobs associated with a framework.

"jobs, jobs, jobs" - every politician, ever.

Searching for "React jobs" on Google yields tons of results: 293,000,000 as of this writing.

Pull up LinkedIn, Indeed, and a few other job boards to get a sense of how many options are out there.

LinkedIn has about 42,091 jobs for the search "react" in the United States

Indeed has about the same job count: 43,315 for the search term "react" in the US.

ZipRecruiter was showing over 850 remote "react" jobs.

So why do the job numbers matter?

It shows there is demand. Demand ensures that in five years, you'll be able to hire developers that know the framework.

While this might not be important to you, businesses need to consider the ability to hire.

We should consider the number of jobs AND the happiness of the people using the framework frequently.

According to the 2019 Stack Overflow Developer Survey, React ranked highest for "Most Loved Web Framework".

"... jQuery are most dreaded"

2019 State of JS developer survey front end frameworks section

The State of JS 2019 survey shows that a ton of people are using React and wouldn't mind using it again, though there are a few detractors.

Conclusion

The numbers show that React is a dominant player in the web framework landscape. Developers are eager to learn React and generally stick with it, either because of the job market or its technical fundamentals.

The tech

We can't talk about a framework without mentioning a few of the key aspects of its technical fundamentals and how they contribute to its success.

React:

focuses on one thing (the view layer)
supports componentized thinking & sharing
simplifies data flows

Do one thing and do it well

Part of the equation of React's success is doing one thing and doing it exceptionally well. React's focus is printed on their homepage:

A JavaScript library for building user interfaces

That may sound simple, but it's critical.

By focusing on one thing , React has been able to iterate on its core mission relentlessly.

React does not focus on:

Data fetching (axios, fetch, superagent, SWR)
Advanced state management (redux, recoil, react-query)
Handle styling (styled-components, styled-jsx)

React only focuses on the view layer.

That lets the framework excel at building user interfaces while ignoring all other problems.

Open-source community

By ignoring a lot of problems, React created a void. Developers happily filled the void with their solutions and contributed them back to the community.

npm has 127951 packages when searching react-

Many companies intentionally do this.

Salesforce could add all the features their users are requesting, or they could continue to let third-party developers build those solutions.
Shopify could add all of the necessary features to run any store you can think of, or they could let third-party developers build a robust ecosystem around them.

The open-source software around React is a natural moat. (What's an economic moat?)

As a developer, it helps me get my job done faster (and likely with higher quality). Each open-source package is a few hundred lines of code not written or maintained by my team, yet we benefit from its vast list of contributors.

One-way binding vs. two-way binding

I've built single-page applications (SPAs) in Knockout, Angular, and React. The way React thinks about your data and DOM is entirely different.

React uses a one-way data bindings, whereas Knockout and Angular take a two-way data binding approach.

One-way data bindings make thinking about how data flows through your application much more straightforward.

The documentation from the React team will explain it far better than I ever could 👇

(https://reactjs.org/docs/hello-world.html)

Other tech reasons

There are a lot of other factors that make React a great framework choice. We're not digging into those in this post.

It's a business decision

Patrick McKenzie (@patio11) put it best in a 2011 essay called "Don't Call Yourself A Programmer, And Other Career Advice":

Engineers are hired to create business value, not to program things

React provides plenty of value to businesses:

There are plenty of React devs in the job market
The community support and ecosystem make things simpler for my team
It's likely to be around for a long time (in the time scale of JS frameworks lifespans)

It just makes business sense.

Said another way, it's a financially sound decision to use React.

I know it

What matters is your team's efficiency. On side projects, I am a team of one. So my final answer is:

I use React for projects because I know it.

React was my gateway to Next.js.

Evolution of Next.js

I have an idea for an app

Let's start a new project together as an example of why frameworks like Next.js and Gatsby are needed.

Here's our project brief:

Build a website that calculates if you should buy a house or not based on your current finances and the house price.

The app needs to:

take in user data
calculate a result
make a shareable results page

Our requirements sounds pretty simple overall, so we start with create-react-app – the easiest way to start building with React.

create-react-app is a great way to get started with React

We launch our app, and it's a massive success on Product Hunt 🎉

As a result, we decide to double down on our growth and try to market the product a little bit more. So how do we do that? Well, our Lighthouse audits are pretty bad. We also don't have any content pages. Google doesn't know what our site is about because we're not providing any extra content. Fixing those might improve our SEO. Maybe if we do all that, Google might send more traffic our way.

We only have one end goal:

Make the site appear as fast as possible to our users and Google

We start with the basic performance tweaks:

cache as many assets as possible
serve assets from the edge via a CDN
remove bloat from node_modules
lazy load images

These improvements get us part of the way there but don't solve the problem of modern web development: our bundle is too big. Slower computers and mobile phones have a hard time processing all of the JavaScript.

SSR

One solution? Simply process the JavaScript on the server and deliver the HTML/CSS. This is server-side rendering (SSR).

Once the client receives this payload, we can hydrate our React app state in the background. The user (human or Googlebot) sees a faster response and can more easily navigate the page.

If we throw a cache (using Cloudflare or some other provider) in front of our server, we can dramatically improve performance for users who have a cache-hit.

Slowly, people got fed up with implementing SSR. Next.js evolved to fill this pain point.

SSG

Another option is to simply process the JavaScript at build time and only send the client a smaller amount of data. This approach is called static site generation (SSG).

SSG requires a few things:

all data needs to be present at build time
changing the site means regenerating it
longer build times

Depending on the site you're building, these requirements are very doable.

As with SSR, the SSG crowd did not enjoy doing this work, yet it was very essential development. Gatsby evolved to fill this niche.

Note: with getStaticProps, getStaticPaths, Next.js has ventured into SSG + SSR.

(Almost) my first Next app

Back in 2018, I was working at Spreetail. The company was building its own ecommerce experience (instead of its usual B2B focus).

At the beginning of the project, we had decided the Next.js framework was "too green" and didn't pick it (around version 5.1). One engineer was convinced it was the right path, and we (me) didn't listen to him. Sorry, Michael.

My previous co-worker, Stephen, wrote up his heroic effort to migrate months of React development to SSR.

It was a lot of work.

Approaching Server Side Rendering in an Existing React/Redux Application

"We decided to go with a React/Redux application built off of react-boilerplate. Development had already started when I signed on, but I know we considered Next.js instead and ended up choosing not to use it. Looking back, it is much easier to use a framework that already handles server-side rendering. I would bias toward using those frameworks in the future."

I respect Stephen's opinion quite a bit, which led me to investigate Next.js for both work & side projects.

I have used Next.js on every greenfield project since.

Pros of Next.js

Let's dive into some of my favorite parts of Next.js and why it's my go-to framework at work and on side projects.

User (developer) obsession

Listening to pain points

The pull requests in Next.js frequently included links to tweets. I think that's a great sign. It shows they're listening to their customers.

Have a problem with a new version of Next? Tweet at the team. You'll likely get a detailed reply and steps to troubleshoot your issues. Still not working? The dev you were tweeting with will most likely file a Github issue and link to your Twitter thread.

That's phenomenal customer service on FREE software (more on OSS perks later).

Detailed examples

At this writing, there are 231 high-quality Next.js examples in the repository.

From Auth0 to XState, they've got everything you can think of. See something they're missing? Perfect. Next.js is an open-source repository. Commit your example and have the community help you improve it over time.

These examples have saved me countless hours.

Performance

Static === speed

With Next.js adding getStaticProps, getStaticPaths, and creating Incremental Static Regeneration (ISR), Next is becoming an incredible framework for static sites.

I talked about this in the last edition of the newsletter, Next Sites Should Be Static, quite a bit.

HEY – let’s talk about static sites

Note: ISR takes a little bit of configuration and doesn't work by default on all hosting providers. Consider hosting on Vercel if you're interested in this feature.

SSR can be fast (with a cache)

If you're server-side rendering your app, it's likely going to be very fast for your users.

In the example we talked about above, SSR provides:

faster FCP via smaller initial payload(first contentful paint)
better overall page load speed
improved SEO via shipping parseable HTML

A downside of SSR is that it can take the server a while to render the page and respond.

By inserting Cloudflare (or some other cache) in-between your server and your users, you can lower the chance your users have to wait on the server.

Note: this works best for marketing pages and content that doesn't change from user to user.

Business value

SEO

Considering Next.js enables both SSG and SSR (two key methods for improving SEO), Next is a great candidate if SEO is a significant concern for you.

P.s. - If you're building a business, SEO is a significant concern for you.

Developer velocity

Similar to all prior frameworks, Next.js has opinions. Those opinions (good or bad) are baked into the way we use the tool. That might initially sound bad, but I would argue it's great.

By being opinionated, Next.js saves us from implementing basic things and wasting time on the problems that don't matter.

How to implement SSR
How routing should work
What's the best way to split this JS bundle
How should app config work
How to build the site at build time

Next.js has answers to all of these questions.

That means, as developers, we get to focus on the problems related to the project domain. Opinionated frameworks enable us to focus on the product.

Overall, this saves our developers time, our company money, and our brains from decision fatigue.

Continuous improvement (via open source)

Because Next.js is open-source, we benefit from the improvements each individual or company makes to the framework.

Rather than explain the perks of open source software myself, I'll let this Explain Like I'm Five (ELI5) Reddit thread explain.

The takeaway is this: together, we can multiply our efforts to build much better software than we could alone.

Read the full comment below 👇

r/explainlikeimfive - ELI5: What is open source software and why is it such a big deal?

Cons of Next.js

If you're new to the Next.js ecosystem, you likely will not find these as controversial as they once were. If you've been here for a while, let's take a trip down memory lane.

Framework whiplash

With a team that listens takes developer feedback quite literally, there are bound to be some changes.

A few notable changes are:

pivoting from SSR first to SSG
removing hosting support for custom servers
adding api functions

The Next.js team added these changes after listening to developer feedback. The problem is, some developers had already come up with bandaids to deal with these problems. Years later, these devs are dealing with bandaids leftover from the early days of the framework (AKA tech debt).

Framework whiplash is a common problem for all fast-moving frameworks, which Next.js definitely is.

Some dislike file-based routing (or some other opinion)

One of the gaps that React left was routing. Since they focus purely on the "V" (view) part of MVC, many different options appeared for dealing with routing.

Not supporting React Router out of the box was a controversial stance Next took in the beginning.

While there are plenty of great routers out there for React, I think Next Router is a great choice. File-based routing is simple to understand for both new developers and Next.js experts.

As I said earlier, Next.js having opinions saves us time and stops us from debating the minutia.

getInitialProps can be tricky

There are quite a few convenience methods that Next.js adds to the React paradigm:

getInitialProps
getStaticProps
getStaticPaths
getServerSideProps
reportWebVitals

I agree that they can be hard to learn. I 100% think they are worth learning anyway. They will greatly improve your productivity and the team has put together amazing supporting documentation.

What about?

Gatsby

Gatsby is a great tool – my personal site with my essays was created with it. The reason I still choose Next.js on most products is Next can handle both SSG and SSR.

When would I still pick Gatsby? If I was building a content site and found a Gatsby theme I really liked. The theme and plugin ecosystem in Gatsby is great. I created my personal site with the help of a Gatsby theme.

narative/gatsby-theme-novela

Vue and Nuxt

I hear amazing things about Vue and Nuxt. I'll certainly be exploring them in the future. I would love to hear about your experience with Nuxt.

Create React App

Time to answer the age-old question: can't I just use create-react-app?

Yes, feel free. Create-react-app is a great tool.

Re-read the "I have an idea for an app" section of this post before venturing too far down this path. If you think you will need SSR or SSG at any point in your project, I would encourage you to start with Next.js first.

Conclusion

Next.js is an excellent framework for React developers building static or server-side rendered sites. The popularity of React helped boost Next. The Next.js team solves common problems with elegant solutions that are almost indistinguishable from magic.

What a time to be a developer.

Newsletter plug

I hope you enjoyed this analysis. I do a longer post like this once a month and send out more brief updates about Next.js on the other weeks.

Here is last week's:

HEY – let’s talk about static sites

Let’s dive into all the releases since Next.js 9.4.0 including canary commits. This post also features JAMstack Functions, a useful resource while building a Next.js app.

Thanks for reading!

Sent my first NextJS Newsletter (v 9.4 overview)

drew.tech — Mon, 15 Jun 2020 22:40:50 +0000

I've been wanting to start a newsletter about NextJS and finally did it this weekend.

I'm using ghost to host the site, it's a super awesome tool. V3 even has support for "membership" which is what I'm using.

https://ghost.org/members/

I send out emails the morning the newsletter goes out. At the same time, the blog post goes live. It's seriously awesome.

I'd encourage all devs to think about using no-code tools to run content-heavy sites.

In the newsletter I cover:

summaries of framework changes
cool new projects that use/integrate with NextJS
high-quality blog posts from the community
useful NPM packages
??? still looking for more content categories

My first post is archived here but I'm putting the content below as well.

NextJS 9.4 overview

Welcome to the first edition of NextJS Notes!

The last big change to the NextJS framework happened on May 11th. Version 9.4 was released and included amazing features mostly focused at improving developer experience.

Before we get started, here's a quick reminder on a somewhat recent security vulnerability.

If you are:

using a version below 9.3.2
not targeting serverless

You need to update to > 9.3.2 as soon as possible. Check out the security warning here.

As a starting point for this newsletter, let's dig into the changes 9.4 brings.

NextJS 9.4 overview

React Fast Refresh
When you make a change in your editor, you keep application state. No more scrolling down to the correct spot on the page after fixing a typo.
An interesting point on Fast Refresh is that it took a lot of community support to make it happen. The NextJS team helped, as well as contributors from React and Webpack.

Better environment variables configuration
I'm very excited for these updates. NextJS environment variables have been the cause of much pain (myself included).

You no longer have to add a next.config.js and add the env key to expose these variables. - NextJS 9.4 Blog Post

Want your vars exposed to the browser? Prefix them with NEXT_PUBLIC_.
Automatic .env support - no need to pull in dotenv into every NextJS project anymore 🎉
Read more about the environment variable changes here.

Incremental Static Regeneration (beta)
Incremental static regeneration is a game-changer. It's joining beta at the moment, so don't throw it in production yet (or do 🙂).

How does incremental regeneration work?

Imagine if each of your server-side-rendered (SSR) pages was statically output to a CDN and served each time (given that the request doesn't change). That is basically incremental static regeneration (ISR).

It's going to change the way you create your site. Most importantly, it's going to change the performance of your site.

Speaking of performance, let's dig into Web Vitals 👇

Web Vitals reporting
What are web vitals? Google is creating a new set of standards for how pages should behave. Vitals are similar to Lighthouse audits but focus on slightly different targets.

Given Google's recent dedication to these metrics, I wouldn't be surprised if they are already playing a big part in their search algorithm. Better get to fixing these to maximize your SEO!

Built-in fetch support
If you upgrade to NextJS 9.4, be sure to throw out those fetch polyfills for the front end. Create your TECH DEBT Jira ticket tomorrow as NextJS includes them by default.

Absolute import aliases
Cleaner code is better code. Absolute paths are a great way to handle super long import paths. You don't have to use this feature, but if you set it up, expect to clean up some of those really long relative import paths.

Example:
The best use case I can think of is a utility file (/utils/foo-helper.js) that needs to be imported deep in the components folder (/components/.../Component.js).

This feature will clean that up nicely. Read more about it here.

Better logging
The dev console gets way less noisy. Here's a before and after:

Updated CMS examples
The NextJS team updated some of the CMS examples more clearly explaining how to statically generate content against the individual CMS APIs.
Great news for you if you use any of these:

Contentful
DatoCMS
Prismic
Sanity
TakeShape

Deep dive
Incremental static site regeneration is awesome, but it can be a little hard to wrap your mind around.

Static tweet example

Luis Alvarez (@luis_fades) put together the above example that shows its benefits.
The first sentence of the RFC makes the goal of ISR clear.
Fully automatic re-rendering of statically exported pages without a full rebuild.
This means a couple of things:

To use ISR, your page needs to be static
ISR saves on rebuilds

If you're tired of waiting on your CMS change to rebuild your entire app, this feature is for you.

Want to learn more? Check out the RFC and docs below 👇

RFC

So do you think you understand ISR? Arunoda Susiripala (@arunoda) made a blog post explaining it that even has quiz questions! Check it out below.

What is incremental static (re)generation

Useful package of the week
The new Web Vitals reporting function in NextJS uses an open-source package from the Google team that reports web vitals (link)

This package is not limited to NextJS apps and can even send the data to your analytics provider (Google Analytics in this case).
NextJS analytics example
Other app analytics example

Thanks for reading!

This is the end of the newsletter

If you enjoyed it, consider signing up here

How to build your own blog in 2020 today

drew.tech — Thu, 23 Jan 2020 19:55:08 +0000

Why I'm blogging

I'm blogging to improve my writing, increase the clarity of my thoughts, and show what I'm working on.

With each blog post, I feel like a slightly better communicator and better teacher.

The compounding effect of continuously improving is staggering.

The trick to seeing these gains is consistency and playing for the long term.

The purpose isn't to please the critics. The purpose is to make your work better. - Show Your Work, Seth Godin

So which platform do I use?

I've started a Blogger blog (this was before Google bought them). Remember .blogspot.com domains?

I built a couple different WordPress blogs, both free and self hosted.

I've started company engineering blogs, internal and external.

I tried building my blog from scratch.

Medium, Confluence, Twitter, LinkedIn, Blogger, Dev.to, WordPress, self-hosted, doesn't matter.

Pick a tech stack and platform that you will help you write consistently.

The trick is getting posts out there, improving over time, and staying in the game.

Using my experience and following principles from James Clear, Tim Ferriss, and more, I've come up with a few rules for starting a blog as a developer in 2020.

I'm building my own blog that uses GatsbyJS hosted over at drew.tech

Principles

1. Stick with what you know

We need blogging to be one of those habits we actually stick with. In order to do that, we need to make it
as simple as possible.

To remove friction in the process, we should stick with:

a platform we know
a familiar tech stack
content you're somewhat familiar with

Example

I'm comfortable in React, JavaScript, and markdown. I've built a GatsbyJS site and am familiar with GraphQL.
I'm not great at styling, so this blog is a Gatsby theme called Novela.

Counterpoint

Want to use your blog as a project to learn some new tech? Want to explore new topics you know nearly nothing about?
That is okay. Just know that it's likely blogging won't be a sustainable habit for you.

2. Easy deploys

This one sounds really simple, but it can make a big difference on if you are or aren't going to post regularly.

Deploying needs to be simple. If it's not, you won't post. Dragging files to an S3 bucket does not count as easy.

You might think I am lazy because of this. Trust your instincts.

Example

I can deploy all of my side projects via pushing or merging changes to the master branch in GitHub (I commit on master frequently 🤠). Each time I push, a new version gets deployed.

Zeit Now and Netlify take care of a lot of the hastle that is devops.

I use Zeit Now for all NextJS and Netlify for all my GatsbyJS.

Counterpoint

There are no excuses for bad CI/CD 😉

3. Don't build from scratch

Starting from scratch can seem tempting; don't.

Lean on existing frameworks like NextJS and GatsbyJS that get you started with built in routing, performance optimization, and a plugin ecosystem.

These things will help you spend more time writing, and less time tweaking code. I'm all for tweaking code, but you're here to create a successful blog,
not to fiddle with code.

Example

This blog relies heavily on:

GatsbyJS
Gatsby Theme Novela
gatsby-plugin-google-tagmanager
gatsby-plugin-twitter
gatsby-plugin-sitemap
gatsby-plugin-mailchimp
gatsby-plugin-feed
[ConvertKit](https://app.convertkit.com/users/signup?plan=free-limited&lmref=l_QK4w

) (get started for free)

That's a lot of coding hours saved that I can use directly on writing.

Counterpoint

Like I've said before, feel free to use your blog as a playground for learning.
If that is your goal, that is okay. It isn't the best approach for creating a
consistent writing habit.

4. Collect blog topic ideas

In order to write a blog post, you need topic ideas. Instead of sitting down and thinking "what do I want to write about?",
pull up your list of ideas and write about what you're most inspired by at that moment.

Here's how I've built my list:

Googled something and couldn't find the answer
Found an answer, but it was buried deeeeep in a forum
Notes from a good book or podcast
Predictions
Learning in public and documenting

This list is different for everyone and depends on what type of content you want to share.

5. Less is more

I had a different UI on my previous blog. It had a lot going on. I removed all the distractions and "features" as a test.
People actually spent more time on my site the fewer "features" there were.

By not creating extra features on your blog, you free up yourself to spend more time writing content.

And you know what they say:

Content is king.

Ready to get started?

Click the Deploy on Netlify button below
Connect your GitHub account
Deploy
Celebrate 🎉

CCPA: Are you making changes?

drew.tech — Fri, 17 Jan 2020 00:42:14 +0000

CCPA went into effect January 1 for California residents.

Are you / your company doing anything about it?

How to Create a Cron Job with Next.js and Vercel

drew.tech — Sun, 05 Jan 2020 12:00:00 +0000

I want to remind myself of my New Year's resolution every day via text.

Why? None of those productivity apps have ever worked for me. I don't open them. I want to be reminded in an app I use every day, iMessage. Let's solve this with cron jobs, a Twilio API call, and Vercel hosting.

Lot's of apps use cron jobs. In the past, I've setup cron jobs on linux servers to process orders, send notification emails, and run expensive SQL queries. Think of it as a list of tasks your server needs to run and the frequency to run them. It's pretty simple to setup and is even shipped with Mac OS & Linux (check out crontab).

But how do we run cron jobs in Vercel deploys? - You, right now, in your Google query

There are five quick steps you need to run cron jobs in a Vercel NextJS app.

1. Start your project

To create a quick NextJS project, I used create-next-app mentioned in the NextJS docs.

You'll want to make sure you have:

a pages folder
an api folder inside the pages folder

2. Add your logic

Then, make sure you have a /pages/api/text.js (or do it in TypeScript for bonus points 😎).

Note: there's no need to follow the rest of this step, unless you're building a resolution reminder app just like me.

Here's what mine looks like:

If you're going to use TypeScript, follow the NextJS guide to converting the initial project to TS.

Here's the link to the example code: text.ts. You will need to install the following packages as well: package.json.

3. Add some security & deploy

Every project needs a little security. For this project, let's make sure our API route is requiring some auth. See the part where we are checking for superSecretAPIKey? You should come up with your own secret and save it for later. We're going to be using that in step number five.

To deploy to Now, follow this guide to deploy with the CLI.

4. Create a cron job

This isn't truly going to be a cron job. We're going to be using EasyCron.com. They have a free tier that's sufficient if you're fine with not adding security (you can't change headers in their free plan).

note: these EasyCron links are referral links. Here is a non-affiliate link - https://easycron.com

Here's what we are trying to achieve:

5. Finish the security (optional)

Like I said, every app needs some security. In order to be secure with EasyCron, I recommend adding authorization headers to your HTTP call from within the UI.

Add an Authorization header to your call with the following:

This is adding some security, but is not the best option. If you need to really secure your endpoint, I would recommend different approaches.

And that's it!

Congrats, you setup cron jobs inside of a serverless NextJS app hosted with Vercel. Please let me know if you ran into any problems!

Follow @DBredvick

Good luck on those resolutions 💪💯

DEV Community: drew.tech

Hey CTO — A Core Web Vitals Strategy for your business.

Hey there, CTO!

How might we...

First, what are Web Vitals?

Cumulative Layout Shift (CLS)

How is CLS measured?

Largest Contentful Paint (LCP)

How is LCP measured?

First Input Delay (FID)

How is FID measured?

Why are Web Vitals important?

Site performance

User experience

SEO (soon)

How to Track Web Vitals

Lighthouse & PageSpeed Insights

Chrome Extension

Google Search Console

CrUX API

DIY Tracking (send to GA)

Sitemap based or traffic based

How can we Monitor our scores?

Build vs. Buy?

A basic version

A complex version

Final recommendation

The end

Is this a problem your company is having?

How to declare Twitter DM bankruptcy

Why declare DM bankruptcy

The steps

1. Write a tweet

2. Pin your bankruptcy tweet

3. Create an automated DM with Twitter's API (optional)

First, what's a Twitter welcome message?

Set up Twurl

Apply for Twitter developer access

Generate tokens

Authorize Twurl

Create your welcome message

Creating a welcome message rule

Is there an easier option?

I built a Next.js job board with Next. Find your Next JS dream job!

The content, updates, and setup

The community

The realization

The product

Next.js Conf Highlights

Next.js 10.0

Next.js Image optimization

Next.js Internationalization

Next.js Analytics

Next.js Commerce

Other updates

FAQ

Conclusion

Monitoring performance in Next.js

Each 100ms decrease in homepage load speed increases session conversion by 1.11%

1. Money

2. UX

3. SEO

4. Tech debt

Monitoring Core Web Vitals in Next.js

In the lab

Setting up automated Lighthouse audits

What's the catch?

In the field

Setting up field tracking of Core Web Vitals in Next

Setup a Google Analytics property

Install analytics

Configure analytics

Configuring _app.js

Success?

Optional: set up alerts

Conclusion

Learn more

Rome wasn't built in a day, and neither was my SaaS app

Building Rome

So I'm no where near finished yet.

Install `analytics`