doeunn.log

[디프만x인프런 수강일기] CS완전정복 스터디 - 3주차 후기

doeunnkimm — Sat, 30 Dec 2023 23:50:30 +0900

기출로 대비하는 개발자 전공면접 [CS 완전정복] 강의 - 인프런

CS 전공면접 기출 분석 [운영체제/자료구조/알고리즘/데이터베이스/네트워크]!, 딱 필요한 핵심만 추렸다! CS 전공면접, 이제 자신있게 준비하세요. 수강생 합격수기 [사진] [사진] [사진

www.inflearn.com

이제는 공부하는 방식에 적응~.~

저번 주부터 적용한 스터디 방식이 저한테 잘 맞는 것 같았어요. 그래서 이번 주도 강의에서 중요한 내용만 받아 적고, 설명해주시는 내용 중에 궁금한 내용을 질문과 답변 형식으로 추가 정리했어요.

이번 주 정리한 내용 ~.~

이번 주 주제였던 `데이터베이스`는 그래도 좀 와닿는 부분이 많았어요. 예전에 공부한 적도 있고 직접 다뤄본 적도 있어서 그런지 지난 주 `운영체제` 때보다는 수월하게 강의를 들을 수도 정리할 수도 있었던 것 같아요.

월9게모거 (월요일 9시 게더 모닥불 거기라는 뜻..)

이번 주도 어김없이 체크인부터 해서 서로 일주일을 어떻게 보냈는지 가볍게 이야기했어요! 사실 저는 이 시간이 제일 재밌답니다. 별 TMI가 다 나와서 웃기기도 하고 재밌더라구요 ㅋㅋ..

저의 3주차 TMI

저에게 3주차에는 무슨 일이 있었나 기억이 안 나서 들어가서 보니까 이런 일이 있었나보군요..! ㅋㅋㅋ 기억 상 정말 굉장히 바빴었는데... 암튼 그렇습니다.

3주차 스터디는 저랑 비슷하게 다들 수월하게 진행되는 느낌이 있었는데, 그래도 그 와중에 직접 면접 때 받은 질문도 공유해주시고 몰랐던 내용들도 있었어서 역시나 스터디원분들 덕분에 이번 주도 의미있게 스터디를 진행할 수 있었습니다.

[디프만x인프런 수강일기] CS완전정복 스터디 - 2주차 후기

doeunnkimm — Sat, 30 Dec 2023 23:41:26 +0900

기출로 대비하는 개발자 전공면접 [CS 완전정복] 강의 - 인프런

www.inflearn.com

1주차가 너무 좋았어서, 기대되는 2주차

1주차에는 제가 강의의 모든 내용(강의자분이 하시는 모든 말)을 적었던 터라 제가 더 공부하고 싶은 내용까지 할 시간이 없었어요. 그래서 이번 주부터는 중요한 내용만을 정리하고 강의자분이 추가로 설명하시는 부분은 이해하고 거기서 궁금한 점들을 더 정리했어요.

더 궁금한 내용은 질문과 답변 형식으로 해서 정리했어요

그랬더니 좀 더 얻어가는 게 많게 공부하는 느낌이 들었습니다.

이번 주도 월요일 9시 게더 모닥불 거기

2주차도 어김없이 월요일 9시에 게더에서 만났어요. 2주차 내용이 `운영체제`였어서 그런지 질문의 내용이나 답변들이 확실히 어렵더라구요.

제가 답변한 부분입니다

처음 알게 된 내용들이 많아서 더 귀를 쫑긋하고 스터디에 참여했던 것 같습니다 ㅎㅎ..

매번 댓글로 호응까지 해주는 스터디원분들 덕분에 행복할지도

체크아웃 시간

이번 주도 어김없이 체크아웃 시간으로 이번 주 스터디 진행에 대해 한번씩 돌아봤어요. 다들 운영체제는 와닿지 않아서 더 내용이 어렵게 느껴졌다고 하시더라구요. 또, 다들 질문 통해서 많이 알아가서 좋은 시간이였다고들 하셨습니다. 한 주 한 주 점점 더 알아가는 느낌이라 뿌듯하게 2주차도 마무리했습니다 :)

[디프만x인프런 수강일기] CS완전정복 스터디 - 1주차 후기

doeunnkimm — Sat, 30 Dec 2023 23:30:18 +0900

기출로 대비하는 개발자 전공면접 [CS 완전정복] 강의 - 인프런

www.inflearn.com

본격적인 시작

드디어 1주차 스터디가 시작되었어요.

어떻게 공부를 하면 좋을지 고민이 많았는데, 저는 CS 지식에 대해 많이 부족해서 원래 제 공부 스타일인 "최대한 많이 받아적자"로 시작했습니다.

다 받아적어버린 나..

이렇게 하니까 꼼꼼하게 하나하나 알아갈 순 있지만 시간이 꽤 많이 소요되더라구요. 강의 내용 이외에도 더 많이 알아보고 싶었는데 사실 시간이 부족해서 그러진 못했습니다.

월요일 9시는 게더에서 스터디 정기 모임 !

약속한대로 시간에 맞춰 모닥불이 모락모락 피는 게더 그곳에서 만나 스터디를 시작했어요.

스터디 방식으로 정했던 체크인 체크아웃 방식으로 스터디 모임 시작에는 서로 일주일 동안 어떻게 지냈는지 이야기하고 조금 분위기(?)를 풀고 슬슬 스터디로 넘어갔어요.

저희 스터디는 일주일 안에 `강의 듣기 + 내용 정리하기 + 목요일 저녁까지 예상 질문 2개씩 남기기 + 답변 달아오기` 이렇게 수행을 하기로 했습니다.

1주차 예상질문 표의 일부입니다 :)

그래서 스터디 모임날에는 순서대로 답변자가 질문을 읽고 답변하고 필요하다면 질문자는 의도를 설명해주는 시간으로 스터디를 진행했습니다. 중간중간에 질문자 분이 직접 면접 때 받은 질문이라고 소개해주시면서 정보 공유도 하고 좋더라구요.

