FE/Next.js

[Next.js] 포트폴리오 성능 점수 100점 도전하기 (feat. 라이트하우스, 폰트 최적화)

unhandled 2025. 5. 1. 11:49

 

(F12 개발자도구 devtools) 라이트하우스

 

 

 

개발자 도구의 라이트하우스로 제가 지금까지 만든 포트폴리오 웹사이트(프로덕션 배포된)의 성능검사를 했을 때 결과입니다. (저는 이 점수만 보고.. 참 기분이 좋았는데..)

 

근데 알고보니 개발자 모드(크롬 devetools)의 라이트하우스와 구글 확장 프로그램인 라이트하우스와는 좀 다르다고 하더군요. 구글 확장 프로그램에서의 라이트하우스가 더 신뢰도가 높고 엄격하다고 합니다. 

 

 

(구글 확장 프로그램) 라이트하우스와 페이지스피드


(구글 확장 프로그램에서의 라이트하우스는 페이지스피드와 라이트하우스 두 가지로 나눠져 있는데, 성능 분석 후의 보고서 형식에서 약간의 차이점이 있지만 검사 자체에 있어서는 거의 유사한 것 같습니다. 테스트 결과는 거의 항상 동일했기 때문에 앞으로 캡처에서는 PageSpeed의 결과를 첨부하겠습니다.)  

 

역시 결과가 달랐습니다. 

 

 

 

성능이 66점인건.. 큰 영향을 끼치는 요인이 있다는 것입니다. 아마 폰트 때문일 것이라 예측하고 있습니다. next가 제공하는 폰트 최적화 기능인 next/font가 있는데 이전에 급하게 폰트를 적용부터 한답시고 jsdeliver로 임포트 하는 간단한 방법으로 폰트를 적용했거든요.

 

 

폰트 수정 (jsdeliver -> 프로젝트 내 woff파일에서 가져오기)

 

globals.css의 이 폰트 import하는 코드를 삭제하고

 

globals.css

@import url("https://cdn.jsdelivr.net/gh/orioncactus/pretendard@v1.3.9/dist/web/static/pretendard.min.css");

body {
  margin-top: 4rem;
  font-family: "pretendard", sans-serif;
  background-color: white;
  font-display: swap;
}

 

 

src 폴더 하위에 font 폴더를 만들어 다운로드 받은 PretendardVariable.woff2 파일을 추가했습니다.

 

 

 

그리고 다시 전역 CSS 파일로 돌아와서 @font-face를 정의해 줍니다. 

 

globals.css

@font-face {
  font-family: "pretendard";
  src: url("../font/PretendardVariable.woff2") format("woff-variations");
  font-style: normal;
  font-display: swap;
}

body {
  margin-top: 4rem;
  font-family: "pretendard", sans-serif;
  background-color: white;
  font-display: swap;
}

 

 

다시 페이지스피드를 돌려보겠습니다.

 

 

 

10점이 올랐군요! 

 

 

폰트 수정 (프로젝트 내 woff파일에서 가져오기 -> next/font/local)

 

 

위 과정은 거쳐가는 중간단계입니다. next의 localFont 기능을 활용하여 프로젝트 내 폰트 파일에서 폰트를 가져온 것과 그 기능을 활용하지 않고 가져온 것의 차이를 비교해보고 싶었기 때문입니다.

 

 

layout.tsx

import type { Metadata } from "next";

//이 부분과
import localFont from "next/font/local";

import { Geist, Geist_Mono } from "next/font/google";
import "./globals.css";
import Navbar from "../component/Navbar/Navbar";

//이 부분을 추가해주세요. 
const pretendard = localFont({
  src: ".././font/PretendardVariable.woff2",
  display: "swap",
  variable: "--font-pretendard",
});

// Geist와 Geist_Mono는 기본 폰트입니다. 
const geistSans = Geist({
  variable: "--font-geist-sans",
  subsets: ["latin"],
});

