DEV Community: Armel

Quickly make a NextJS app installable with Chrome

Armel — Sat, 12 Aug 2023 19:07:02 +0000

In this article, I will show you how to quickly make your NextJS app installable with Chrome.

The goal is to provide the minimum code and assets necessary to activate this feature.

Let’s jump to the implementation and create our NextJS app:

npx create-next-app@latest

Select the options you want, I will answer "Yes" to everything except the last one:

✔ What is your project named? … nextjs-installable
✔ Would you like to use TypeScript? … No / Yes
✔ Would you like to use ESLint? … No / Yes
✔ Would you like to use Tailwind CSS? … No / Yes
✔ Would you like to use `src/` directory? … No / Yes
✔ Would you like to use App Router? (recommended) … No / Yes
✔ Would you like to customize the default import alias? … No / Yes

Let’s test our app with:

cd nextjs-installable
npm run dev

Let's check with Chrome what the Lighthouse PWA report is saying about our app:

First, I will remove the line 31 and 40 from the src/app/page.tsx file as they are triggering the Content does not size correctly to viewport in the Lighthouse report and we don't need it for the topic of this article.

Now let's add all the missing features our report is complaining about.

Download any 512x512 PNG image, for example:
https://www.pngmart.com/fr/image/39454

Rename it and put it the following folder:

public/images/icon-512x512.png

Now create a public/manifest.json file with the following content, feel free to adapt it to your needs:

{
 "name": "NextJS Installable",
 "short_name": "Installable",
 "theme_color": "#000000",
 "background_color": "#000000",
 "display": "standalone",
 "scope": "/",
 "start_url": "/",
 "description": "Minimal configuration for a NextJS installable app",
 "icons": [
   {
     "src": "/icon-512x512.png",
     "sizes": "512x512",
     "type": "image/png"
   }
 ]
}

Open the src/app/layout.tsx and add a link to the manifest.json file along with the theme color of our app:

export const metadata: Metadata = {
  title: 'Create Next App',
  description: 'Generated by create next app',
  manifest: '/manifest.json',
  themeColor: '#000000',
}

Now create the service worker file called public/sw.js with one single line:

self.addEventListener('fetch', () => {});

and create another file to register our service worker called public/register.sw with the following content:

if ("serviceWorker" in navigator) {
  // declaring scope manually
  navigator.serviceWorker.register("/sw.js", { scope: "./" }).then(
    (registration) => {
      console.log("Service worker registration succeeded:", registration);
    },
    (error) => {
      console.error(`Service worker registration failed: ${error}`);
    },
  );
} else {
  console.error("Service workers are not supported.");
}

Finally let's link our register-sw.js file in our src/app/layout.tsx:

<html lang="en">
  <Script src='/register-sw.js' />
  <body className={inter.className}>{children}</body>
</html>

Let's re-run a Lighthouse report:

And finally, let's open our app with Chrome on our phone. Before that we will deploy it with https://vercel.com:

https://vercel.com/armelpingault/nextjs-installable

Source: https://github.com/armelpingault/nextjs-installable

A little investigation on the Largest Contentful Paint metric

Armel — Tue, 12 May 2020 07:37:22 +0000

As a Front-end web developer, web performance is one of my major responsibilities in our team. I use different tools and methodologies to monitor on a daily basis the performance metrics for our clients.

I have been following closely the SpeedIndex, the First Meaningful Paint, and the Page Load metrics for one of our clients, so when Google released its Web Vitals, I decided to give a better focus to the Largest Contentful Paint (LCP) metric.

One question I was wondering before even starting to measure the LCP was:

What are the consequences on the LCP when the largest element in the viewport is an image that appears with a fade-in animation?

So I measured the LCP of the website I was working on with and without the fade-in animation and I was a little bit surprised by the result: the LCP was exactly the same!

Since I did not understand how that was possible, I decided to investigate a little bit further.

First, I decided to create a simple page with a <h1> title, 2 short paragraphs <p>, and 1 image <img> and made sure the image was the largest element on the page:

https://lcp.glitch.me

I needed to update my lighthouse to version 6 in order to get the Web Vitals metrics:

npm install -g lighthouse@next

Then I ran the performance report on my page:

lighthouse --view https://lcp.glitch.me/

And I got the following results:

Lighthouse Performance report without fade-in animation

I also did a performance audit from the Chrome DevTools tab, and I could see the LCP was triggered when the image was displayed, which was totally fine:

Chrome DevTools Performance audit without fade-in animation

Now I wanted to compare the result with another version of my page including a fade-in animation of 5 seconds and see why I was getting the same result. I added a couple of lines of CSS to implement the animation:

img {
  max-width: 800px; 
  width: 100%;
  opacity: 1;
  animation: fadeIn 5s;
}

@keyframes fadeIn {
  from { 
    opacity: 0;
  }
  to {
    opacity: 1;
  }
}

And ran another Lighthouse performance report:

Lighthouse Performance report with a fade-in animation