더 좋았던 건 질문에 대한 답변을 준비하면서 공부한 내용들을 모두가 약속한 것처럼 정리해오셨더라구요 ㅎㅎㅋㅋㅋㅋ 그래서 나중에 들어가서 한번더 찾아보기 좋았던 것 같습니다.

체크아웃 시간

모든 예상 질문에 대한 답변을 끝내고 1주차 스터디를 마무리하기 전에 이번 주 스터디 내용에 대하 점검하는 시간으로 체크아웃 타임을 가졌어요. 그냥 이번 주 스터디하는 동안 어땠는지 이야기하는 시간이에요!

다들 예상 질문을 만들고 답변하니까 더 깊게 공부를 할 수 있었고 다양한 관점에서의 질문에 답변해보니까 그것도 좋았다고 하시더라구요!

첫 스터디였는데 모두가 열심히 해오고 생각보다 얻어가는 게 많은 시간이였던 것 같아요. 앞으로도 기대가 되는 1주차 스터디였습니다

[디프만x인프런 수강일기] CS완전정복 스터디 OT 후기

doeunnkimm — Mon, 4 Dec 2023 23:39:25 +0900

좋은 기회로 CS 스터디를 시작하다

디프만 14기로 활동하게 되면서, 인프런에서 제공하는 강의에 대해 스터디 참여를 할 수 있는 기회가 있었어요!

당연히 좋은 기회라고 생각해 냉큼(?) 참여하겠다고 했습니다

9개의 후원 강의들

인프런 후원 강의는 아래와 같았어요.

저는 WEB파트였던 만큼 `함수형 프로그래밍과 JavaScript`도 수강하고 싶었지만 이번이 아니면 CS를 공부할 기회가 없을 것 같아 CS완전정복 스터디에 참여하게 되었답니다.

나 어쩌다 스터디장까지

같은 스터디 참여를 희망하는 분들끼리 슬랙에 초대되고 단지 얼른 시작하고 싶은 마음에 제가 커리큘럼을 대강 구성을 해서 스터디원분들께 보냈었어요.

아아...혜자 반응들 무한 감사

같이 게더 모닥불 아래서.. OT

총 7명의 일정을 조율해서 다같이 게더에서 만나서 첫 OT를 진행했습니다.

첫 OT인 만큼 정해야할 것들이 많았어요. CS 스터디를 진행하실 생각이 있으시다면 아래 리스트의 내용을 정해보시는 걸 추천드려요.

스터디장
스터디 운영 방식
스터디 규칙
스터디 장소 / 시간

결국 첫 슬랙을 보냈던 제가 스터디장이 되었답니다

우리 스터디는 말이죠

저희는 우선 게더에서 일주일에 1번 모여서 정기적으로 스터디를 진행하기로 했어요.

또, 스터디 운영 방식 및 규칙에 대해서는 다음과 같았어요.

일주일 동안 강의 수강하면서 개인 정리 (단, 공개된 곳에서 다같이 각자)
예상 질문을 2개 이상씩 만들고 랜덤으로 분배해서 만나는 날까지 답변 준비해오기
매 스터디날 마다 체크인 / 체크아웃 방식으로 짧게 나마 친해지는 시간 가지기
운영 방식에 따라 일주일에 성실히 수행하지 못했을 경우 1만원 씩 벌금
공지 올리면 리액션 많이많이

뭐 이런 것들을 정했습니다 저는 아무리 스터디를 위해 만났다 하더라도 서로 가까워져야 더 편한 분위기에서 더 좋은 내용들이 나오고 서로에게 도움이 되는 말들을 주고 받을 수 있을 거라고 생각하기 때문에 체크인 / 체크아웃 처럼 서로 이야기를 하는 시간도 넣었어요.

첫날에도 가볍게 체크아웃을 해보았어요

~~은근 나름 재밌는 거 같은데 저만 그런가요~~

OT를 마치고

다들 적극적으로 의견도 내주시고 말씀도 너무 다들 웃기셔서 OT 끝나고 스터디원분들이랑 한참을 떠들다가 나갔네요,,

역시나 반응은 혜자였다

사실 지금 스터디에 총 7명 중 1명 WEB, 6명 SERVER 이렇게 구성되어 있는데요! WEB 한명이 접니다만

저도 `어느정도의 기본기 + 분명 필요한 순간이 올 거 같음`의 마음으로 시작하게 되었답니다.

기출로 대비하는 개발자 전공면접 [CS 완전정복] - 인프런 | 강의

www.inflearn.com

앞으로 열심히

[Next.js] next.config.js 옵션 알아보기

doeunnkimm — Thu, 29 Jun 2023 22:31:25 +0900

Configuration

CRA로 프로젝트를 만들었을 때는 webpack config 등을 커스텀하려고 하면 React에 기본으로 셋업되어 있는 configuration을 해제해서 직접 커스터마이징할 수 있게 하거나(`npm run eject`), carco(Create React App Configuration Override)와 같은 도구 등을 사용하여야 했습니다.

next.config.js

Next.js에서는 기존에 있는 것을 eject 하거나 craco 같은 도구를 쓸 필요없이 root 디렉토리에 `next.config.js`을 저장해 두고 그곳에서 필요한 여러 configuration을 추가하면 됩니다. 그렇게 추가한 config는 서버를 띄우거나 build하는 타이밍에 사용됩니다.

1. 환경 변수

아래와 같이 작성해 주면 `process.env.{ 환경변수 이름 }`으로 환경 변수를 사용할 수 있습니다.

next.config.js

module.exports = {
  env: {
    customKey: 'TEST NEXT CONFIG',
  },
}

특정 페이지에서 `process.env.customKey`를 콘솔 명령어를 통해 확인해 보았더니 아래와 같이 잘 나오는 것을 확인할 수 있었습니다.

