DEV Community: Meet Dave

domstat - A Puppeteer based CLI tool to check web performance

Meet Dave — Tue, 02 Aug 2022 14:30:00 +0000

domstat is a Puppeteer based CLI tool that runs locally and checks for webpage performance statistics.

Domstat consolidates select Chrome dev tools statistics at one place and gives a bird's eye overview on how a webpage performed at runtime.

Source code

To run this, you should have node & npm installed on your machine. You can do so by downloading node.js

Using npm

npm i -g domstat 
domstat --url=example.com

Alternatively, using npx

npx domstat --url=example.com

Plot

domstat parses the browser-level API numbers like DOM user timings & code coverage. Similar to httpstat for cURL related information.

domstat also takes inspiration from this web.dev article which gives an in-detail explanation about measuring critical rendering path using the Navigation Timing API.

How does domstat help?

Let's take a look at a scenario where we want to check and compare the dom timings & coverage for different websites.

Below are the domstats for optimised "movies" web application in different frameworks. You can find the repositories on https://github.com/orgs/tastejs/repositories

Angular:

Next.js:

Nuxt:

All of the above movies web application score a 90+ on Lighthouse / Pagespeed audit, domstat on the other hand leverages the browser's API and helps further by giving insights about the loading behaviour.

These statistics are available on the Chrome's devtools but they aren't consolidated at one place. Example: The CSS & JS coverage statistics are present in the Sources tab, to get the DOM timings, you need to run the Performance audit from the Performance tab and so on.

Domstat consolidates all these numbers at one place and gives a bird's eye overview on how the webpage performed.

By default the tests don't have cpu or network throttling yet but I wish to add more such flags soon.

Building the CLI

The CLI is built using React. Yes, React! Seems that React can do a lot of things. From Desktop apps with Electron to a fullstack app with Next.js.

I used create-ink-app to build the CLI tool. The create-ink-app spins up a basic project structure for Ink apps and lets you avoid the boilerplate and get to building beautiful CLIs in no time.

Checkout ink to know more about writing CLI tools with React :)

Closing notes

I've been using the Chrome DevTools to check site's performance, running tests to check and compare runtime performance of different pages.

This CLI tool is a step closer to knowing the APIs well, the tools gives quick insights and saves the hassle of clicking around the already overwhelming browser's dev tools.

There's a good potential for improving the tool further & if you're familiar with the Node.js ecosystem and React, you're most welcome to contribute to make this better.

The goal isn't to make another lighthouse like tool, but only to consolidate the important scattered statistics from the browser's API at one place, using one command.

Extending Next.js' component to improve UX

Meet Dave — Mon, 22 Nov 2021 14:09:55 +0000

If you have worked on Next.js, it's a good chance that you might have ended up using the Image component.

While the Next's Image component already has a lot of built in features like blurring placeholder images when the images are loading or controlling image quality to improve the UX.

In this article, we explore extending the Next's image component to improve the end user experience alternatively.

Plot

Here we address 2 main states when serving images

1. Loading state

Lazy loading images contributes to better UX since it helps in reducing the load time among other things, however, to improve it one step further we add something like an intermediate form of display until the image loads. For example, spinner or a skeleton loader

2. Errored state

What happens if the image url is incorrect or if the image service API is down for some reason? It would be ideal to have a fallback image so the end user has a seamless experience and doesn't end up seeing something like this.

When using Next.js' Image component, it is important to wire it up with a fallback image because of domains.

After we've taken care of these 2 states, the solution ends up looking like this:

ImageWithState

Let's dive in and extend the Next.js' component to further support the aforementioned states.

Starting with the main imports



import React from 'react'
import Image, { ImageProps } from 'next/image'

Now, we create a React component that simply extends the Next's Image component & also the types




type ImageWithStateProps = ImageProps

function ImageWithState (props: ImageWithStateProps) {
  return <Image {...props} />
}

So far, we've done nothing other than adding a transparent abstraction over the Image component. The component ImageWithState will work same as Next's Image, only that the component name is different.