All metrics were the same except the Speed Index, which made sense since this metric “measures how quickly content is visually displayed during page load”. The longer the fade-in animation is, the higher the value will be.

However, how come the LCP is exactly the same?

I did another performance audit with Chrome DevTools and I got the answer to my question:

Chrome DevTools Performance audit with a fade-in animation

The LCP was not based on the image anymore but on the h1 title!

So you have to be really careful when using this metric, the LCP is not always tracking the element you think, it’s not always as obvious as it seems to be in the first place :)

How to create a simple and beautiful chat with MongoDB, Express, React and Node.js (MERN stack)

Armel — Mon, 30 Dec 2019 13:48:35 +0000

Recently, I worked on an interesting project called SpeedBoard which is a real-time board for Agile and Scrum retrospectives. It's the kind of tool we use at work after our Scrum Sprint review to easily share our feedback about the last Sprint.

Since it was a very enriching experience, I thought that I would do a quick tutorial on how to set up a simple chat with the same technology stack which includes: MongoDB, Express, React, Node.js and is also called the MERN stack. I am also using Socket.IO for the real-time engine and Material-UI which is a UI framework for React based on Material Design.

If you don't want to wait until the end of this tutorial, you can already check a preview of the final result, and also check the Github repository if you want to fork it and start to improve it ;)

Prerequisites

In this tutorial, we will use Heroku for hosting our live project and Github for hosting our code and deploying it to Heroku, so make sure you already have an account with them, they both provide a free sign up.

Structure

Before we start, let's have a quick look at the structure of our project. Inside our root folder, we will have 2 subfolders: one called client which contains the React app and one called server with our Node.js server:

speedchatapp/
├── client/
├── server/

Let's open our Terminal and create our project folder:

mkdir speedchatapp
cd speedchatapp/

Set up the client

On the client-side, we will use the Create React App (CRA) which provides a very easy way to start building any React SPA.

CRA provides a very simple command to install the app, but first, let's ensure that npx is using the latest version if you used create-react-app in the past:

npm uninstall -g create-react-app

Now, let's create our app in our client folder with this simple command:

npx create-react-app client

This might take a couple of minutes to install all the dependencies, and once you are done, try:

cd client/
npm start

You should now be able to access your app at http://localhost:3000/

That was quick and simple : ) But still pretty far from our final result! We'll come back a little bit later to our React app once the server-side of our project is ready.

Set up the server

Now that we have the skeleton of our client ready, let's have a look at the backend side.

First, let's create our server folder at the root of our project and initialize our package.json file:

mkdir server
cd server/
npm init

A utility will take you through the configuration of the file but you can type Enter for all options for this tutorial.

Now, we will install all the dependencies required for our server (Express, Mongoose and Socket.IO) with the following command:

npm install express mongoose socket.io --save

Then, copy the .gitignore file from the client folder to the server folder to prevent some files and folders to be pushed to our GitHub repository (e.g. /node_modules folder):

cp ../client/.gitignore ./

We will create the 2 files necessary for our server to work. The first one (Message.js) is the schema of the documents we will keep in our database. We will need 3 information: the name of the user who is posting a message in the chat, the content of its message and a timestamp to know when he posted his message.

server/Message.js

const mongoose = require('mongoose');

const messageSchema = new mongoose.Schema({
  content: String,
  name: String,
}, {
  timestamps: true,
});

module.exports = mongoose.model('Message', messageSchema);

The second one (index.js) is our main file, I won't go too much into details because that would make this tutorial a bit too long, but feel free to ask any question in the comments, I'll be glad to answer them or improve the comments directly in the code if necessary.

server/index.js

const express = require('express');
const app = express();
const http = require('http').Server(app);
const path = require('path');
const io = require('socket.io')(http);

const uri = process.env.MONGODB_URI;
const port = process.env.PORT || 5000;

const Message = require('./Message');
const mongoose = require('mongoose');

mongoose.connect(uri, {
  useUnifiedTopology: true,
  useNewUrlParser: true,
});

app.use(express.static(path.join(__dirname, '..', 'client', 'build')));

io.on('connection', (socket) => {

  // Get the last 10 messages from the database.
  Message.find().sort({createdAt: -1}).limit(10).exec((err, messages) => {
    if (err) return console.error(err);

    // Send the last messages to the user.
    socket.emit('init', messages);
  });

  // Listen to connected users for a new message.
  socket.on('message', (msg) => {
    // Create a message with the content and the name of the user.
    const message = new Message({
      content: msg.content,
      name: msg.name,
    });

    // Save the message to the database.
    message.save((err) => {
      if (err) return console.error(err);
    });

    // Notify all other users about a new message.
    socket.broadcast.emit('push', msg);
  });
});

http.listen(port, () => {
  console.log('listening on *:' + port);
});

The structure of your project should now look like this:

speedchatapp/
├── client/
│   └── (Several files and folders)
└── server/
    ├── node_modules/
    ├── .gitignore
    ├── index.js
    ├── Message.js
    ├── package-lock.json (auto-generated)
    └── package.json

Before coming back to our React app to finish our project, let's set up our Heroku hosting and link it to our Github repository to make sure the deployment works fine.

Set up our Heroku hosting

Let's download and install the Heroku CLI to set up everything from our Terminal.

Once downloaded and installed, let's go back to our Terminal and login to our Heroku account:

heroku login

It will open a new tab in your browser and once you are logged in, you can close the browser tab and go back to your Terminal.

Now let's create our new app that will host our project:

heroku create

It will automatically generate an identifier with a URL where you can access your app, it should look like this:

https://sleepy-meadow-81798.herokuapp.com/

You can rename your app if you want something a little bit easier to remember, you can then use it for the rest of this tutorial:

Alright, now we need our MongoDB database to store the chat messages from the users. Let's add the mongolab addon to our app:

heroku addons:create mongolab --app speedchatapp

I used speedchatapp in the previous command because I renamed my application but you should use the one provided when you created it if you didn't rename it, for example, sleepy-meadow-81798.

Once created it will show you the name of a variable in green, i.e MONGODB_URI. Now let's get the configuration URI of our newly created database:

heroku config:get MONGODB_URI

You should see something like this:

mongodb://heroku_123abc:abc123@ds141188.mlab.com:41188/heroku_123abc

Copy this URI, and create a file at the root of your project called .env with the following content [VARIABLE_IN_GREEN]=[URI]. It should look like this:

MONGODB_URI=mongodb://heroku_123abc:abc123@ds141188.mlab.com:41188/heroku_123abc

Let's copy one more time the .gitignore and add the .env file at the end of it to avoid pushing the credentials of our database to GitHub:

cp server/.gitignore ./
echo '.env' >> .gitignore

During the deployment of our app, we need to tell Heroku how to start our server. It can be done by using a Procfile that we will put at the root of our project. So let's create it and add the command line that will start our server:

echo 'web: node server/index.js' > Procfile

Now let's initialize another package.json at the root of our project. Same as before, don't worry about all the options, for now, just type Enter at all prompts:

npm init

One last thing we want to do here is to install the npm package called Concurrently that will allow us to run both the server and the client in a single command line during our development mode:

npm install --save-dev concurrently

And finally, in our newly created package.json at the root of the project, we will add 2 lines in the scripts section:

"scripts": {
    "dev": "concurrently --kill-others \"heroku local\" \"npm run start --prefix ./client\"",
    "postinstall": "npm install --prefix ./server && npm install --prefix ./client && npm run build --prefix ./client",
}

The postinstall command, as you can guess, will be executed after Heroku has finished running the npm install command at the root of our folder. It's telling Heroku to also run the npm install command inside our client and server folder and will also build our React app for production.

Now, it's time to test it, go to the root of your project and type:

npm run dev

This will launch the server and our React app in development mode, and it should open a window in your browser with the previous landing page of our React app.

In your terminal, you should see something like this:

> concurrently --kill-others "heroku local" "npm run start --prefix ./client"

[1] 
[1] > react-scripts start
[1] 
[0] [OKAY] Loaded ENV .env File as KEY=VALUE Format
[0] 12:16:15 PM web.1 |  listening on *:5000
[1] Starting the development server...
[1] 
[1] Compiled successfully!
[1] 
[1] You can now view client in the browser.
[1] 
[1]   Local:            http://localhost:3000/
[1]   On Your Network:  http://192.168.0.10:3000/
[1] 
[1] Note that the development build is not optimized.
[1] To create a production build, use npm run build.

Note: we are using the same database for both Dev and Live mode, if you want to use a different database, you can always create another one in Heroku like we have seen before and update your .env file with the credentials of your new database to make sure it won't interfere with the one in production.

Set up GitHub and link to Heroku

Now, we are going create a new repository on GitHub, and we are going to connect it to Heroku so every time we will merge a Pull Request on the master branch, it will automatically deploy it on Heroku.

Let's create our repository on GitHub. Go to https://github.com/new:

Write down the repository URL that we will use in the next step. Back to our Terminal, in the root folder of our project:

// Initialize the root folder as a Git repository
git init 

// Add all the files for the initial commit
git add .

// Commit staged files
git commit -m "Initial commit"

// Set the GitHub remote repository
git remote add origin <repository url>

// Push the local changes to GitHub
git push origin master

Now our code is on GitHub, let's link this repository to our Heroku app.

From the Heroku UI, select your app and click on the Deploy tab. In the Deployment method, click on Github, type your repository name and click on Connect:

Also, make sure that the "Enable Automatic Deploys" on the master branch is activated:

It should now look like this:

Now let's trigger a first manual deployment to check that everything is fine. Click on the Deploy Branch and wait until you see you see Your app was successfully deployed.

Finally, after clicking on the Open App button at the top right of the page, you should see the React app on your Heroku hosting.