const geistMono = Geist_Mono({
  variable: "--font-geist-mono",
  subsets: ["latin"],
});

export default function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  return (
    <html lang="en">
      <body
      
      //그리고 아래처럼 이 부분에 ${pretendard.className}를 추가해주세요. (antialiased는 안 해도 됨) 
        className={`${geistSans.variable} ${geistMono.variable} antialiased ${pretendard.className}`}
      >
        <Navbar />
        <main>{children}</main>
      </body>
    </html>
  );
}

 

 

이제 또다시 페이지스피드를 돌려볼까요?

 

 

 

 

와우 89점이 됬습니다! 성능이 또 10점 상승했군요!

 

Next의 localFont는 자동 최적화가 설정되었기 때문입니다. 

 

역시 폰트가 성능을 떨어뜨리는 핵심 원인이었던 것 같습니다. 

 

 

사용하지 않는 폰트 제거

 

남은 성능은 어떻게 올려야할까요? 

프로젝트 생성 처음부터 있었던 next/font/google로 가져오고 있던 2개의 폰트(Geist와 Geist_Mono)를 삭제해 보았습니다.

 

루트 레이아웃 파일도 다음과 같이 수정하고

 

layout.tsx

import type { Metadata } from "next";
import localFont from "next/font/local";
import "./globals.css";
import Navbar from "../component/Navbar/Navbar";

const pretendard = localFont({
  src: ".././font/PretendardVariable.woff2",
  display: "swap",
  variable: "--font-pretendard",
});

export default function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  return (
    <html lang="en">
       <body className={`antialiased ${pretendard.className}`}>
        <Navbar />
        <main>{children}</main>
      </body>
    </html>
  );
}

 

 

아까 전역 CSS파일에 정의했던 @font-face 부분을 삭제해 줍니다. 

 

globals.css

/* @font-face {
  font-family: "pretendard";
  src: url("../font/PretendardVariable.woff2") format("woff-variations");
  font-style: normal;
  font-display: swap;
} */

body {
  margin-top: 4rem;
  font-family: "pretendard", sans-serif;
  background-color: white;
  font-display: swap;
}

 

 

이제 페이지 스피드를 돌려보겠습니다. 

 

 

 

사용하지 않는 기본 폰트까지 삭제하니까 성능이 1점 더 올랐습니다!

 

이제 나머지 10점이 어떤 것으로 인한 것인지 알아봐야겠죠. 

 

 

삽질의 여정 시작

 

 

"콘텐츠가 포함된 최대 페인트 요소" 이 부분이 문제인 것 같습니다. 

 

일단 처음으로 의심되는 건.. 당연하게도 프로필 이미지였습니다.

 

 

 

이 프로필 이미지는 제가 직접 피그마 캔버스에서 후다닥 만들어서 적용했었습니다.  지금 보니까 이미지 가로세로 길이가 6360x6360에 크기는 355KB나 됩니다. 

 

제 모니터 최대 화면에서도 가로세로 288px밖에 차지하지 않는데 저렇게 큰 이미지를 넣을 이유가 없습니다.

이 이미지를 줄이면(길이도 용량도) 성능 점수가 올라가지 않을까요?

 

 

576x576 크기로 줄여주었습니다.

 

 

 

 

우와! 역시 이미지 크기 때문이었던 것일까요? 

이제 96점인 접근성 부분만 해결하면 올백을 받을 수 있을 것 같습니다.

 

어... 그런데 몇 분 후 다시 돌려보니까 

 

 

 

 

페이지스피드 검사에서 성능 점수가 다시 90점으로 되돌아왔습니다.

 

어떻게 된 것일까요? (이 부분이 계속 절 좀 혼란스럽게 했는데 프로덕션 배포가 완료되자마자 곧바로 검사하면 성능 점수가 일시적으로 100점이 나오는 것 같습니다. 몇 분 지나고 해야 원래의 정상적인(?) 점수가 나오는 것 같더군요. )

 

 

 