콘솔 명령

2. Base Path

Base Path는 프로젝트의 구조를 커스텀할 때 활용합니다. 이를 통해 모든 경로의 base path를 변경해줄 수 있습니다.

next.config.js

module.exports = {
  basePath: '/docs',
}

원래는 basePath는 `/`이기 때문에 <Link> 컴포넌트나 <Image> 컴포넌트에 경로를 입력해주려고 할 때 `/docs/hello` 이런 식으로 입력을 했었다면 basePath를 `/docs`로 입력하고서는 `/hello`만 입력해도 `/docs/hello`로 된다는 것입니다.

3. Rewrites

요청 경로를 다른 경로로 매핑할 수 있습니다. rewrite는 URL 프록시 역할을 하고, 요청 경로를 마스킹하여 사용자가 사이트에서 자신의 위치를 변경하지 않은 것처럼 보이게 합니다.

Rewrite vs Redirect

공통점
특정 path에 접근시 정해진 화면이 보이도록 한다.

차이점
rewrite는 유저가 입력한 url 그대로 유저에게 보여주어 유저는 화면이 변경된지 모른다.
redirect는 정해진 path로 url이 변경된다.

예를 들어, test.com/old로 접근했을 때 /new로 변경되도록 설정했다면
rewrite는 test.com/old 인채로 /new의 화면이 보여지고, redirect는 test.com/old에 진입하자마자 /new로 경로를 변경해 버린다.

rewrite는 `source`와 `destination`이 필요합니다.

source : 들어오는 요청 경로
destination : 라우팅하려는 경로

next.config.js

module.exports = {
  async rewrites() {
    return [
      {
        source: '/about',
        destination: '/',
      },
    ]
  },
}

추가로, rewrites도 slug처럼 작동하게 하고 싶다면 아래와 같이 작성해주면 됩니다.

module.exports = {
  async rewrites() {
    return [
      {
        source: '/about/:slug+',
        destination: '/',
      },
    ]
  },
}

그러면 `/about/aaa`와 같이 about과 관련된 모든 url에 대해 모두 `/`로 rewrite하겠다라고 작성해줄 수도 있습니다.

Header, Cookies, Query를 매칭해서 rewrites도 가능

헤더, 쿠키, 쿼리 값도 필드와 일치할 때 rewrites하도록도 가능합니다.

has
- type: 'header' | 'cookie' | 'query' | 'host'
- key: 일치시킬 유형의 키 이름
- value: 확인할 값

저는 간단하게 `query`로 테스트를 해보겠습니다.

next.config.js

async rewrites() {
    return [
      {
        source: '/about',
        has: [{ type: 'query', key: 'test', value: 'rewrite' }],
        destination: '/',
      },
    ]
  },

위와 같이 작성했습니다. `/about`이라는 url로 접근하면, `query`를 확인합니다. key는 `test`이고 value는 `rewrite`인지를 확인합니다. 만약 일치하다면 `/`로 rewrites하게 됩니다.

4. Redirect

rewrites를 살펴볼 때 잠깐 설명했는데, 요청 경로를 다른 대상 경로로 화면은 마찬가지로 url로 이동시킵니다.

source : 들어오는 요청 경로
destination : 라우팅하려는 경로
permanent : 유저나 검색 엔진에서 해당 리다이렉트 값을 영구적으로 저장할 것인지에 대한 여부. 만약 이벤트 페이지이거나 임시 페이지인 경우는 `false`로 지정해주면 된다.

next.config.js

module.exports = {
  async redirects() {
    return [
      {
        source: '/about',
        destination: '/',
        permanent: true,
      },
    ]
  },
}

Redirect에서도 Rewrite와 비슷하게 헤더, 쿠키, 쿼리로 매칭하여 redirect할 수 있습니다.

5. Runtime Configuration

Next.js가 실행하는 동안 동작 및 설정을 조정할 수 있습니다.

serverRuntimeConfig : server측에서 접근 가능한 런타임 설정
publicRuntimeConfig : client측과 server측 양쪽에서 접근 가능한 공개 설정

next.config.js

serverRuntimeConfig: {
    // Will only be available on the server side
    mySecret: 'secret',
  },
  publicRuntimeConfig: {
    // Will be available on both server and client
    staticFolder: '/static',
  },

위와 같이 작성하고 특정 파일에 아래 내용을 작성해봅시다.

import getConfig from 'next/config'

const { serverRuntimeConfig, publicRuntimeConfig } = getConfig()
console.log(serverRuntimeConfig.mySecret)
console.log(publicRuntimeConfig.staticFolder)

client

server

`serverRuntimeConfig`는 client 콘솔에는 `undefined`로 커버가 된 것을 확인할 수 있었고, server 콘솔에서는 모두 로그가 찍힌 것을 확인할 수 있었습니다.

6. distDir

빌드 시 생성되는 디렉토리 이름을 변경해줄 수 있습니다. 원래는 `.next`였죠?

next.config.js

module.exports = {
  distDir: 'build',
}

위와 같이 설정해주고 `yarn build`를 해보면 `build`라는 폴더가 생기면 빌드된 파일들이 포함되게 됩니다.

그런데 위와 같이 설정하고 `yarn build`를 해주면 마지막에 에러가 뜹니다.

export-marker.json은 지금 `build`파일에 존재하는데 못찾겠다면서요!

그래서 next-sitemap.config.js 파일로 가서 추가 설정이 필요합니다.

next-sitemap.config.js

/** @type {import('next-sitemap').IConfig} */
module.exports = {
  siteUrl: '배포주소',
  generateRobotsTxt: true, // (optional)
  // ...other options
  sourceDir: 'build'
}

위와 같이 `sourceDir`을 알려줘야 합니다.

이번 포스팅에서는 next.config.js에서 커스텀할 수 있는 내용들에 대해 알아보았습니다. 모든 내용을 다룬 것은 아니니 공식 문서를 참고하시면 더욱 좋을 것 같습니다!