From now on, after pushing any update to your GitHub repository, you should see the deployment triggered automatically in your Heroku UI:

Finishing the client

Now that the architecture of our project is ready, let's finish our clientReact app.

The first thing we will need here is to install our frontend dependencies in the client folder: Socket.IO for client, Material-UI core and icons:

cd client/
npm install socket.io-client @material-ui/core @material-ui/icons --save

Now in the client/package.json, add the following proxy field at the end of the file:

"proxy": "http://localhost:5000"

It will tell the development server to proxy any unknown requests to your server in development. Check the official documentation for more information.

Next, we'll create a config.js file to tell our app to switch endpoints in case we are on our local machine or live hosting:

client/src/config.js

import pkg from '../package.json';

export default {
  development: {
    endpoint: pkg.proxy
  },
  production: {
    endpoint: window.location.hostname
  }
}

Okay now let's start our local development environment from our root folder:

npm run dev

Last steps

For the last step, either create or update each file below manually or go directly to the GitHub repository to check out the project.

Replace client/src/App.css:

body {
  background: #f5f5f5;
  padding: 16px;
}

#chat {
  max-height: calc(100vh - 128px);
  overflow: scroll;
  padding: 16px;
}

.name {
  color: rgba(0, 0, 0, 0.54);
}

.content {
  margin-bottom: 8px;
}

Replace client/src/App.js:

import React from 'react';
import config from './config';
import io from 'socket.io-client';

import Paper from '@material-ui/core/Paper';
import Typography from '@material-ui/core/Typography';

import BottomBar from './BottomBar';
import './App.css';

class App extends React.Component {
  constructor(props) {
    super(props);

    this.state = {
      chat: [],
      content: '',
      name: '',
    };
  }

  componentDidMount() {
    this.socket = io(config[process.env.NODE_ENV].endpoint);

    // Load the last 10 messages in the window.
    this.socket.on('init', (msg) => {
      let msgReversed = msg.reverse();
      this.setState((state) => ({
        chat: [...state.chat, ...msgReversed],
      }), this.scrollToBottom);
    });

    // Update the chat if a new message is broadcasted.
    this.socket.on('push', (msg) => {
      this.setState((state) => ({
        chat: [...state.chat, msg],
      }), this.scrollToBottom);
    });
  }

  // Save the message the user is typing in the input field.
  handleContent(event) {
    this.setState({
      content: event.target.value,
    });
  }

  //
  handleName(event) {
    this.setState({
      name: event.target.value,
    });
  }

  handleSubmit(event) {
    // Prevent the form to reload the current page.
    event.preventDefault();

    // Send the new message to the server.
    this.socket.emit('message', {
      name: this.state.name,
      content: this.state.content,
    });

    this.setState((state) => {
      // Update the chat with the user's message and remove the current message.
      return {
        chat: [...state.chat, {
          name: state.name,
          content: state.content,
        }],
        content: '',
      };
    }, this.scrollToBottom);
  }

  // Always make sure the window is scrolled down to the last message.
  scrollToBottom() {
    const chat = document.getElementById('chat');
    chat.scrollTop = chat.scrollHeight;
  }

  render() {
    return (
      <div className="App">
        <Paper id="chat" elevation={3}>
          {this.state.chat.map((el, index) => {
            return (
              <div key={index}>
                <Typography variant="caption" className="name">
                  {el.name}
                </Typography>
                <Typography variant="body1" className="content">
                  {el.content}
                </Typography>
              </div>
            );
          })}
        </Paper>
        <BottomBar
          content={this.state.content}
          handleContent={this.handleContent.bind(this)}
          handleName={this.handleName.bind(this)}
          handleSubmit={this.handleSubmit.bind(this)}
          name={this.state.name}
        />
      </div>
    );
  }
};

export default App;

Create client/src/BottomBar.js:

import React from 'react';

import { fade, makeStyles } from '@material-ui/core/styles';
import AppBar from '@material-ui/core/AppBar';
import InputBase from '@material-ui/core/InputBase';
import Toolbar from '@material-ui/core/Toolbar';

import ChatIcon from '@material-ui/icons/Chat';
import FaceIcon from '@material-ui/icons/Face';

const useStyles = makeStyles(theme => ({
  appBar: {
    bottom: 0,
    top: 'auto',
  },
  inputContainer: {
    backgroundColor: fade(theme.palette.common.white, 0.15),
    '&:hover': {
      backgroundColor: fade(theme.palette.common.white, 0.25),
    },
    borderRadius: theme.shape.borderRadius,
    marginLeft: theme.spacing(1),
    position: 'relative',
    width: '100%',
  },
  icon: {
    width: theme.spacing(7),
    height: '100%',
    position: 'absolute',
    pointerEvents: 'none',
    display: 'flex',
    alignItems: 'center',
    justifyContent: 'center',
  },
  inputRoot: {
    color: 'inherit',
  },
  inputInput: {
    padding: theme.spacing(1, 1, 1, 7),
    width: '100%',
  },
}));