여전히 이미지가 문제의 원인이라 지목하는 것처럼 보입니다. 이상하군요. 파일명도 resized로 끝나는 것을 보니까 분명 크기 조절 이후의 이미지가 적용된 것인데 말입니다.  

 

 

LCP라는 것은 최대 콘텐츠 렌더링 지표(?)이고, 이것이 도달하기 전까지 시간이 오래 걸린다.라는 의미 같습니다. 그러므로 이미지 파일이 커서 그것 때문에 시간이 오래 걸리는 게 아니라 이미지 파일이 도착하기 전까지의 어떠한 사전 작업? 어떠한 일련의 과정? 때문에 이미지 파일이 화면에 보이는 것도 지연되는 것일 가능성이 높은 것 같습니다.

 

개발자 도구의 퍼포먼스 탭을 살펴보겠습니다.

 

 

으음..(사실 잘 모름)

 

 

이 부분을 해석하거나 분석하는 부분에서는 잘 모르지만... 저 LCP 이전의 Compile script 과정에서 무언가 지연되는 것이 아닐까요? 그래서 저는 혹시 프로젝트 자체의 문제가 아니라 배포 플랫폼(Vercel)과 관련된 이유가 아닐까 하는 생각이 들었습니다. 

 

서버리스를 활용한 PaaS 방식의 콜드 스타트라는 특성 때문에 무언가 지연되는 게 아닐까?라는 생각이 들었습니다. 그런데도 이 가설은 이상합니다. Vercel은 Next.js 관련 최적화가 매우 잘 되어있기 때문에 Next.js 프로젝트를 배포하기 위한 최적의 플랫폼이라고 알고 있었기 때문입니다. 최적화가 잘 되어있다는 것은 성능 또한 다른 플랫폼 배포 대비 우수할 확률이 높다는 것이니까요.  

 

EC2 배포로 비교하기

 

지난번에 했던 EC2 배포를 이렇게 빨리 다시 해보게 될 줄은 몰랐습니다.

 

 

 

성능이 100이 되었습니다. (권장사항이 75인 것은 당연합니다. HTTPS 설정이 안 되어있는 상태니까요.)

이상합니다. 왜 아무런 최적화가 안 되어있는 EC2배포가 Vercel로 배포한 것보다 성능 점수가 잘 나오지?

 

그런데 또 시간이 지나니 금방 90점으로 떨어지더군요. 

 

제가 인프라 부분은 잘 모르는데.. nginx의 리버스 프록시와 관련이 있을까? 혹시 무언가.. 보완되는 그런 기능이 있는걸까? 라는 생각이 들었습니다. 

 

EC2 배포로 비교하기 2 (feat. 리버스 프록시 설정을 변경한) 

 

그래서 nginx의 리버스 프록시 설정의 일부분을 지워버리고 최소한의 설정만 넣어보았습니다. (어떠한 설정이 성능을 보완해준 것이 아닐까?라는 추측에서 시도해본 것인데, 사실 타당한 이유로 진행한 테스트는 아니었던것 같습니다. )

 

원래 리버스 프록시 설정은 이거였는데

server {
    listen 80;
    server_name _;

    location / {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }
}

 

이렇게 변경했습니다. 

server {
    listen 80;
    server_name _;

    location / {
        proxy_pass http://localhost:3000;
    }
}

 

그리고 nginx를 재시작하고 다시 배포된 사이트 화면을 보니..

 

 

 

하하 뭘까요? 갑자기 CSS가 싹 사라지고 이미지도 뜨지 않습니다. (색이 적용된 부분은 데이터에서 동적으로 색상 정보를 가져오게 했기 때문에 제가 인라인으로 스타일을 부여한 요소이기 때문입니다.)

 

제가 지워버린 리버스 프록시 설정 중에 누락되면 CSS 파일도 누락되거나 적용되지 않는 문제를 일으키는 설정이 있었나 봅니다.

 

 