1. 필요한 것만

다양한 설정이 가능, 찾아서 쓸 수 있으면 됨

2. 환경변수

process.env.*

3. rewrite / redirect

url 유지 / url 자체 redirect

4. 기타

webpack부터 기타 세밀한 설정까지

[Next.js] Next.js에서 Error Handling을 해서 원하는 에러 문구를 보여주자

doeunnkimm — Wed, 28 Jun 2023 22:16:12 +0900

Error Handling

공식 문서

공식문서에서 개발, 서버 측 및 클라이언트 측 오류를 처리하는 방법을 설명하고 있습니다 :) 해당 내용에 대해 살펴보도록 하겠습니다.

1. 개발 중 오류 처리

Next.js 개발 단계에서 런타임 오류가 발생하면 오버레이가 발생합니다 . 웹 페이지를 덮는 모달입니다. devlopment 모드로 실행될 때만 표시 되며 빌드 환경에서는 표시되지 않습니다. 오류를 수정하면 오버레이가 자동으로 해제됩니다.

이런 거 많이 볼 수 있죠?

2. 서버 오류 처리

서버 측 오류를 처리하기 위해 기본적으로 정적인 500 페이지를 제공합니다.

`500.js`라는 파일을 만들어 커스텀해서 에러 페이지를 보여줄 수도 있습니다. 마찬가지로 404, 401과 같이 에러 status code 이름으로 파일을 만들어 컴포넌트를 추가하면 해당 에러에 대해 만들어둔 Custom 에러 컴포넌트를 사용자에게 보여줄 수 있습니다.

pages/404.js

export default function Custom404() {
  return <h1>404 - Page Not Found</h1>
}

3. 오류 페이지 Customizing

다양한 status code에 대해 한번에 처리하고 싶다면 다음과 같이 사용할 수 있습니다.

pages/_error.js

import ErrorNext from 'next/error'

function Error({ statusCode }) {
  if (statusCode === 404) {
    return <p>404에러에요!</p>
  }
  return <ErrorNext statusCode={statusCode} />
}

Error.getInitialProps = ({ res, err }) => {
  const statusCode = res ? res.statusCode : err ? err.statusCode : 404
  return { statusCode }
}

export default Error

`next/error`의 컴포넌트는 위에서 기본적으로 보여주었던 next에서 제공하고 있는 에러 컴포넌트입니다. 저는 위와 같이 내가 따로 처리하고 싶은 statusCode에 대해서는 특별하게 return 하고 있고 나머지에 대해서는 기본 컴포넌트를 사용하여 처리되도록 했습니다.

주의할 점은 예를 들어 이미 `404.js`파일이 존재한다면 404.js 파일을 먼저 인식하여 _error.js 파일로 인식이 되지 않습니다.

위에서는 제가 간단하게 작성했지만, 특정 statusCode에 대해 분기처리 하고 싶다고 하면

const getErrorMessage = status => {
	switch (status) {
		case 403:
			return {
				title: '세션이 만료되었습니다.',
				content: '로그인을 해주세요',
			}
		// case 409:
		case 500:
			return {
				title: '서버에서 오류가 발생하였습니다.',
				content:
					'잠시 후 다시 시도해주세요. 문제가 지속될 경우 고객 센터에 문의해 주세요.',
			}
		case 502:
			return {
				title: '연결 과정에서 문제가 발생하였습니다.',
				content: '잠시 후 다시 시도해주세요.',
			}
		case 503:
			return {
				title: '서비스를 일시적으로 이용할 수 없습니다.',
				content: '나중에 다시 시도해주세요.',
			}
		default:
			return {
				title: '서비스에 접속할 수 없습니다.',
				content: '새로고침을 하거나 잠시 후 다시 접속해 주시기 바랍니다.',
			}
	}
}
export default getErrorMessage

위 처럼 따로 정의해두고 에러 컴포넌트에서 statusCode에 따라 처리하는 것도 좋은 방법일 것입니다.

4. 클라이언트 오류 처리

React의 ErrorBoundary에 대한 사용방법을 설명하고 있습니다.

Next.js에서 ErrorBoundary를 사용하려면 클래스 구성 요소를 생성하고 pages/_app.js를 래핑해야 합니다.

우선 ErrorBoundary 컴포넌트를 생성합니다.

components/ErrorBoundary.js

import React from 'react'

/**
 * Error 관련되어서는 hook에서 life cycle method가 존재하지 않아서
 * class형 컴포넌트 사용이 불가피
 */
class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props)

    // 초기 상태를 setup
    this.state = { hasError: false, error: null, errorInfo: null }
  }

  static getDerivedStateFromError(error) {
    console.log(`getDerivedStateFromError: ${error}`)

    return { hasError: true }
  }

  componentDidCatch(error, errorInfo) {
    this.setState({ error, errorInfo })
    console.log(`componentDidCatch: ${(error, errorInfo)}`)
  }

  render() {
    if (this.state.hasError) {
      if (this.props.fallbackComponent) {
        // props로 받은 fallbackComponent가 있다면
        return this.props.fallbackComponent
      }

      return (
        <div>
          <h2>Error occurred</h2>
          <details style={{ whiteSpace: 'pre-wrap' }}>
            {this.state.error && this.state.error.toString()}
          </details>
        </div>
      )
    }
    return this.props.children
  }
}

export default ErrorBoundary

위처럼 만들어준 ErrorBoundary 컴포넌트를 _app.js에서 래핑해줍니다.

_app.js

import Layout from '@/components/Layout'
import '@/styles/globals.css'
import ErrorBoundary from '@/components/ErrorBoundary'

export default function App({ Component, pageProps }) {

  return (
    <Layout>
      <ErrorBoundary>
        <Component {...pageProps} pathname={router.pathname} />
      </ErrorBoundary>
    </Layout>
  )
}