export default function BottomBar(props) {
  const classes = useStyles();

  return (
    <AppBar position="fixed" className={classes.appBar}>
      <Toolbar>
        <div className={classes.inputContainer} style={{maxWidth: '200px'}}>
          <div className={classes.icon}>
            <FaceIcon />
          </div>
          <InputBase
            onChange={props.handleName}
            value={props.name}
            placeholder="Name"
            classes={{
              root: classes.inputRoot,
              input: classes.inputInput,
            }}
            inputProps={{ 'aria-label': 'name' }}
          />
        </div>
        <div className={classes.inputContainer}>
          <form onSubmit={props.handleSubmit}>
            <div className={classes.icon}>
              <ChatIcon />
            </div>
            <InputBase
              onChange={props.handleContent}
              value={props.content}
              placeholder="Type your message..."
              classes={{
                root: classes.inputRoot,
                input: classes.inputInput,
              }}
              inputProps={{ 'aria-label': 'content' }}
            />
          </form>
        </div>
      </Toolbar>
    </AppBar>
  );
}

Every time you update the code, you should see the project at http://localhost:3000 automatically reload with the last changes.

Finally, let's push our latest update to GitHub to trigger a new deployment on our live project:

git add .
git commit -m "Final update"
git push origin master

Et voilà, Bob's your uncle! Our chat is now finished and ready: https://speedchatapp.herokuapp.com/

If you have any question, feel free to ask in the comments, I'll be glad to answer it and improve this tutorial. And feel free to fork the project to improve it ;)

9 web development tips and tricks out of the blue

Armel — Mon, 16 Dec 2019 14:39:00 +0000

In this article, I gathered 9 tips and tricks for web developers that I used recently. Even though the content is more oriented toward beginners, I hope it can still be a good reminder for more advanced developers.

1. Get the current timestamp

This is a little shorthand I found interesting, especially to understand what's going on behind the scene:

const ts = + new Date(); // Same as (new Date()).getTime()

console.log(ts);
// 1576178666126

Demo: https://codepen.io/armelpingault/pen/eYmBzEG

According to the documentation:

The valueOf() method returns the primitive value of the specified object. The shorthand notation is prefixing the variable with a plus sign.

and in case you need a reminder about what exactly is a primitive value:

In JavaScript, a primitive (primitive value, primitive data type) is data that is not an object and has no methods. There are 7 primitive data types: string, number, bigint, boolean, null, undefined, and symbol.

2. Detect a long press

I have a button that should trigger 2 different actions depending on the user interaction: one action on a normal click and another action on a long press on the button:

const btn = document.querySelector('button');
let timer;

btn.addEventListener('mousedown', (e) => {
  timer = + new Date();
});

btn.addEventListener('mouseup', (e) => {
  if (+ new Date() - timer < 500) {
    console.log('click');
  } else {
    console.log('long press');
  };
});

Demo: https://codepen.io/armelpingault/pen/rNaLpLE

3. Sort an array of objects

This one is a classic, we often need to sort an array of objects according to the value of one property of the objects.

const arr = [
  {name: 'Jacques', age: 32},
  {name: 'Paul', age: 45},
  {name: 'Pierre', age: 20}
];

arr.sort((firstEl, secondEl) => firstEl.age - secondEl.age);
// [{name: 'Pierre', age: 20}, {name: 'Jacques', age: 32}, {name: 'Paul', age: 45}]

// And if you want to sort in descending order:

arr.sort((firstEl, secondEl) => secondEl.age - firstEl.age);
// [{name: 'Paul', age: 45}, {name: 'Jacques', age: 32}, {name: 'Paul', age: 20}]

Demo: https://codepen.io/armelpingault/pen/zYxoBPW

Also note that using the sort() function, the array is sorted in place, and no copy is made.

4. Communicate between components

When I need 2 of my Javascript components to communicate with each other, I sometimes end up implementing a Custom Event:

const el = document.createElement('div');
const btn = document.querySelector('button');

const event = new CustomEvent('sort', {
  detail: {
    by: 'name'
  }
});

btn.addEventListener('click', () => {
  el.dispatchEvent(event);
});

el.addEventListener('sort', (e) => {
  console.log('Sort by', e.detail.by);
});

Demo: https://codepen.io/armelpingault/pen/gObLazb

5. Deep and shallow copy of an array of objects

This topic deserves a whole article by itself, you will find thousands of articles covering it, but I thought I put another reminder here after a discussion I had a couple of days ago with one of my colleagues.

When you need to create a copy of an array of object, it's tempting to
do:

const arr1 = [{a: 1, b: 2}, {c: 3, d: 4}];
const arr2 = arr1;

However, this is just going copy the reference to the original object and if you modify arr1, then arr2 will be modified too.

const arr1 = [{a: 1, b: 2}, {c: 3, d: 4}];
const arr2 = arr1;
arr1[1].c = 9;

