


Typography accounts for [95% of web design](https://ia.net/topics/the-web-is-all-about-typography-period/). Your font choice can be critical for branding, readability, and performance.

[Over time](https://thehistoryoftheweb.com/web-fonts/), recommendations for using web fonts have changed as browsers adopted new standards. Now in 2021, I wanted to learn the best practices for using web fonts on high-performance sites.

## System Fonts

The fastest way to use a web font is none. Browsers include a set of [web-safe fonts](https://developer.mozilla.org/en-US/docs/Learn/CSS/Styling_text/Fundamentals#Web_safe_fonts) (e.g. Arial, Georgia, Times New Roman) you can use by default.

Using web-safe fonts or the [system font stack](https://systemfontstack.com/) will be the fastest option.

```css
font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Helvetica, Arial,
  sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol';
```

## Why Use Web Fonts?

If system fonts are the fastest option, why do web fonts exist? Branding, improved design, and cross browser and device consistency. [82% of web pages for desktop](https://almanac.httparchive.org/en/2020/fonts) use web fonts.

Let's cover five different areas for high-performance web fonts and conclude with a 2021 recommendation.

- Self Hosting
- Preloading
- Font Display
- Variable Fonts
- Subsetting

## Self Hosting

[Google Fonts](https://fonts.google.com/) is responsible for [70% of all web font usage](https://almanac.httparchive.org/en/2020/fonts#serving-with-a-service). With over 1000 fonts, they provide easy access to quality fonts, multiple formats, and performant defaults (pre-connecting and swapping).

However, **Google Fonts is no longer necessary**. Since 2018, [Google has advised self-hosting](https://developers.google.com/web/updates/2018/08/web-performance-made-easy) for optimal performance through preloading.

There aren't any caching advantages anymore, either. Let's say you're using the font "Roboto", which is [a popular font](https://fonts.google.com/?sort=popularity) on Google Fonts. Chances are you've visited another site using "Roboto" and cached the font.

Since October 2020, Chrome [no longer allows](https://developers.google.com/web/updates/2020/10/http-cache-partitioning) a shared cache across sites. Safari has worked this way since 2013. "Roboto" will be re-downloaded for every site, regardless of it being cached.

When self-hosting, ensure you cache your font with the `Cache-Control` HTTP header. `immutable` tells the browser the file will never change. When a request is made within the `max-age` (1 year), it avoids the roundtrip to ensure it's the latest content.

```bash
Cache-Control: public, immutable, max-age=31536000
```

If you need Google Fonts, [use these optimizations](https://csswizardry.com/2020/05/the-fastest-google-fonts/). With the latest changes in the v2 API, you can tailor fonts to specific users and platforms (including variable fonts).

## Preloading

The browser assigns [loading priorities](https://web.dev/prioritize-resources/) to different types of resources. By default, CSS will be loaded before scripts and images. You can influence the importance of resources by [preloading critical assets](https://web.dev/preload-critical-assets/).

Fonts are discovered late by the browser by default. By preloading, we fetch the font file as soon as possible. Then, the browser caches the font making it available immediately.

Preloading can improve performance metrics like [Time to Interactive](https://web.dev/interactive) and [First Contentful Paint](https://web.dev/first-contentful-paint). For example, Shopify saw a [50% (1.2 second) improvement](https://twitter.com/ShopifyEng/status/844245243948163072) in First Contentful Paint, removing their Flash of Invisible Text (FOIT).

As of 2020, [75% of web fonts use WOFF2](https://almanac.httparchive.org/en/2019/fonts). You likely only need this. For example:

```css
<link
	rel="preload"
	href="/fonts/inter-var-latin.woff2"
	as="font"
	type="font/woff2"
	crossOrigin="anonymous"
/>
```

> Support: All modern browsers except Firefox.

## Font Display

`font-display` allows you to modify the rendering behavior of web fonts with values such as `auto`, `swap`, `block`, `fallback` and `optional`. When loading web fonts, we want to prevent [layout shift](https://web.dev/cls/). This occurs in two ways:

- Flash of Unstyled Text (FOUT) — The fallback font is swapped with a new font (e.g. `swap`).
- Flash of Invisible Text (FOIT) — Invisible text is shown on the page until a new font is rendered (e.g. `block`).

Browsers currently have a default strategy similar to `block`. The only option that eliminates layout shift is `optional`. Combined with the other performance optimizations in this article, `optional` is your best choice.

```css
@font-face {
  font-family: 'Inter';
  font-style: normal;
  font-display: optional;
  src: url(/fonts/inter-var-latin.woff2) format('woff2');
}
```

> Support: All modern browsers

## Variable Fonts

[Variable fonts](https://web.dev/variable-fonts/) allow us to combine multiple styles and weights (e.g. bold, italic) into a single font file.

```css
@font-face {
  font-family: 'Inter';
  font-style: normal;
  font-weight: 100 900; // Range of weights supported
  font-display: optional;
  src: url(/fonts/inter-var-latin.woff2) format('woff2');
}
```

You can try out different variable font options [here](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Fonts/Variable_Fonts_Guide).

> Support: All modern browsers. Even Google Fonts v2 API has support for variable fonts.

## Subsettings

Font files contain multiple languages and glyphs, which increase the file size. Subsetting is the removal of characters you don’t need.

For example, we might use the Inter variable font and subset to latin languages.

```css
@font-face {
  font-family: 'Inter';
  font-style: normal;
  font-weight: 100 900; // Range of weights supported
  font-display: optional;
  src: url(/fonts/inter-var-latin.woff2) format('woff2');
  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA,
    U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215,
    U+FEFF, U+FFFD;
}
```

## Conclusion

1. Use a variable font
2. Preload your font file
3. Self-host instead of Google Fonts
4. Use `font-display: optional` to prevent layout shift

[Here's an example](https://github.com/leerob/leerob.io) of a site implementing all these recommendations.

## Future

If you need to use `font-display: swap`, future support for [Font Metrics Override](https://www.youtube.com/watch?t=176&v=Z6wjUOSh9Tk&feature=youtu.be) will reduce layout shift when swapping.

```css
@font-face {
  font-family: ...;
  src: ...;
  ascent-override: 80%;
  descent-override: 20%;
  line-gap-override: 0%;
  ...;
}
```


Web Fonts in 2022


# Using the Spotify API with Next.js

I wanted to display what song I'm currently listening to, as well as my top tracks. To accomplish this, I'd need to integrate Spotify's API with Next.js API routes. This post will be a quick tutorial to get up and running with Spotify.

## Create an Application

First, we need to create a Spotify application to give us credentials to authenticate with the API.

Go to your [Spotify Developer Dashboard](https://developer.spotify.com/dashboard) and log in.
Click Create an App.
Fill out the name and description and click create.
Click Show Client Secret.
Save your Client ID and Secret. You'll need these soon.
Click Edit Settings.
Add `http://localhost:3000` as a redirect URI.
All done! You now have a properly configured Spotify application and the correct credentials to make requests.

## Authentication

There are a variety of ways to authenticate with the Spotify API, depending on your application. Since we only need permission granted once, we'll use the [Authorization Code Flow](https://developer.spotify.com/documentation/general/guides/authorization/).

First, we'll have our application request authorization by logging in with whatever [scopes](https://developer.spotify.com/documentation/general/guides/authorization/) we need. Here's an example of what the URL might look like. Swap out the `client_id` and scopes for your own.

```bash
https://accounts.spotify.com/authorize?client_id=8e94bde7dd
b84a1f7a0e51bf3bc95be8&response_type=code&redirect_uri=http
%3A%2F%2Flocalhost:3000&scope=user-read-currently-playing%20
user-top-read
```

After authorizing, you'll be redirected back to your `redirect_uri`. In the URL, there's a `code` query parameter. Save this value.

```
http://localhost:3000/callback?code=NApCCg..BkWtQ
```

Next, we'll need to retrieve the refresh token. You'll need to generate a Base 64 encoded string containing the client ID and secret from earlier. You can use [this tool](https://www.base64encode.org/) to encode it online. The format should be `client_id:client_secret`.

```bash
curl -H "Authorization: Basic <base64 encoded client_id:client_secret>"
-d grant_type=authorization_code -d code=<code> -d redirect_uri=http%3A
%2F%2Flocalhost:3000 https://accounts.spotify.com/api/token
```

This will return a JSON response containing a `refresh_token`. This token is [valid indefinitely](https://github.com/spotify/web-api/issues/374) unless you revoke access, so we'll want to save this in an environment variable.

## Using Spotify's API

Finally, we can get some real data! Inside Next.js, create three new values in your `.env.local` file.


```bash
SPOTIFY_CLIENT_ID=
SPOTIFY_CLIENT_SECRET=
SPOTIFY_REFRESH_TOKEN=
```

**Note:** If you haven't worked with environment variables in Next before, [give this a read first](https://nextjs.org/docs/basic-features/environment-variables).

We can now request an access token using our client ID, client secret, and `refresh_token`.


```js:lib/spotify.js
import querystring from 'querystring';

const client_id = process.env.SPOTIFY_CLIENT_ID;
const client_secret = process.env.SPOTIFY_CLIENT_SECRET;
const refresh_token = process.env.SPOTIFY_REFRESH_TOKEN;

const basic = Buffer.from(`${client_id}:${client_secret}`).toString('base64');
const TOKEN_ENDPOINT = `https://accounts.spotify.com/api/token`;

const getAccessToken = async () => {
  const response = await fetch(TOKEN_ENDPOINT, {
    method: 'POST',
    headers: {
      Authorization: `Basic ${basic}`,
      'Content-Type': 'application/x-www-form-urlencoded'
    },
    body: querystring.stringify({
      grant_type: 'refresh_token',
      refresh_token
    })
  });

  return response.json();
};
```

Use this `access_token` to securely request your top tracks.
This assumes you added the `user-top-read` scope at the beginning.

```js:lib/spotify.js
const TOP_TRACKS_ENDPOINT = `https://api.spotify.com/v1/me/top/tracks`;

export const getTopTracks = async () => {
  const { access_token } = await getAccessToken();

  return fetch(TOP_TRACKS_ENDPOINT, {
    headers: {
      Authorization: `Bearer ${access_token}`
    }
  });
};
```

### Creating an API Route

Let's test our communication with Spotify.
First, create a new file at `pages/api/top-tracks.js`.
Then, import the new function `getTopTracks`.

```js:pages/api/top-tracks.js
import { getTopTracks } from '../../lib/spotify';

export default async (_, res) => {
  const response = await getTopTracks();
  const { items } = await response.json();

  const tracks = items.slice(0, 10).map((track) => ({
    artist: track.artists.map((_artist) => _artist.name).join(', '),
    songUrl: track.external_urls.spotify,
    title: track.name
  }));

  return res.status(200).json({ tracks });
};
```

This will return the first ten top tracks, formatted to remove unnecessary information.
Feel free to modify this as you see fit.
If everything worked correctly, you should see some data like this after running `next dev`.

```json
// example web: https://leerob.io/api/top-tracks

{
  "tracks": [
    {
      "artist": "Jamie xx",
      "songUrl": "https://open.spotify.com/track/77Ezu3tBE7gmzQ4mRnZZUf",
      "title": "The Rest Is Noise"
    },
    {
      "artist": "Surfaces",
      "songUrl": "https://open.spotify.com/track/0NjSiGW8b5HYFfjdCbZzbg",
      "title": "Horizons"
    }
  ]
}
```

Using the Spotify API with Next.js


# Wisly Ong

## Programming Enthusiast

Im a 16 Years old, Coding Dreamer Currently Learning React, Postgres, Graphql, Prisma, And Typescript.

# My Gear

Here's what tech I'm currently using for coding, gaming, and music.

![my setup](/posts/desk.webp)

### Computer
- Samsung Monitor 
- Rexus Keyboard/Mouse

### Coding
-  Editor: VSCode
-  Theme: Github Dark Default
-  Terminal: Windows Powershell

###  Software
- Spotify
- Youtube Music
- Steam
- Ubisoft Connect

### Other Tech
- Oppo Smarthphone
- Ipad

About Me


This guide will show you how to use Firebase 9+ with Next.js and deploy it to Vercel.

### Connecting to Firebase

1. Create a project in [Firebase](https://firebase.google.com/docs/firestore/quickstart).
1. In the Firebase console, open Settings > Service Accounts.
1. Click Generate New Private Key, then confirm by clicking Generate Key.
1. Download and open the JSON file containing your service account.
1. Create a new file `.env.local` and add environment variables with those values.

```bash:.env.local
NEXT_PUBLIC_FIREBASE_PROJECT_ID=replace-me
FIREBASE_CLIENT_EMAIL=replace-me
FIREBASE_PRIVATE_KEY=replace-me
```

Create `lib/firebase.js` to connect to Firebase using your credentials:

```js:lib/firebase.js
import * as admin from 'firebase-admin';

if (!admin.apps.length) {
  admin.initializeApp({
    credential: admin.credential.cert({
      projectId: process.env.NEXT_PUBLIC_FIREBASE_PROJECT_ID,
      clientEmail: process.env.FIREBASE_CLIENT_EMAIL,
      privateKey: process.env.FIREBASE_PRIVATE_KEY.replace(/\\n/g, '\n')
    })
  });
}

const db = admin.firestore();

export { db };
```

### Fetching Data from Firebase

We can fetch data on the server from Firebase using an [API Route](https://nextjs.org/docs/api-routes/introduction) in Next.js. You'll need to create a new collection `users` and add a document `leerob` with a `name` string field if you're following this guide, but you can change that to whatever you want.

```js:pages/api/user.js
import { db } from '../../lib/firebase';

export default async function handler(req, res) {
  const user = await db.collection('users').doc('realpenguin').get();

  if (!user.exists) {
    return res.status(404).json({});
  }

  return res.status(404).json({ id: user.id, ...user.data() });
}
```

Let's break this down:

1. You'll make a request to `/api/users` from your frontend
1. A connection to Firestore is created using your service account
1. The API Route queries the `users` collection and returns the `leerob` document
1. We return the data for that document in the response

### Displaying Data on the Client

First, we need to install the correct dependencies:

```bash
$ npm i swr next@latest react@rc react-dom@rc
```

Finally, let's make a request to our API Route on the client-side using [SWR](https://swr.vercel.app) and Suspense:

```js:pages/index.js
import { Suspense } from 'react';
import useSWR from 'swr';

const fetcher = async (...args) => {
  const res = await fetch(...args);

  return res.json();
};

function Profile() {
  const { data } = useSWR('/api/user', fetcher, { suspense: true });
  return <div>Hello, {data.name}!</div>;
}

export default function App() {
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <Profile />
    </Suspense>
  );
}
```

Let's break this down:

1. When you request the root route (`/`) in your application, `pages/index.js` is rendered
1. React suspends the rendering of the page while fetching from `/api/user`
1. The fallback state (`<div>Loading...</div>`) is rendered while the data is being fetched
1. After the data is fetched, the fallback state is removed and the page is re-rendered
1. The `<Profile />` component shows `Hello, Lee Robinson!`


Using Firebase with Next.js


There's never been a [better time](/blog/learn-nextjs) to learn React.
If you're just getting started, you might have heard about these three options:

- [Next.js](https://nextjs.org)
- [Gatsby](https://www.gatsbyjs.org/)
- [Create React App (CRA)](https://create-react-app.dev/)

However, it's not exactly clear when or why you would choose one over the other.
This post will highlight the key similarities and differences between the three solutions.

## Next.js

Next.js is a hybrid React framework that evolves with your product.
With Next, you can have static pages, server-rendered pages, and more all within the same framework.

> **Update (2020):** I now work at Vercel, so I'm biased towards Next.js. The cons listed below are the
> most common pain points from the community.

**Pros**

- ✅ Supports static sites and server-side rendering
- ✅ Best DX out of the three (Webpack support, Fast Refresh, error handling)
- ✅ Create full-stack apps with [API Routes](https://nextjs.org/docs/api-routes/introduction)

**Cons**

- ⛔️ Lack of built-in support for layouts
- ⛔️ Limited plugin system ([RFC](https://github.com/vercel/next.js/issues/9133))
- ⛔️ Server-rendering adds complexity

## Gatsby

The key difference between Next.js and Gatsby is that Gatsby doesn't use a server.
While Gatsby's main use case is for static sites, it can also re-hydrate into a fully-functional React application.

Gatsby comes bundled with GraphQL for data fetching. Here's a short example.

```jsx
import React from 'react';
import { graphql } from 'gatsby';

const HomePage = ({ data }) => {
  return <div>{data.site.siteMetadata.description}</div>;
};

export const query = graphql`
  query HomePageQuery {
    site {
      siteMetadata {
        description
      }
    }
  }
`;

export default HomePage;
```

You can use [Gatsby without GraphQL](https://www.gatsbyjs.org/docs/using-gatsby-without-graphql/) if you absolutely must, but it's one of the key features it promotes.

**Pros**

- ✅ Robust [plugin library](https://www.gatsbyjs.org/plugins/)
- ✅ GraphQL integration

**Cons**

- ⛔️ GraphQL knowledge potentially needed
- ⛔️ Debugging plugin issues can be difficult
- ⛔️ Potentially large build times (e.g. lots of images/fetches)

## Create React App

CRA helps you get started building React apps immediately with client-side rendering (CSR). There's much less to digest and understand.
Unfortunately, that also means there's less you get for free as you scale your application. When building large-scale React applications,
especially those with marketing pages, having server-rendering in the framework is very helpful.

**Pros**

- ✅ Easiest to learn
- ✅ Best choice for guaranteed single-page applications
- ✅ More hosting options (since a server isn't required)

**Cons**

- ⛔️ No server-side rendering
- ⛔️ No code-splitting out of the box ([can be configured](https://create-react-app.dev/docs/code-splitting/))
- ⛔️ Requires client-side routing library (e.g. React Router)
- ⛔️ "Ejecting" for custom use cases can add complexity

## Conclusion

Still not sure which one to choose? I would highly recommend reading [Rendering on the Web](https://developers.google.com/web/updates/2019/02/rendering-on-the-web) for a deep-dive on where your rendering logic should live.

![rendering](/posts/rendering.jpg)

Web Fonts in 2022

Using the Spotify API with Next.js

About Me

Using Firebase with Next.js

Next.js vs. Gatsby vs. Create React App