Let's now introduce the states




function ImageWithState (props: ImageWithStateProps) {
  const [loading, setLoading] = React.useState(true)
  const [onErrorSrc, setOnErrorSrc] = React.useState<string | undefined>(undefined)

  return <Image {...props} />
}

When the component mounts, loading is set to true by default as the image would start loading

The onErrorSrc prop is the source url for the fallback image. The fallback image appears when the Image component throws an error. Let's go ahead and create the function to handle the errored state




 function handleOnError (e: React.SyntheticEvent<HTMLImageElement, Event>): void {
    e?.currentTarget?.src !== props.fallback && setOnErrorSrc(props.fallback)
  }

This is triggered by the onError event



return <Image {...props} onError={(e) => handleOnError(e)} />

The handleOnError function is called when the component would error. In that case we change the src prop of the element to the fallback image.

Now, we manage the loading state




  return (
    <div style={{ position: "relative" }}>
      {loading === true && (
        <SkeletonLoader
          style={{
            position: "absolute",
            zIndex: props.debug === "true" ? 99 : "auto"
          }}
          height={props.height}
          width={props.width}
        />
      )}
      <Image
        {...props}
        src={onErrorSrc || src}
        onLoadingComplete={() => !props.debug && setLoading(false)}
        onError={(e) => handleOnError(e)}
      />
    </div>
  );

To represent the loading state, I have used SkeletonLoader component. Feel free to use any other loading indicators like spinners or splash based on your use case.

Furthermore, there is a debug prop which can be helpful when developing & styling to check if the loading indicators are styled appropriately.

Mostly images are served from disk cache, in that case it becomes difficult to replicate a "loading" state for an image while developing. In such a situation, enabling the debug prop would provide a much efficient dev workflow than network throttling via the browser's dev tools.

If you haven't noticed yet, we pass the same height and width prop to the skeleton loader. This also further helps in avoiding layout shift as the space will be preserved for the image.

Finally, updating the type



type ImageWithStateProps = ImageProps & {

  fallback: string;

  debug?: string;

};

Usage

Using the wrapper component should be same as using the Next's Image component.

The ImageWithState component added 2 extra props which are for the fallback image in case of an error & a debug prop to help us make sure that the skeleton loader displays appropriately

Feel free to fork or play around this component on CodeSandbox

You can also visit https://f1icr.csb.app/ to check out the working solution

Caveats

Build size: These changes, including adding the svg skeleton loader library which is react-skeleton-loader adds approximately 5kB to your production build. But keep in mind that this component is reusable across your entire app so the build size won't bloat up further

Web vitals: Next's Image component loads the images lazily by default. If you're loading the images above the fold, remember to pass the priority prop so the page doesn't lose out on LCP points

Blur: It's possible to display a blurred image placeholder when the image is being loaded. This is supported by the placeholder property on the Image component.

Unoptimized: You may have seen an unoptimized true prop passed to the Image component. This is because I haven't setup any loader configuration for these images. Make sure to keep your images optimised and pass srcSet, (now device sizes in Next.js) & responsive images in modern image formats!

Conclusion

Presently, Next.js' Image component only supports displaying a blurred placeholder when an image is being loaded, something like what you may have seen on medium.com.

As one solution doesn't fit all use cases, this write-up represents an alternate way to wire up the Image component while still keeping the end user experience in mind.

CI/CD tooling for frontend projects using GitHub actions

Meet Dave — Fri, 23 Apr 2021 09:58:41 +0000

Setting up continuous integration pipelines for your frontend project can help you avoid bugs & filter out problems sneaking into production.

Photo by Nathan Dumlao on Unsplash
Filtering out the best for your end users 👆

Having CI/CD in your frontend project from the beginning can help in avoiding “broken windows“ in your project (ref: broken window theory).

Additionally, setting up the workflow can help significantly improve developer experience (DX) & user experience (UX)

A pipeline that is setup early on in the project can help the team work with a unified purpose & set guidelines.

Plot