console.log(arr2);
// [{a: 1, b: 2}, {c: 9, d: 4}];

Demo: https://codepen.io/armelpingault/pen/OJPbXEy

Using the spread operator can help you create a shallow copy of your array. This will create a new array, but it will keep a reference to the objects inside the array.

const arr1 = [{a: 1, b: 2}, {c: 3, d: 4}];
const arr2 = [...arr1];

arr1.push({e: 5, f: 6});
arr1[0].a = 8;

console.log(arr2);
// [{a: 8, b: 2}, {c: 3, d: 4}];

Demo: https://codepen.io/armelpingault/pen/GRgNqBg

As you can see, adding a new element to arr1 is not changing arr2. However, if I modify an object inside arr1, then we will also see the changes inside arr2.

Now if I want to make a deep copy of the array, I can do like this:

const arr1 = [{a: 1, b: 2}, {c: 3, d: 4}];
const arr2 = JSON.parse(JSON.stringify(arr1));
arr[1].d = 6;

console.log(arr1);
// [{a: 1, b: 2}, {c: 3, d: 6}];

console.log(arr2);
// [{a: 1, b: 2}, {c: 3, d: 4}];

Demo: https://codepen.io/armelpingault/pen/BayQzOK

In this case, I can see that whatever I change in arr1, it won't have any impact on arr2.

Note that with JSON.stringify, object instances (including Map, Set, WeakMap, and WeakSet) will have only their enumerable properties serialized.

6. Copy to clipboard

This is a little snippet I use to copy the content of a <textarea> into the clipboard:

const textarea = document.querySelector('textarea');

const copy = () => {
  textarea.select();
  document.execCommand('copy');
  alert('Content popied to clipboard!');
};

textarea.addEventListener('click', copy);

Demo: https://codepen.io/armelpingault/pen/jOEVrQw

There is also the Clipboard API that is offering more options to manipulate the clipboard. However, it's still an experimental feature and the browser support is still pretty low.

7. One npm command to rule them all

I am a very big fan of projects where the deployment command is just one simple line, whether it's for development or production.

While working on a project recently, I realized that we needed two commands to start our development environment, one from our server folder and one from our client folder. Well, we definitely needed to merge those two commands into one command we could run from the root folder.

Projects
|
|-- client
|      package.json
|
|-- server
|      package.json
|
package.json

Thanks to the npm package concurrently which is allowing us to run several npm commands at the same time.

// After installing the npm package
npm install --save-dev concurrently

// You should now see it in your package.json
"devDependencies": {
  "concurrently": "^5.0.0"
}

// Then add the "master" command to the root package.json
"scripts": {
    "start": "concurrently \"npm start --prefix ./client\" \"npm start --prefix ./server\"",
}

The --prefix option will run any npm command inside the sub-folder of your choice:

npm run build --prefix ./client

8. Optimize SVG file

We work a lot with SVG icons on a daily basis, and those icons are usually provided by web design agencies or by the clients' web design department.

A lot of them are actually created and generated with software like Adobe Illustrator. Even though they are great tools to create graphic designs, they unfortunately also create a lot of extra useless markup in your SVG files if you don't pay attention to your export settings.

In order to optimize my SVG files, I use SVG Optimizer, which is pretty simple to integrate in your project:

// Install SVGO globally
npm install -g svgo

// Optimize all SVG file from -f "folder" to -o "folder"
svgo -f assets/src/svg -o assets/dist/svg

Last time I ran it, I was able to measure an average gain of around ~30% of the size of all the files... not bad!

9. Inspect WebSocket messages in Chrome

For the last tip of this article, I am re-posting an answer I wrote on StackOverflow that I needed while working on the development of a real-time web application.

Open Chrome Developer Tools.
Click on the Network tab.
Click on the filter WS (for WebSockets).
Reload the page to make sure you see your connection in the Name column.
Click on Messages.

Now you should see all your communications with your WebSockets, with 3 columns: Data, Length and Time.

Any other web development tips and tricks you would like to share with the community, feel free to add them in the comment section ;)

How to convince your client to focus on Web Performance: a case study

Armel — Tue, 10 Dec 2019 09:33:08 +0000

Web Performance is really one of my daily concerns for the clients I am working with at Netcentric.

Sometimes convincing them to focus on web performance is not an easy task: it’s never clear what will be the gain compared to the effort we are putting in it, and as you might already know, web performance is all about measurements.

By the time we decide to implement a feature for our clients, it can take weeks before we can see it live and finally measure the improvements, and there is always the risk that the rewards are not what we were expecting.

I wanted to show one of our clients that we should focus on optimizing what’s happening in the <head> section of their page, and again I couldn’t go with my "feeling" that it could be good for their performance. I wanted to show them some real numbers that would help me convince them that it was an important topic.

Luckily today, I was able to find a set of tools that would help me achieve my goal.

Building a Proof of Concept (PoC)