실행 화면

의도적으로 에러를 throw하여 테스트 해보았을 때 미리 Custom 해두었던 에러 메세지가 화면에 렌더링된 것을 확인할 수 있었습니다.

이번에는 fallbackComponent를 추가해봅시다.

<ErrorBoundary fallbackComponent={<div>에러 발생!  </div>}>
	<Component {...pageProps} pathname={router.pathname} />
</ErrorBoundary>

실행 화면

이번에는 fallbackComponent로 특별히 화면에 렌더하고 싶은 컴포넌트를 넘겨주었더니 해당 컴포넌트로 화면에 렌더링된 것을 확인할 수 있었습니다.

만약 에러가 런타임 에러 모달로 뜬다면 development 모드에서가 아닌 build 환경에서 확인해보시면 되겠습니다 :)

이번 포스팅에서는 Custom Error 컴포넌트를 통해 Error Handling에 대해 알아보았습니다.

1. Error

handled vs unhandled

2. Error Handling

Development / Server / Client

3. Error Page Custom

404.js / _error.js / next/error

4. Client

Error Boundary

[Next.js] Web vitals와 성능 측정 도구에 대해 알아보자

doeunnkimm — Wed, 28 Jun 2023 12:21:34 +0900

Web Vitals

구글은 어떻게 페이지의 품질을 평가할까요? SEO 전략을 세우는 데 중요한 구글의 품질 평가 요소 중 한 축을 담당하는 코어 웹 바이탈에 대해 알아보려고 합니다.

Core Web Vitals

코어 웹 바이탈(Core Web Vitals)은 웹 페이지 로딩 속도, 모바일 친화성, 세이프 브라우징, 암호화(HTTPS 적용 여부), 방해요소 여부 등과 같은 웹 콘텐츠 이용자의 사용 경험에 영향을 미치는 다양한 측정 가능한 값들 중에서 구글이 중요하다 강조하는 아래의 3가지 매트릭스는 다음과 같습니다.

웹 바이탈의 3가지 핵심 매트릭스

1. LCP(Largest Contentful Paint, 최대 콘텐츠풀 페인트)

사용자가 화면에 렌더링된 콘텐츠를 보는데 걸리는 시간
LCP는 웹 페이지의 로딩 속도에 대한 지표
웹사이트가 사용자에게 화면에서 완전하고 상호작용할 준비가 된 가장 큰 콘텐츠를 표시하는 데 걸리는 시간을 측정
다음과 같이 사용자 경험과 관련된 로드 시간만 계산
- 이미지
- 비디오 썸네일
- CSS를 사용한 배경 이미지
- 단락, 제목 및 목록과 같은 텍스트 요소

좋은 LCP 점수

우수한 사용자 경험을 제공하려면 2.5초 이하로 권장

LCP에 악영향을 미치는 원인

느린 서버 응답 시간
브라우저가 서버에서 콘텐츠를 받는 데 걸리는 시간이 올래 걸릴수록 화면에 렌더링하는 데 시간이 더 오래 걸린다. 서버가 콘텐츠를 처리하는 방법과 위치를 개선해야 한다. 자원을 캐시하거나, HTML 페이지를 우선 캐시되도록 하는 등을 방법으로 서버 응답 시간을 단축할 수 있다.
자바스크립트와 CSS의 렌더 블로킹
브라우저가 콘텐츠를 렌더링하려면, HTML 마크업을 파싱해서 DOM 트리로 만들어야 한다. HTML 파서는 외부 스타일시트(<link rel="stylesheet">)나 동기적인 자바스크립트(<script src="main.js">)를 만나면 중단될 것이다.
스크립트와 스타일시트는 모두 LCP를 지연시키는 렌더 블로킹 리소스이다. 웹 페이지의 주요 컨텐츠를 빠르게 로딩하기 위해서 중요하지 않는 자바스크립트와 CSS는 지연시켜야 한다.
느린 리소스 로딩 시간
LCP에 영향을 주는 엘리먼트의 타입들은 <img>, <svg> 엘리먼트 내부의 <image>, <video>, CSS 그라데이션과 다르게 url() 함수를 통해 로드된 배경 이미지들이다.
상단부가 렌더링된 경우 이런 엘리먼트를 로드하는 데 걸리는 시간은 LCP에 직접적인 영향을 미친다. 이런 파일이 가능한 빠르게 로드될 수 있도록 하는 방법에는 이미지 최적화 및 압축, 중요한 리소스를 미리 로드, 텍스트 파일 압축 등이 있다.
Client-side 렌더링
클라이언트에서 주로 렌더링되는 사이트를 만들고 있다면, 용량이 큰 자바스크립트 번들의 사용이 LCP에 미칠 수 있는 영향을 조심해야 한다.
클라이언트 측에서 렌더링되는 사이트를 만들 때 핵심 자바스크립트를 최소화, 서버 측 렌더링을 사용, 사전 렌더링한다 등과 같은 최적화 방법을 고려해야 한다.

2. FID(First Input Delay, 최소 입력 지연)

브라우저가 첫 번째 클라이언트 요청에 응답하는 데 걸리는 시간을 계산
콘텐츠가 그려진 시점과 사이트가 이벤트 핸들러를 실행하고 처리할 준비가 된 시점 사이의 시간
이 지연은 JS를 다운로드하고 실행해야 하는 양, 이미지 크기, 사용자 정의 글꼴 등에 따라 사이트마다 다를 수 있다.
FID가 높을수록 사용자에게 더 답답

좋은 FID 점수

우수한 사용자 경험을 제공하려면 100ms 이하

FID에 악영향을 미치는 원인

JavaScript 실행
브라우저가 다음 단계를 결정하기 위해 기다리는 동안 웹 사이트가 응답하지 않은 것처럼 느끼게 하여 입력 지연 시간이 길어질 수 있다. 비동기 작업을 작은 단위로 나누어 처리하거나 서버 측에서 콘텐츠를 생성하여 클라이언트 측에서 후처리해야 하는 양을 최소화하거나, 사용하지 않는 JS를 delay하거나 해서 최적화 방법을 고려할 수 있습니다.