This article demonstrates a continuous integration pipeline setup for a starter Next.js app deployed on Vercel living on a Github repository. The pipeline makes use open-source Github actions from the Github marketplace.

The CI jobs runs synchronously. If a job fails, the process would exit.

For this article I have chosen to setup the following jobs:

Linting (eslint + stylelint) - Helps with consistent DX
Vercel deployment - Helps with deployment previews useful for CI
Lighthouse budget checks - Helps in UX integrity & maintain consistency throughout the software lifecycle

Additional jobs you can add in your CI pipeline:

Send slack notification if a job fails
Run Cypress tests / Jest tests against preview urls
Setup semantic versioning / semantic release

If you find yourself using something else than the options I have chosen above. Here are some reasons why I have opinionated myself with the selected tools for this example:

Why Next.js instead of Angular, Nuxt.js, etc?
Next.js gives flexibility to statically generate a page and / or use server side rendering. Smaller overall bundle size helps in achieving better UX.
Why Vercel instead of AWS Amplify or Netlify, etc?
Deployment previews! Each PR generates a deployment preview URL. Makes it easy and efficient to run E2E tests or Lighthouse checks against a preview URL. Also since I’m using Next.js.
Why Github actions instead of Gitlab or Bitbucket, etc
Ability to use and/or write open-source Github actions.

1. Getting started

In this example I’m setting up the CI pipeline for a boilerplate Next.js app.

npx create-next-app

After the boilerplate next app is generated, I initialise the ESLint setup:

eslint —init

ESLint initialisation will take you through a set of questions and help you set up the correct lint rules for your project. It automatically generates the configuration file & installs the dependencies.

For linting styles, I mainly prefer using stylelint, helps in enforcing css / scss conventions & avoid errors for stylesheets. Equivalent to using ESLint for Javascript files. Read more about configuring stylelint for your frontend project.

If you are writing styles in CSS-in-JS land, stylelint has a styled-components extension that you can configure as well :)

Finally, add the lint check scripts inside the package.json file so we can set it up with our CI pipeline next.

2. Creating the Github actions workflow

To write the Github actions, we need to create main.yml workflow file inside .github/workflows/

In this CI example we have 3 jobs in our workflow.

Lint source code (ESLint + Stylelint)
If no lint errors then -> deploy on Vercel
If deploy build is successful then -> run performance check with Lighthouse

We get started by defining that the jobs should run whenever there is a PUSH event on any branch.

name: CI
on: [push]

Based on your use-case, you can also chose to have different events. Checkout the different events that trigger a workflow

3. Setup the linting job

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - name: Begin linting
        uses: actions/checkout@v2
        with:
          fetch-depth: 0

      - name: Use Node 12
        uses: actions/setup-node@v1
        with:
          node-version: 12.x

      - name: Use cached node_modules
        uses: actions/cache@v2
        with:
          path: node_modules
          key: nodeModules-${{ hashFiles('**/yarn.lock') }}
          restore-keys: |
            nodeModules-

      - name: Install dependencies
        run: yarn install --frozen-lockfile

      - name: Run ESLint
        run: yarn lint

      - name: Run stylelint
        run: yarn stylelint

This job checks if the code / changes adhere to the lint rules. As you can see, the job checks for eslint and stylelint problems.

To improve the DX and catch these lint issues while developing, it’s best to setup your IDE with the respective plugins. Since I use VSCode, here are the eslint or stylelint plugins that I use. I also like to set up the format on save in the VSCode settings.json file to automatically format & fix all fixable problems when I hit save.

4. Generate deployment previews with Vercel

deploy:
    runs-on: ubuntu-latest
    needs: lint
    steps:
      - uses: actions/checkout@v2
      - uses: amondnet/vercel-action@v20
        id: vercel-deployment
        with:
          github-token: ${{ secrets.GH_TOKEN }}
          vercel-token: ${{ secrets.VERCEL_TOKEN }}
          vercel-org-id: ${{ secrets.ORG_ID}}
          vercel-project-id: ${{ secrets.PROJECT_ID}}
          vercel-project-name: 'nextjs-tooling'
    outputs:
      preview-url: ${{ steps.vercel-deployment.outputs.preview-url }}