(위 캡처 이미지는 구글 확장 프로그램 라이트하우스에서의 결과이지만 페이지 스피드에서의 결과도 동일했습니다. )

 

그런데.. 퍼포먼스가 100이 됐습니다.

 

(접근성은 89점으로 떨어졌네요. CSS 스타일링이 적용되지 않았으니 당연합니다. 아래 접은 글에서 어떠한 부분에서 접근성이 하락했는지 확인하실 수 있습니다.)

더보기

왜 CSS파일이 적용되지 않으면 웹 접근성 점수가 떨어지는가?

 

그 이유는 이제 색대비도 충족되지 않고 

 

UI요소들 간의 간격도 사라져 버렸기 때문입니다. 

 

이는 사용자 경험을 저해하기 때문에 웹 접근성 점수가 하락한 것입니다. 

 

이때 점수가 좀 유동적이었는데, 신기하게도 이 상태에서 퍼포먼스 점수는 100점을 계속 유지했습니다. CSS가 적용되지 않은 상태에서 성능 점수가 높아졌다? 이건 설마 CSS 관련 이슈인 것이 아닐까? 

 

 

Vercel 배포에서 Performance 탭 살펴보기

 

아래 이미지는 EC2가 아닌 Vercel로 배포한 경우였는데 제가 이 부분은 잘 모르기에 해석하기 어렵지만.. 아마 데이터가 서버에서 클라이언트에 도착하는 시간과 순서를 보여주는 표인 것 같습니다. 

 

 

 

FCP 이전의 Layout이라는 구간이 꽤 길지 않나요? 그리고 FCP(첫 번째로 도착하는 페인팅 요소)와 LCP(가장 큰 페인팅 요소) 간의 Layout 부분도 눈에 들어옵니다. 

 

그럼 레이아웃의 문제인가? 

 

위 EC2 배포에서 혹시 CSS의 문제인가?라는 생각이 떠올랐던 것과 더불어서 다음과 같은 추측을 했습니다. 

 

제가 그리드로 레이아웃을 잡으면서 반응형 웹을 구현하기 위해 그 그리드 내부에 또 그리드를 설정한 부분이 조금 있습니다. 혹시 이 중첩 그리드 구조가 성능저하를 유발하는 요인이 아닐까 라는 생각이 들었습니다. 

 

 

CSS 중첩 그리드 삭제해 보기

 

하지만 중첩 그리드 구조도 주석처리하고 새로 배포해도 성능 점수는 상승하지 않았습니다. 여전히 90점 그대로였죠. 

 

 

프로필 이미지 삭제해 보기

 

앞서서 이미지 때문은 아닌 것 같다고 했었지만.. 그래도 일단 프로필 이미지를 제거해 보았습니다. 

(중간에 웹 접근성을 개선했기에 웹 접근성은 이전 스샷보다 점수가 올랐습니다.)

 

 

 

여전히 성능은 90점이군요.

 

 

 

그리고 이 내용으로 더더욱 이미지 때문이 아니라는 것이 확실해졌습니다. 분명 저 첫 번째로 도착하는 가장 큰 요소(LCP)가 도달하기까지의 시간을 지연시키는 무언가가 있을 것 같습니다. 

 

 

next/dynamic 적용

 

혹시 첫 랜딩 페이지에서 뷰포트 밖의 컴포넌트들을 다이나믹 임포트로 가져오면 나아질까요?

 

하지만 쓰로틀링이 잔뜩 걸린 확장툴 라이트 하우스에서의 점수를 위해 실제 사용자 경험을 저해하는 게 아닌가?라는 생각도 들었습니다. 다이나믹 임포트로 가져온다는 것은 레이지 로딩을 한다는 거고, 사용자가 그 부분을 보기 전까지는 그 부분에 대한 내용을 가져오지 않는다는 것이니까요. 이는 사용자가 스크롤을 내리는 도중에 로딩 중인 화면을 보게 될 수도 있다는 것입니다. (실제로 해보니까 보이진 않았지만요.)

 

 