3. CLS(Cumulative Layout Shife, 누적 레이아웃 시프트)

방문자에게 콘텐츠가 얼마나 불안정한 지 측정하는 사용자 경험 측정 항목
뉴스 기사를 보려고 들어간 웹 사이트에서 기사 링크를 클릭한 순간 레이아웃이 이동해서 광고가 나타나 기사가 아닌 광고를 클릭한 경험이 있을텐데...
이렇게 페이지에 들어갔을 때 갑작스럽게 발생하는 레이아웃 이동의 정도를 합산한 이동 거리 개념을 도입
안정적인 레이아웃이냐를 따진다.

좋은 CLS 점수

우수한 사용자 경험을 제공하려면 0.1 이하

CLS에 악영향을 미치는 원인

치수가 없는 이미지
이미지 및 비디오 요소에 `width`와 `height` 속성을 항상 포함하거나 또는 CSS를 사용하여 필요한 공간을 잡는다. 이 방법을 사용하면 이미지가 로드되는 동안 브라우저가 문서의 공간을 올바르게 할당할 수 있다. 영역을 미리 확보게 두는 것이 중요한데, 이럴 때 `aspect-ratio` 속성을 사용하거나 반응형 이미지를 처리하거나 하는 방법으로 최적화를 할 수 있다.
크기가 없는 광고, 삽입 및 iframe
광고는 웹에서 레이아웃 이동에 가장 큰 영향을 주는 요소 중 하나이다. 동적인 광고 크기는 형재 보고 있는 콘텐츠를 페이지 아래로 밀어버릴 수 있어 사용자 환경에 최적화되지 않을 수 있다. 광고 슬롯을 위한 정적 공간을 확보하거나, 뷰포트 상단 근처에 광고 배치하지 않는 방법 등으로 개선할 수 있겠다.
동적으로 삽입된 콘텐츠
사용자 상호 작용에 대한 응답이 없는 경우 기존 콘텐츠 위에 새 콘텐츠를 삽입하지 않도록 한다. 사이트를 로드하려고 할 때 뷰포트의 맨 위/아래에 나타나는 ,UI로 인해 레이아웃 이동을 경험했을텐데, 이는 광고와 마찬가지로 페이지의 나머지 콘텐츠를 이동시키는 배너 및 폼에서 종종 발생한다.
미리 뷰포트에 충분한 공간을 확보하여(placeholder 또는 Skeleton UI 사용) 로드할 때 페이지의 콘텐츠가 이동하지 않도록 해야 한다.
FOIT/FOUT을 유발하는 웹 글꼴
FOIT : 웹 폰트가 적용되지 않은 텍스트가 보이지 않는 상태. 폰트가 바뀌면서 텐스트 번쩍임이 일어난다.
FOUT: : 웹 폰트가 적용되지 않는 Fallback 폰트 상태(unstyled)에서 폰트가 바뀌면서 텍스트 번쩍임이 일어난다
이럴 때는 `font-display`를 사용하여 사용자 정의 폰트의 렌더링 동작을 수정할 수 있다.

Google을 활용한 성능 측정

위 링크를 통해 성능을 측정할 수도 있고, 상세하게 여러 요인들을 알려주기도 합니다. 해당 내용들을 참고해 웹 성능 최적화를 수행을 할 수 있습니다.

Chrome을 활용한 성능 측정

Performance
Lighthouse
React debug tool profiler

그래서 Next.js에서 Web vitals를 어떻게 추적?

위 방법으로 측정하는 것은 어떤 기능이 어떤 속도로 동작했는지는 볼 수 있지만, 사용자의 상황에서는 어떤 경험을 하고 있는지는 알 수 없었습니다. 그 부분들은 사용자에게 제공된 우리 웹에서 이 vital들을 tracking할 수 있는 로그들을 심어서 볼 수가 있습니다.

공식문서

`_app.js`파일에 아래 내용을 추가해주면 쉽게 report를 얻을 수 있다고 하고 있습니다.

export function reportWebVitals(metric) {
  console.log(metric)
}

보면 CLS, LCP, FCP 등이 남았습니다. 해당하는 값은 `value`를 보면 됩니다. 해당 내용을 fetch로 서버에 올린다면 그 값이 우리에게 축적이 되면서 우리의 서비스를 접근하는 사용자가 어떠한 환경에서 어느정도의 퍼포먼스를 경험하고 있는지를 분석할 수 있습니다.

이번 포스팅에서는 Web vitals와 성능 측정 방식에 대해서도 간단히 알아보았습니다.

1. web.dev

LCP(2.5s) / FID(100ms) / CLS(0.1)

2. Google

web url 입력시 점수 측정 가능

3. Chrome

Performance / Lighthouse

4. reportWebvitals

웹서비스에 접근한 사용자의 로그 수집

참고 문서

[Next.js] Custom App - 생산성을 높이는 _app.js에서 할 수 있는 일들

doeunnkimm — Tue, 27 Jun 2023 18:15:58 +0900

Custom App

Next.js에서 `_app.js` 파일은 모든 구성요소를 Wrap하고 있는 요소라고도 할 수 있습니다. 따라서 `_app.js`에서 모든 컴포넌트에게 필요한 것들을 정의하고 초기화하여 조금이라도 반복되는 코드들을 줄일 수 있습니다.

공식문서에서는 다음과 같은 내용들을 수행할 수 있다고 합니다.

페이지 변경 간에 레이아웃 유지
페이지 탐색 시 고정적인 state를 유지
페이지에 추가 데이터 주입
글로벌 CSS 추가

하나씩 예시 코드를 살펴보며 무엇을 이야기하는지를 알아봅시다 :)