This job makes the use of the opensource GitHub action: Vercel actions
The opensource action makes it easy for us to generate Vercel deployments, whether they are preview deployments or production deployments.

Here, we are also checking if the production build succeeds or not since we are making a deployment.

Using this action in the CI pipeline is better than setting up the Vercel for Github Integration, since the Github integration is asynchronous and runs independently of the pipeline state.

Once the deployment is complete, Vercel generates a preview-url.

You may chose to run Cypress tests against the preview-url. In this article, we will be setting up the Lighthouse job which will make use of this preview-url.

5. Run Lighthouse budget checks against the deployment previews

lighthouse:
    runs-on: ubuntu-latest
    needs: deploy
    steps:
      - uses: actions/checkout@v2
      - name: Run Lighthouse on urls and validate with lighthouserc
        uses: treosh/lighthouse-ci-action@v7
        with:
          urls: |
            ${{ needs.deploy.outputs.preview-url }}
            ${{ needs.deploy.outputs.preview-url }}/some-other-path
          budgetPath: ./budget.json
          runs: 3

This job makes use of the opensource treosh/lighthouse-ci-action Github action. The action makes use of the Lighthouse CI and audits our deployments. The action allows us to set numerous options like

testing against multiple paths
providing a budget path
number of runs (how many times the CI should audit an URL?)
and many more ..

In this job, setting up a budget is the most important task. As you may have known, with the Google page experience update coming up in May / June 2021, Lighthouse scores and page speed performance are going to be prioritised in search rankings.

Therefore, setting up this Github action would help immensely for websites that rely on Google search traffic. If not taken care of in the early stage, it’s quite normal for the bundle sizes to bloat up as a website is iterated, then that results in a lower lighthouse score. This Lighthouse Github action helps us keep an eye on any discrepancy in every commit.

Based on your project, it can also be important to setup a correct Lighthouse budget. The budget for the example repo is: https://github.com/snowballdigital/nextjs-tooling/blob/main/budget.json

6. CI in Action

Working Github repo: https://github.com/snowballdigital/nextjs-tooling

Now we have all 3 jobs setup in the CI pipeline, on each push to a branch the following 3 jobs would run like so:

Additionally, if there is a PR, vercel-actions will comment on the PR once the preview URL is deployed successfully.

In conclusion

Simply, any commit which violates your CI rules will not make it to production. And in the 3 jobs we have defined in this article has a core focus on UX and DX.

These pipelines setup are best suited for any frontend project since the successful pipelines give you that the extra finesse and assurance to deliver a solid, consistent end user experience & also an improved developer experience for your team & co-contributors.

Interested in building lightning fast web applications on React? We’re in search for senior frontend developers, Apply here!

HTML autocomplete value for "city"

Meet Dave — Wed, 31 Mar 2021 13:14:58 +0000

Plot

A few days ago I was building a form in React that would take in user's address fields such as address lines, postal code, city, country, etc.

Following some practices, I wanted to make use of the HTML's native attributes such as autocomplete, placeholder, inputMode, etc. on form fields as that would result in a good end user experience.

The autocomplete attribute provides an automated assistance in filling out form field values, as well as guidance to the browser regarding the type of information to expect in the field.

Generally, when the autocomplete attribute is not provided, the input field suggestions are random, and up-to the browser.

Why this blog post?

While implementing the autocomplete attribute for an address form, I referred to the web development bible: The MDN, specifically the docs for the autocomplete attribute

Surprisingly the docs don't mention the value for autofilling a "city" input field.

Solution

After some research I stumbled upon the correct usage for autofilling a city field:

<input
  type="text"
  autoComplete="home city"
/>

Conclusion

After using the autocomplete attribute for my form fields, I was conscious about this browser feature whenever I would visit other websites to fill out forms.