The first thing to do when it comes to web performance is to get a picture of the current status, so we can easily see the comparison before and after our work.

The Chrome DevTools Performance tab offers a lot of very interesting information, but it can sometimes be really hard to understand, especially for not-too-technical people, with all the information it provides:

Performance reports are not always easy to understand for non-tech people

So, I decided to use some custom metrics using the Performance API to get a rough idea of what was time-consuming on the page I was auditing.

The first step was to go to the homepage of our client and use the Overrides feature of Chrome to be able to inject my own piece of Javascript.

First, I opened Chrome DevTools, went to the "Sources" tab, followed by the "Overrides" panel:

How to access the "Sources" → "Overrides" panel

From here, I clicked on "+ Select folder to overrides" and selected an empty folder I just created (You can also create a new one directly from the dialogue box).

Once selected, Chrome prompts you to allow access to this folder, so don’t forget to click on the "Allow" button:

Chrome prompting you to ask access to your overrides folder

Then, from the "Sources" tab, I went to the "Page" panel and opened my main HTML file (in my case, en.html):

The HTML source viewed from the "Sources" tab

On the right side, I was able to inject my Javascript for my custom metrics. I used two functions: performance.mark() and performance.measure().

The Performance API is very easy to use, for example:

// Start your measure
performance.mark('begin');
// Put everything you want to measure between the marks
// Stop your measure
performance.mark('end');
// Calculate the time difference between your 2 marks
performance.measure('diff', 'begin', 'end');
// View the results in the Performance tab
// or output the results in the console using:
console.log(performance.getEntriesByType("measure"));

You should see something similar to this in your console:

How the measure looks like in the Chrome console

Finally, the code had the following structure for my page:

Structure of my page after adding the performance marks

Once done with injecting my performance marks inside my HTML, I switched to the "Performance" tab, made sure I selected a "Fast 3G" network and "4x slowdown" for the CPU, and finally clicked on "Start profiling and reload the page":

Configuration before running the Performance report

After a couple of seconds, I was able to see my report with some interesting information. The section I wanted to check was the "Timings" panel where I could find my custom metrics along with some default user metrics provided by Chrome, e.g. First Contentful Paint (FCP), First Meaningful Paint (FMP), Largest Contentful Paint (LCP), ...

The "Timings" panel shows my custom metrics along with Chrome default ones

What I saw there was that parsing the <head> section was taking 4.40s (CSS 1.85s + JS 2.55s) for ~50 lines when parsing the <body> section was only taking 0.97s for ~1300 lines.

With that, I had a baseline for measuring my improvements. Time to optimise!

The first optimization I tested was adding a defer attribute to my Javascript files:

Adding a "defer" attribute to my scripts

So back to my "Sources" tab, I opened the HTML file and added the defer attribute, and ran a new "Performance" test:

"Timings" panel after adding the defer attribute

Checking the "Timings" panel again, I could now barely see the JS parsing time, which was down to 8.66ms. The total <head> section was also down to 1.65s, where most of the time was now only spent on the CSS.

I now wanted to see if I could also reduce the time spent on the CSS. So I went to check the "Coverage" tab (cmd+shift+p), opened it and clicked on "Start instrumenting coverage and reload the page":

The "Coverage" tab before starting profiling

Since I only wanted to see the CSS coverage, I used the filter .css and what I could see was that 92% of the CSS I was loading was not used. (Unused bytes will change in real-time when you start interacting with the page):

Unused bytes was over 92%

That was a lot of data loaded for nothing, and I wondered if I would have some gain removing unused CSS. To achieve this, I had a couple of solutions and tools like Purgecss, uncss or PurifyCSS for example, that could help me remove all the unused CSS on the homepage. I decided to use the last one as it was providing an easy user interface which was enough for my PoC.