오 효과가 있나! 싶었다가

 

다시 90점으로 돌아왔습니다.. (이때 기뻐서 캡처 이미지 파일명도 "다이나믹_임포트의_효능.png"라고 해놨었습니다... 하하하 배포 후 일시적으로 100점에 가까운 점수가 뜨는 것 같다는 것이 바로 이러한 점들 때문입니다. 일시적으로 100점 내지는 100점에 가까운 점수가 나왔다가 다시 90점으로 돌아왔었으니까요.)

 

... 설마 폰트 문제가 아직 안 끝난 것일까요?

 

 

폰트 아예 삭제

 

아예 Pretendard 폰트 자체를 삭제해 보았습니다.

 

 

 

와. 100점입니다.

 

시간이 지나고 계속 100점. 결국 폰트 로딩의 문제였군요

하지만.. 폰트를 아예 적용하지 않을 수는 없습니다. 

 

 

 

왼쪽이 아무런 커스텀 폰트가 적용되지 않은 기본 상태이고 오른쪽은 프리텐다드 폰트 적용 후입니다. 시각적인 차이가 많이 납니다.

 

 

폰트 수정 (전체 woff 파일에서 프리셋 파일들만 가져오기)

 

보통 프리셋이라는 것을 많이 사용하더군요. 프리셋은 모든 글자에 대해 폰트를 적용하는 것이 아닌 사용자가 주로 사용하는 주요 글자에 대해서만 폰트를 적용합니다. 그러니까 크기가 더 작은 폰트파일입니다. 

 

font 폴더 하위에 Pretendard라는 폴더를 만들고 그 안에 폰트 서브셋 파일들을 넣어줍니다. 

 

 

 

그리고 루트 레이아웃 파일도 수정해 줍니다.

 

layout.tsx

import type { Metadata } from "next";
import localFont from "next/font/local";
import "./globals.css";
import Navbar from "../component/Navbar/Navbar";

// 이렇게 수정
const pretendard = localFont({
  src: [
    {
      path: ".././font/Pretendard/Pretendard-Thin.subset.woff2",
      weight: "100",
      style: "normal",
    },
    {
      path: ".././font/Pretendard/Pretendard-ExtraLight.subset.woff2",
      weight: "200",
      style: "normal",
    },
    {
      path: ".././font/Pretendard/Pretendard-Light.subset.woff2",
      weight: "300",
      style: "normal",
    },
    {
      path: ".././font/Pretendard/Pretendard-Regular.subset.woff2",
      weight: "400",
      style: "normal",
    },
    {
      path: ".././font/Pretendard/Pretendard-Medium.subset.woff2",
      weight: "500",
      style: "normal",
    },
    {
      path: ".././font/Pretendard/Pretendard-SemiBold.subset.woff2",
      weight: "600",
      style: "normal",
    },
    {
      path: ".././font/Pretendard/Pretendard-Bold.subset.woff2",
      weight: "700",
      style: "normal",
    },
    {
      path: ".././font/Pretendard/Pretendard-ExtraBold.subset.woff2",
      weight: "800",
      style: "normal",
    },
    {
      path: ".././font/Pretendard/Pretendard-Black.subset.woff2",
      weight: "900",
      style: "normal",
    },
  ],
  display: "swap",
  variable: "--font-pretendard",
});

export default function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  return (
    <html lang="en">
      <body className={`antialiased ${pretendard.className}`}>
        <Navbar />
        <main>{children}</main>
      </body>
    </html>
  );
}

 

 

페이지 스피드 결과를 볼까요?

 

 

....???? 이전에 프리셋 파일을 사용하기 전(90점)보다 성능 점수가 더 나빠졌습니다!

 