Astonishingly, I see that many large scale websites / brands don't use this attribute yet 😐

I also noticed the payment gateway providers make good use of the attributes (like: autocomplete="cc-number") that help in autofilling appropriate credit card information 🤔

Now, whenever I'm building forms, a typical input field would have the following attributes / properties.

<input
  id="personalNumber"
  autocomplete="tel"
  placeholder={t(`contractFormPlaceholders.personalNumber`)}
  type="number"
  inputMode="decimal"
  required
/>

As you can see, the input field is using much of assistive native HTML features & not relying on javascript (example for input validations).

Do you make use of any other native HTML attributes that further improve the end user experience than the one's mentioned above? Feel free to voice some helpful one's in the comments below 👇

Cheers!

Handling runtime errors when server side rendering with Next.js

Meet Dave — Wed, 10 Feb 2021 16:44:01 +0000

Avoid bad user experience by exploring different ways to manage runtime errors with Next.js

Intro

If you are working with Next.js, there is quite a good chance to bump into internal server errors (5xx) when on production. If not handled correctly, a single error can bring down the complete page. Imagine a user shopping online for their favourite gadget and they end up seeing this page resulting in a bad UX.

Nextjs shipped SSG support with version 9.3 and brought in a lot of positives. For instance: getting errors at build time rather than runtime. Switching from SSR to SSG, ended up in an amazing user experience as everything was statically generated before the site was deployed.

However, in some cases, we still require our website pages to use server side rendering (SSR) instead of static site generation (SSG). Example: checking if the user is logged in or not?

Plot

In this article, let’s take a look at a typical error, the “TypeError“

Consider our web-application consuming data from a CMS. At some point the marketing team tries to change a property and they accidentally end up removing one. Or, for the sake of this article let’s consider the CMS backend server goes offline. We fail fetching the data from the CMS and the TypeError is born.

This example considers a scenario when your webpage uses Server side rendering.

The source code is spun out of a simple next.js boilerplate, Deployed on https://ssr-error-handling-git-main.meetdave3.vercel.app and available on Github: https://github.com/meetdave3/ssr-error-handling

Let’s take a look of ways how can we avoid a webpage from crashing in production?

1. Error boundary

function Tile(props) {
  return (
    <ErrorBoundary FallbackComponent={ErrorFallback} key={props.id}>
      <a key={props.id} href={props.link} className={styles.card}>
        <h3>{props.error.title} &rarr;</h3>
        <p>{props.para.para.para}</p>
      </a>
    </ErrorBoundary>
  );
}

Since we’re using React, we are aware of using error boundaries as React exposes getDerivedStateFromError or componentDidCatch lifecycle methods so we can handle the runtime errors.

These lifecycle method won’t run in Next.js as componentDidCatch does not work when using SSR

If an error occurs in the Error Boundary, the webpage will simply throw a internal server error (500) and result in an errored page.

So if you are using error boundaries to handle runtime errors & if an error occurs on production, the page will render like so: https://ssr-error-handling-git-main.meetdave3.vercel.app/error-boundary

You will see a 500 internal server error. Yes, it’s annoying and we don’t want our end users to see it either.

2. Try ... catch

When server side rendering, Our old friend Try … catch is a good replacement to the error boundary as it works expectedly on server side, helps us avoiding the annoying 500 internal server error.

You can wrap your risky component with a try catch like so

function Tile(props) {
  try {
    return (
      <a key={props.id} href={props.link} className={styles.card}>
        <h3>{props.title} &rarr;</h3>
        <p>{props.para.para.para}</p>
      </a>
    );
  } catch (e) {
    // Send to an error monitoring solution or log it.
    return null;
  }
}

Check: https://ssr-error-handling-git-main.meetdave3.vercel.app/try-catch

and you can see how the complete page doesn’t crash any more

3. Optional Chaining

function Tile(props) {
  return (
    <a href={props?.link} className={styles.card}>
      <h3>{props?.error?.title} &rarr;</h3>
      <p>{props?.para?.para?.para}</p>
    </a>
  );
}