For this tool, just put the URL of your website and click on "Clean up CSS". (I didn't check exactly how accurate this tool was as I just wanted to have a rough idea in my case).

Once it's done, I clicked on the "show clean css code" button and copied the new CSS.

Back to my DevTools and the "Sources" tab, "Page" panel, I selected my CSS file, pasted the cleaned CSS code I got in the previous step and saved my changes (ctrl+s).

And finally, I ran another "Performance" test:

"Performance" report after applying all my optimizations

In the end, after only those two optimizations, parsing the <head> section was only taking 0.63s, and most of this time was spent on the CSS (0.61ms). Knowing that our baseline metric was 4.40s, that was a total improvement of around ~85%!

Conclusion

The goal of this PoC was to convince our client to focus on Web Performance without going through the whole internal development process that would take weeks and without having any guarantee of the gains.

The PoC took me 2 hours to prepare, however, the real development will take a few weeks. Having all of our baseline measurements already done also lets us measure again once we are ready to go live and see the final real gain.

Improving web font performance: a case study

Armel — Tue, 02 Apr 2019 06:09:35 +0000

On the 8th and 9th of November 2018, I had the chance to join the first edition of the performance.now() conference, focusing on today's most important web performance insights. Among the sixteen great talks, I took a great deal away from Zach Leatherman's presentation on Web Font Performance and I would encourage you to watch the full talk.

At Netcentric, where I am a Front-end Software Engineer and web performance guardian, I could immediately see areas in which I could begin to try out some of the tips mentioned to improve web font implementation. I'll illustrate a few points of analysis that could be useful for optimizing web font performance.

Insights for optimizing web font performance

Setup

I mainly used macOS 10 with Chrome 70 for my analysis, and always throttling the network to Fast 3G and CPU 4x slowdown.

Similar fonts

Let's start by simply loading the homepage of the website to see which files are being loaded:

We are loading 5 font files, the .ttf and the CAC-Regular cannot be touched as they are very specific but I noticed that we have 3 fonts with quite a similar name:

CS-Light.woff2
CS-Regular.woff2
CS-Demi.woff2

I wondered how different they really are and if we really needed all of them, so I decided to compare them visually by placing one font on top of another. I chose to use the CS-Light font as a base font because it seemed easier to match with the other fonts. In our case, setting a lighter font-weight to the CS-Regular font didn't make any difference, so I could only apply a bolder font-weight.

So, I have the CS-Regular font in green, the one I want to replace, and the CS-Light in red and they don't really match.

We obviously have 2 different fonts

The first word here looked acceptable, but then it gets pretty wild. However, I could see some similarities so I tried to get a closer match by playing a little with some CSS:

Adding a letter-spacing and a line-height to .cs-light

By playing with two CSS properties, letter-spacing and line-height, which are both well supported, I could actually get a better match:

This isn't perfect, but I was surprised at how close I could get and how similar those two fonts are.

I also wanted to make sure they still match even if I change the font-size:

Font-size: 1em

Font-size: 3em

I really liked the result. You can feel a slight difference, especially when the text is made a bit larger, but overall it looks similar.

Then, I wanted to also check the other font we have, called CS-Demi, to see if I could get similar results:

CS-Light cs CS-Demi

Again, it didn't really match in the first place. So, I went through the same process and played again with some CSS properties, also adding a font-weight property since this font was much bolder than the other one:

Also adding a font-weight property

In the end, I got a pretty decent result. It's not as good as the previous results, but it's still hard to tell the difference between these two fonts if you don't know exactly which is which:

Font-size: 2em

So, now we can get a pretty similar result by loading only one file instead of three. Let's see what the gain could be:

344.7 KB of web fonts

We are loading 344.7 KB of web fonts separated in 5 file requests.

After getting rid of CS-Regular and CS-Demi, we now have only 197.7 KB of web fonts among 3 file requests, so that's a gain of 147.KB, which represents ~42.6% of the total weight of the fonts of the page. Not bad.

FOIT and FOUT

Another problem we've faced with websites is called Flash Of Invisible Text (FOIT) and also Flash Of Unstyled Text (FOUT). You can definitely see it visually when the network is a bit slower than usual. The Lighthouse audit has also been complaining about it:

The loading of web fonts are timing out (3,000ms)

Thanks to the font-display property, we can avoid a FOIT pretty easily, using the fallback value:

Font-display: fallback

As explained on the Google Developers' website:

fallback gives the font face an extremely small block period (100ms or less is recommended in most cases) and a short swap period (three seconds is recommended in most cases). In other words, the font face is rendered with a fallback at first if it's not loaded, but the font is swapped as soon as it loads. However, if too much time passes, the fallback will be used for the rest of the page's lifetime. fallback is a good candidate for things like body text where you'd like the user to start reading as soon as possible and don't want to disturb their experience by shifting text around as a new font loads in.

Be careful though: font-display is not fully supported yet!

Finally, after adding this property, we can fix our FOIT, at least on browsers supporting this feature:

FOIT is not a problem anymore

However, our FOUT problem remained, so to fix this issue I took a look at the preload hint.

Preload

We need to prioritize our CS-Light request

By examining the timing of the request of our CS-Light web font, I could see that it took almost 5 seconds to load, and it's also being loaded at the same time as the other fonts:

Before preload

So I decided to preload the critical web font by simply adding 1 line on the head section (see preload specifications):

Preload the main font file

I could then see straight away that Chrome was loading the main font file before the other ones, and faster too:

Our critical font file has now a high priority

Time to download the resource is divided by 2

Therefore, we started to download our critical web font resource after 1.45s instead of 5.33s, resulting in a gain of 72.8%. This meant it took 2.14s instead of 4.29s to download, meaning a gain of 50% regarding the length of time taken to download the content.

After all those optimizations, we could finally put everything together. We ended up with something that looked like this:

Next steps

There is still room for improvement regarding the optimization of the web fonts, and I'll continue to share the rest of the analysis. The next area to explore will be the possibility of subsetting fonts, since the website is being delivered in many languages.

Feel free to share your experience regarding web fonts optimization below or get in touch if you have any questions about these insights.