모든 프리셋 파일을 layout.tsx에 가져와서 그런 것 같습니다. (페이지 새로고침 시 네트워크 창에 모든 프리셋 파일 폰트가 도착합니다. 이것이 성능을 낮추는 원인이라는 것을 보여줍니다.)

 

필요한 파일만 가져오는 걸로 수정하겠습니다. 

 

 

폰트 수정 (사용하는 프리셋 파일 2개만 남기고 나머지 프리셋 삭제)

 

CSS 코드를 보니 제가 사용하는 font-weight 속성은 Medium(500-기본)과 Bold(700) 두 가지뿐이었습니다.

 

프리셋 파일 2개(Medium, Bold)만 남기고 나머지 프리셋 파일은 다 삭제했습니다. 

 

 

루트 레이아웃도 이에 따라 수정하겠습니다. 

 

layout.tsx

import type { Metadata } from "next";
import localFont from "next/font/local";
import "./globals.css";
import Navbar from "../component/Navbar/Navbar";

const pretendard = localFont({
  src: [
    {
      path: ".././font/Pretendard/Pretendard-Medium.subset.woff2",
      weight: "500",
      style: "normal",
    },
    {
      path: ".././font/Pretendard/Pretendard-Bold.subset.woff2",
      weight: "700",
      style: "normal",
    },
  ],
  display: "swap",
  variable: "--font-pretendard",
});

export default function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  return (
    <html lang="ko">
      <body className={`${pretendard.className}`}>
        <Navbar />
        <main>{children}</main>
        <Analytics />
      </body>
    </html>
  );
}

 

이제 페이지 스피드를 돌려보겠습니다. 

 

100점은 아니지만 99점이 됬군요.

시간이 지나도 99점인 안정적인 99점입니다.

 

 

마지막 1점을 올릴 수 있을까?

 

이 남은 1점도 폰트 문젠가 싶었습니다. 폰트를 아예 제거해 버렸을 때 성능 점수가 100점이 나왔으니까요. 그리고 더 이상 LCP 관련 경고가 보고서에 적혀있지 않았습니다. 그래서 혹시 이제는 정말 폰트가 아닌 다른 부분을 개선해서 점수를 올릴 수 있지 않을까?라는 생각이 들었습니다. 

 

 

저 Zustand 로고는 Zustand 로고 모양으로 svg path를 작성한 컴포넌트인데 굉장히 복잡합니다. Zustand 로고는 복잡하지만 그래도 오피셜 로고를 넣어야겠다 싶어서 넣은 것이었는데 저러한 요인이 문제를 일으킬 수도 있는 것 같습니다. 그래서 저 부분을 일시적으로 다른 스택 로고로 변경해 보았습니다.

 


점수는 그대로군요


하지만 아래 Zustand 로고 관련 경고가 사라졌고 총 돔 요소 개수가 많이 줄었습니다. 성능 점수 자체는 오르지 않았지만 이 또한 일종의 최적화를 한 것이라고 할 수 있습니다. 

 

 

자바스크립트 번들 최적화

 

페이지스피드 보고서에서 보이는 또 하나의 경고는 바로 이것이었습니다.

 

 

저 파일은 프로젝트 빌드시 생성되는 자바스크립트 번들 파일입니다.

 

검색해 보니까 많은 사람들이 성능 최적화를 위해 자바스크립트 번들 최적화를 시도하는 것 같았습니다. 이를 최적화하려면 어떻게 해야 할까요?

 

 

@next/anaylzer로 자바스크립트 번들 분석

 

next-analyzer는 자바스크립트 번들 크기를 시각적으로 분석할 수 있게 해주는 Next.js 전용 라이브러리입니다. 

라이브러리를 설치하고 설정을 마친 후 빌드하면 이렇게 각각의 번들 크기를 볼 수 있는 화면이 새창으로 뜹니다. 

(Node.js/Client.. 이렇게 나눠서 뜨는데 Client에 해당하는 창을 보면 될 것 같습니다.)

 

 

 

 

왼쪽 하단의

 