This method is the best case from all the options when we want to solve a TypeError. It’s minimal, it’s fast, still it can only help us in accessing chained properties without throwing any error.

Conclusion

It’s not necessary to use any of these methods if you are statically generating the site (SSG)

Why? Because we will get the TypeError at build time when running next build and a production build won’t be created.

When using SSR, we need to fallback to the try .. catch solution when we are trying to do something more error prone like calculating the total tax of the shopping basket when rendering the checkout page.

It’s best to use a mix of optional chaining and try catch to avoid server side errors. Avoid falling into the trap of using React error boundaries when creating a server side rendered page.

Styled components vs Emotion js: A performance perspective

Meet Dave — Wed, 19 Aug 2020 20:28:46 +0000

This article demonstrates the bare minimum difference on build size when using a css-in-js library & it's performance implications.

Ever wondered how your styles make it to the browser when using CSS-in-JS library like styled-components or emotion?

When we're defining our styles, we're actually creating a normal React component that has the styles attached to it. This means we are shipping the styles in a .js file rather than a .css file.

We're going to take a look at build sizes for the two most used CSS-in-JS libraries: emotion.js vs styled-components.

Apart from page rendering performance, build sizes directly affect the load time. Shipping large builds will naturally have lower load times & an increase in site's time to interactive. If the website relies on traffic from organic search and PPC campaigns, page speed is an important factor.

In my setup, I spin up a Next.js boilerplate. We can do this by running

$ npx create-next-app

$ yarn create next-app

Boilerplate build

Now, without doing any further changes, Let’s create a boilerplate production build.

We have 61.1 kB of FIRST LOAD JS.

Plot

In this assessment, We only add a styled header component which we create in the component.

mycomponent/styles.js

export const Header = styled.h1`
  color: blue;
`;

mycomponent/index.js

import { Header } from './styles';

const MyComponent = () => <Header>Styling this component with emotion-js</Header>;

export default MyComponent;

Versions used:

"react": "16.13.1"
"@emotion/core": "10.0.35"
"next": "9.5.2"
"styled-components": "5.1.1"

Let’s go!

First up - styled-components

We have a 20% increase in our build size right away.

One can argue that a 13kB increase does not make any difference, however, in page speed performance - milliseconds matter & so do the amount of bytes we ship across the network.

Let’s take both builds on a test drive and deploy them on Vercel.

After deploying, I ran a page speed comparison on https://developers.google.com/speed/pagespeed/insights/

Results:

19% difference in Time to interactive
28% difference in First contentful paint
And 2 points skimmed off from the page speed score

Apart from the build sizes, the other performance hit is “rendering“ & “react re-renders“. The CSS-in-JS libraries depend on a runtime that helps them dynamically update the styles of a component. The CSS-in-JS libraries don’t create CSS classes at build-time, but instead dynamically generate and update style tags in the document whenever a component mounts and/or has it's props changed, making it favourable for theming & complex use of css with React.

If there’s such a difference in the tiniest example possible, an even more complex app can have heavier build sizes. Also, since we’re shipping our styles in a javascript file, it’s evident that increasing the number of styled components will increase the build size and hence reduce the page speed.

Next up - Emotion.js

Emotion.js performs slightly better than styled-components.

Here’s the Page speed comparison for both the libraries -

In terms of build size, we can see emotion js stands somewhere midway between a plain boilerplate and styled-components.

After working with both the libraries extensively, I did not find a big difference in the JS APIs. There wasn't much difference in developer experience (DX) as well. If you’re using an older version of styled-components, your build sizes will tend to be much larger. Lately, the styled-components team have bridged the gap by reducing their build sizes.

If your project doesn’t handle theming or complex css, linaria can be a suitable option as it compiles js into css at build time.

Given that we know the how these libraries perform with build sizes, It will be interesting to see which one is faster when the styles mount (renders). Faster rendering on browsers will give us a lower “time to interactive“. This should be an interesting case study that demands an article of its own.