1. 페이지 변경 간에 레이아웃 유지

모든 페이지에 걸쳐 동일한 레이아웃을 유지해야 한다면 매번 컴포넌트의 최상단에 Layout 컴포넌트를 Wrapper로 씌워줄 필요가 없습니다. 이럴 때 `_app.js` 파일에서 한번에 Wrap해주면 되는데요.

_app.js

export default function App({ Component }) {
  const router = useRouter()

  return (
    // 아래와 같이 _app.js에서 Layout을 감싸주면
    // _app.js는 전체 컴포넌트의 Wrapper이기 때문에 전부 적용된다.
    <Layout home={router.pathname === '/'}>
      <Component {...pageProps} />
    </Layout>
  )
}

위 코드에는 특정 페이지에서는 조금 다른 스타일이 필요한 경우를 위해 옵션도 prop으로 전달할 수 있도록 한 형태입니다. 위와 같이 작성해주면 다른 페이지 컴포넌트에서는 해당 컴포넌트의 View 로직만 집중해서 작성할 수 있겠습니다.

2. 페이지 탐색 시 고정적인 state를 유지

`_app.js`에서 어떤 state를 가지고 있고, 해당 state를 계속 유지하는 경우도 알아봅시다.

만약 모든 페이지에 걸쳐 언제 방문했는지 년-월-일-시간을 표시해야 하는 경우를 예시로 들어보겠습니다. 그런데 방문 시간은 해당 사이트에 처음 방문한 시간을 표시하죠? 즉, navigate를 넘나들더라도 방문시간이 그때그때마다 변경되지 않아야 한다는 말과 같습니다.

_app.js

export default function App({ Component, pageProps }) {
  const router = useRouter()
  const [visitedTime] = useState(new Date())

  return (
    <Layout home={router.pathname === '/'}>
      <div>visited: {format(visitedTime, "yyyy-MM-dd'T'HH:mm:ss.SSSxxx")}</div>
      <Component {...pageProps} pathname={router.pathname} />
    </Layout>
  )
}

실행 화면

실행 화면을 보게되면 `_app.js`에서 관리하는 state이므로 navigate를 하더라도 변하지 않고 유지되는 것을 확인할 수 있었습니다.

3. 페이지에 추가 데이터 주입

만약 모든 페이지에 지금 페이지 pathname을 주입한다고 해보겠습니다.

_app.js

export default function App({ Component, pageProps }) {
  const router = useRouter()

  return (
    <Layout home={router.pathname === '/'}>
      <Component {...pageProps} pathname={router.pathname} />
    </Layout>
  )
}

위와 같이 작성해주면 모든 페이지들은 prop으로 pathname을 받아 사용할 수 있게 됩니다.

pages/posts/[id].js

export default Post({ postData, pathname }) {
  // ...
  
  return (
    <h2>pathname: {pathname}</h2>
  )
}

실행 화면

4. 글로벌 CSS 추가

`_app.js`에서 css를 import해주면 전역에서 스타일이 적용되게 됩니다.

_app.js

import '@/styles/globals.css'

[Next.js] ../ 때문에 길어지는 import문은 별칭 절대경로 @ 사용하기

doeunnkimm — Tue, 27 Jun 2023 12:51:18 +0900

Absolute Imports and Module Path Aliases

프로젝트를 하면 어떤 라이브러리 혹은 컴포넌트를 import하는 일이 많습니다. 일반적으로 `import Somthing from '../../components/Something'` 과 같은 형식으로 상대경로를 이용해서 불러옵니다.

프로젝트 규모가 커질 수록, 생성되는 폴더 및 파일이 많아질수록 depth가 깊어져 아래와 같이 import문이 굉장히 길어질 수 있습니다.

import Something from '../../../../components/common/layout/Something/';
import SubThing from '../../../../components/common/base/SubThing/';

보기 불편할 뿐더러 지저분해 보이기까지도 한다. 따라서 이럴 때 경로를 `절대경로`와 `별칭`을 사용하여 간단하게 표현할 수 있다.

jsconfig.json / tsconfig.json 생성

프로젝트에 맞게 config 파일을 생성해주고, 다음 내용을 추가해줍니다.