static/chunks/684-02f7adea1028fe15.js

 

이게 아까 언급된 파일명입니다. 그래서 저 남색 블록들을 잘 찾아보면 이유를 알 수 있지 않을까 싶었습니다. 하지만 여기서 무언가를 더 알아내진 못했습니다.

 

데브툴의 Coverage 탭 살펴보기

 

 

3번째에 아까 언급했던 684-02f7adea1028fe15.js 파일이 있습니다. Usage Visualization은 저 JS 파일의 코드를 얼마나 사용하고 있는지를 보여줍니다. 이 파일은 빨간색이 45.5%인데 이 자바스크립트 코드 중 약 45.5%는 사용되지 않고 있다는 것입니다. 하지만 제가 이 부분을 당장 최적화하기는 어려울 것 같았습니다. 

 

 

최종 결과

 

이후 코드 정리와 웹 접근성 관련해서 정리하고 재사용성을 리팩토링하고 그런 과정을 거쳤습니다. 그리고 다시 검사를 해보니까 페이지스피드의 성능 점수는 100점이 되었습니다. 

 

 

 

확장 프로그램의 라이트하우스에서는 여전히 99점이지만요.

 

 

 

성능 개선 도전 후기

 

결국 성능 점수가 낮았던 원인 중 핵심은 폰트 관련 이슈였습니다. 중간에 빙빙 돌아가는 삽질을 좀 했지만 그래도 새로 배우거나 접한 게 많아서 그 과정 자체는 좋은 경험이 되어준 것 같습니다. 

 

테스트가 막상 원활하게만은 진행되지 않았던 것은 배포하고 곧바로 구글 확장프로그램의 라이트하우스나 페이지스피드 검사 시 100점 또는 100점에 가까운 점수가 나오는 일시적인 현상을 보였기 때문입니다. 아마 중간의 EC2 배포 테스트에서 CSS 적용이 안 된 상태에서 성능 점수가 100점이 나온 것도 일시적인 현상일 가능성이 높을 것이라고 생각합니다. 

 

그리고 이 점수는 이 웹사이트가 가벼운 포트폴리오 프로젝트이기에 쉽게 도달한 것일 가능성이 높습니다. 가벼운 프로젝트라서 이전의 EC2 배포가 원활했던 것처럼 말입니다. 복잡한 로직과 더 큰 규모의 프로젝트에서 이 점수를 달성하는 것은 또 다른 차원의 문제일 것입니다. 

 

 

마무리

 

아쉽지만 일단 성능개선은 여기까지 하겠습니다.

 

99점도 충분히 좋은 점수라고 생각합니다. 그리고 데브툴의 라이트하우스와 구글 확장 프로그램 페이지스피드에서는 목표를 달성했으니까요. 그리고 앞으로도 계속 포트폴리오의 기능은 추가되거나 변경될 것이고 성능 점수는 다시 떨어지게 될 것입니다. 그러면 그때 가서 그 상황에 적절한 최적화 방법을 찾아야 할 것입니다. 

 

효율성의 관점에서 이제 다음 단계로 넘어갑니다. 

 

 

 

 

'FE > Next.js' 카테고리의 다른 글

[Next.js] AWS EC2로 Next.js를 배포할 때 Node.js를 설치해야 하나요?  (0) 2025.05.16
[Next.js] 왜 Next.js는 "풀스택" 프레임워크라고 불리는가?  (0) 2025.05.03
[Next.js] Yarn berry로 Next.js 프로젝트 시작하기  (0) 2025.03.13
[Next.js] App Router에서의 CSS-in-JS 사용과 한계  (0) 2025.03.11
[Next.js] App Router에서는 어떤 CSS 방식을 사용해야합니까?  (0) 2025.03.06

'FE/Next.js'의 다른글

  • 현재글[Next.js] 포트폴리오 성능 점수 100점 도전하기 (feat. 라이트하우스, 폰트 최적화)

관련글

티스토리툴바