jsconfig.json

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/components/*": ["components/*"]
    }
  }
}

`baseUrl`을 "."으로 해서 root 디렉토리를 baseUrl이 되도록 설정합니다. 그리고 @/components는 components 폴더를 의미하는 별칭으로 설정했습니다.

위와 같이 설정해주면 다음과 같이 수정해줄 수 있습니다.

> before
import Layout from '../../components/Layout'

> after
import Layout from '@components/Layout'

훨씬 간략하고 보기 편하다고 생각이 듭니다 :)

[Next.js] Dynamic Import(Lazy load) & Hydration & Static Export

doeunnkimm — Tue, 27 Jun 2023 12:29:19 +0900

Dynamic Import

Dynamic Import는 컴포넌트를 사용하는 시점에 로드하는 것인데요. Next.js에서는 이미지나 Link 컴포넌트 두 가지 모두 Viewport 안에 들어왔을 떄 로드하는 것들이 있었습니다. 그런 것들을 Lazy Load라고 합니다.

컴포넌트 마저도 상단에서 모두 한번에 import해서 사용하는 것이 아니라 필요한 타이밍에 로드해서 사용할 수 있는 방법을 제공합니다. Next.js에서는 그것을 Dynamic이라는 개념으로 사용됩니다.

Dynamic Import를 사용하면 모듈을 빌드 타임이 아닌 런타임에 불러오도록 합니다. 이를 통해 번들 파일을 분리하고 초기 렌더링 시간 단축이란느 퍼포먼스 향상을 기대할 수 있습니다.

애플리케이션에는 초기 로딩부터 사용하지 않는 부분이 존재할 수 있으며, 또 그 부분의 사이즈가 생각보다 클 수 있기 때문입니다.

next/dynamic을 이용해서

`next/dynamic`을 사용하면 페이지의 초기 번들에 포함되지 않습니다. 페이지는 Suspense를 통해 fallback을 먼저 렌더링한 다음 로드가 되면 그때 구성 요소를 렌더링합니다.

import dynamic from 'next/dynamic'

const Button = dynamic(() => import('../../components/Button'), {
  loading: () => <div>Loading...</div>,
})

Dynamic Import를 사용하면 따로 빌드가 되게 됩니다. 반면 Dynamic Import를 사용하지 않으면 따로 쪼개지 않고 chunk에 같이 묶이게 됩니다.

Automatic Static Optimization

Next.js가 정적 페이지는 .html으로 요청에 맞춰 동작하는 페이지는 .js로 빌드하는 것을 말합니다.

Next.js는 자동적으로 정적인 것은 최적화해서 정적인 파일로, 동적인 것은 동적인 파일로 만들어줍니다.

작동 원리

`getServerSideProps`또는 `getInitialProps`가 페이지에 있는 경우 Next.js는 요청에 따라 페이지를 렌더링하도록 전환합니다. 위 경우가 아니라면 페이지를 HTML로 미리 렌더링하여 자동으로 페이지를 정적으로 최적화합니다.

router의 query

dynamic하다 static하다라는 것을 보았을 때, router의 query의 경우 client-side의 경우 hydration 이후 query 값을 읽어올 수 있습니다.

Next.js의 hydrate

Server Side 단에서 렌더링된 정적인 페이지와 번들링된 JS 파일을 클라이언트에게 보낸 뒤, 클라이언트 단에서 HTML 코드와 JS코드를 서로 매칭시키는 과정이다. React는 JS만을 사용해 화면을 painting한다. Next.js는 Server Side에서 미리 웹페이지를 Pre-rendering하여 generate된 HTML document를 클라이언트에게 전송한다.

Next.js를 통해 클라이언트가 받은 정적 웹페이지는 JS가 없기 때문에 interactive하지 않다. 개발자 도구의 네트워크 탭을 보면, document Type의 파일을 다운로드 받은 뒤 JS파일들이 다운로드되는 것을 확인할 수 있다.

그리고 이 JS코드들이 이전에 보내진 HTML DOM 요소 위에서 한번 더 렌더링을 하면서 각자 자기 자리를 찾아가며 매칭이 된다.

간단하게 확인해봅시다. 정적인 파일에서 Client Side 부분에 다음과 같은 코드를 추가해봅시다.

const router = useRouter()

useEffect(() => {
	console.log(router.query)
}, [router.query])

`build`하고 실행해서 살펴보면 새로고침 했을 때, 분명 query가 있음에도 처음에 빈 객체가 먼저 뜹니다. 이는 dydration 즉, 사용자와 interaction할 준비가 될 때까지는 query가 없다고 판단하여 빈 객체가 콘솔에 찍힌 것이고, 그 이후에 query가 보여진 것입니다.

client side에서 코드를 작성하고 있다면 query의 존재가 이후에 주입될 수 있다는 점을 염두하고 있는 것이 좋습니다.

Next.js이 Hydration함으로써 얻게되는 이점

React와 다르게 Pre-rendering된 Document는 자바스크립트 요소가 빠진 가벼운 상태이기 때문에 클라이언트 측에서 빠르게 로딩이 가능한 장점이 있습니다. 또한, 이후에 Chunk 단위로 다운로드된 자바스크립트 요소들이 렌더링될 때는 먼저 받아진 document의 DOM 요소에 자바스크립트 속성이 매칭되는 것이기 때문에 웹 페이지를 다시 그리는 과정이 일어나지 않게 됩니다.

좀더 쉽게 이해해보자면, React는 CSR(Client-side Rendering)로, 처음에 브라우저에 빈 HTML을 파일을 받아 아무것도 보여주지 않다가, 사용자 기기에서 렌더링이 진행되어 한 번에 화면을 보여줍니다.

반면, Next.js는 모든 페이지를 미리 렌더링(pre-render)합니다. 이는 Next.js가 모든 일을 클라이언트 측에서 모든 작업을 수행하는 것이 아니라, 각 페이지의 HTML을 미리 생성하는 것입니다. 생성된 HTML은 해당 페이지에 필요한 최소한의 JS코드와 연결됩니다. 그 후 브라우저에 의해 페이지가 로드되면, JS코드가 실행되어 페이지와 유저가 상호작용(interaction)할 수 있게 됩니다.

→ 이러한 과정을 hydration이라 합니다.

Static Export

Next.js 프로젝트를 정적인 파일들만으로 build하는 것을 말합니다. CDN 등에 정적인 파일들만을 올려서 서비스를 제공하는 것도 가능합니다.

즉, Node.js 서버가 있어야만 동작하는 기능들을 포기해야 한다는 말과 같습니다. 공식 문서에서는 다음과 같이 Static Export를 사용했을 때 지원받지 못하는 것들을 나열하고 있습니다.

공식 문서에 사용하는 방법도 자세히 설명되어 있으니 같이 참고하면 좋을 것 같습니다 bb

실행해보면, 위에 지원하지 않는 기능이 포함된 경우 export할 떄 에러가 발생합니다. 그래서 적절히 변경해주고 다시 export를 해보면 .next에 `out`이라는 폴더가 생기는데, 그 안에는 모두 html로 이루어진 파일들이 존재하며, next의 기본 동작을 위한 파일들만 js로 구성되어 있는 것을 확인할 수 있습니다.

이번 글에서는 Dynamic Import와 Hydration 그리고 Static Export에 대해 알아보았습니다.

1. Dynamic Import

Lazy load로 초기 청크 사이즈 줄이기

2. Suspense

Promise resolved 되어야 렌더

3. Automatic Static Optimize

알아서 정적 파일과 동적 파일 구분

4. Static HTML Export

의도적으로 정적 파일로 export 가능