공부? 공부?

1. Lighthouse 측정Lighthouse를 측정하다가 LCP 점수가 다른 점수에 비해 낮게 측정되는 것을 발견했고 아래의 경고가 뜨는 것을 발견했다.이게 점수 하락의 원인이라고 생각하고 번들을 최적화 하기로 했다. 2. Analyze 확인 해당 번들이 무엇인지 확인하기 위해nextjs가 제공하는 analyze를 사용했다.npm run analyze **번들 이름이 없을 경우**NextJS는 기본적으로 개발환경에서는 터보팩으로 번들링을 한다그렇기 때문에 번들 이름이 다르게 나온다.나는 개발환경에서도 웹팩으로 번들링을 하도록 pakage.json에 추가 설정을 하였다. "build": "next build --webpack", 3. 번들 분석 크게 Zod와 Supabase의 SSR 번들..

1. 번들링과 스플리팅 1-1. 번들링이란 1-2. 스플리팅이란2. 번들링과 스플리팅의 방법 2-1. 번들링의 방법 2-2. 스플리팅의 방법3. 번들 분석 도구4. 실제 적용 4-1) 분석 4-2) 과정 4-3) 결과 1. 번들링과 스플리팅 1-1) 번들링이란?각 페이지마다 나눠져 있는 코드를 하나의 파일로 합치는 것이다.만약 개발자의 환경처럼 파일이 전부 나눠져 있는 상태로 서비스를 운영한다면 페이지 요청마다 여러 파일의 요청이 필요하게 되고 여러번의 HTTP 요청이 발생할 것이다. 하지만 번들링으로 파일을 하나로 합친다면 하나의 파일만으로 요청을 처리할 수 있어서 속도와 효율성을 올릴 수 있다. 개발자는 평소처럼 컴포넌트를 나눠서 작업하고, 빌드 시 번들러(Webpack, Turbo..

배포 자동화 계획 수립 로컬에서 코드 작성 후 매번 SSH에 직접 접속하여 Git pull을 하는 과정이 너무 번거롭다고 생각이 되어배포 자동화에 대한 경험을 축적할 겸 Git Actions를 사용하여 배포자동화를 진행해 보았다. 더보기GitHub Actions란?GitHub에서 제공하는 CI/CD 도구. 레포지토리에 .github/workflows/ 폴더에 yml 파일을 작성하면 특정 이벤트(push, PR 등)가 발생했을 때 자동으로 실행된다GitHub Actions가 제공하는 서버(runner)에서 실행되기 때문에 별도 서버가 필요 없다. Git Actions을 사용한 배포 자동화 워크플로우로컬에서 push -> git actions가 이를 감지 -> deploy.yml 내용 따라 워크플로우 진행 ..

1. 왜 HTTPS가 필요한가TLS(SSL)인증으로 인한 보안성 증가암호화/복호화 비용이 발생하지만 비싸지 않고, HTTP2의 멀티플렉싱과 헤더압축으로 HTTP와 비슷하거나 더 빠른 속도 보장신뢰성 증가로 인한 구글 랭킹 증가와 Lighthouse SEO 점수 증가 2. 사전 준비배포 서버(기존에 AWS EC2에 배포한 서버 + docker compose 컨테이너 기반(프로젝트,nginx포함) 배포)도메인(기존에 가지고 있던 GoDaddy 도메인 준비)배포 서버에 Node.js 설치Node.js를 설치 방법으로 크게 apt, nodesource, nvm 방식이 있다는 것을 알았다.apt는 최신 노드버전을 쓰지 못하기 때문에 제외했고 추후 Git Actions로 배포자동화를 할 때를 대비하여 전역 환경변수..

이미지 성능 최적화 전략 1. 문제- 크롬 개발자도구의 네트워크 탭을 통해 이미지 리소스가 전체 네트워크 요청의 상당 부분을 차지하고 있음을 확인했다. 이미지 수가 늘어날수록 초기 페이지 로딩 성능에 직접적인 영향을 줄 것으로 판단하여 이미지 최적화를 진행하기로 했다. 2. 방법 이미지 최적화 방법에 대해 알아보았다. 2-1) 포맷 최적화JPEG/PNG → WebP/AVIF 변환WebP는 JPEG 대비 25~35% 용량 절감AVIF는 WebP보다 더 효율적이지만 브라우저 지원이 아직 제한적2-2) 크기 최적화표시 크기에 맞게 리사이즈 (2000px 원본을 400px로 표시하면 낭비)반응형: 화면 크기별로 다른 크기 제공 (srcset)해상도별: 레티나 디스플레이용 2x 이미지2-3) 로딩 전략Lazy L..

문제 상황 - 게시글의 조회수 중복 증가해결 방법 - Zustand 도입이유 - 게시글 조회수의 중복 증가를 방지하고 싶었다. 그러기 위해서는 새로고침을 해도 값이 유지되어 지속적으로 관리 가능한 상태관리가 필요했다.localStorage만 쓰지 않은 이유는, localStorage 값이 변경되어도 React 렌더링이 일어나지 않기 때문이다. 렌더링이 없으면 UI와 실제 데이터 간의 동기화가 깨진다. Zustand는 React 상태로 값을 관리하기 때문에 상태가 변경되면 리렌더링이 발생한다. 여기에 persist 미들웨어를 적용하면, 상태가 변경되는 시점에 localStorage와 자동으로 동기화되어 새로고침 후에도 값이 유지된다.React Query는 서버 상태관리이고, 본 글 목록은 클라이언트 상태이..

문제- 로그아웃해도 Header에 로그아웃 된 상태로 즉시 적용 되지 않는 것을 발견 문제 파악 과정1. 대략적으로 Header.tsx의 상태관리문제 일 것으로 생각하고, 아마 로그아웃시 상태관리 캐시가 제대로 초기화되지 않았을까 추측하여 Header.tsx 코드를 확인 2. 추가적으로 콘솔에 에러가 뜨는 것을 확인 3. 확인 결과 서버엑션에서 로그인 여부 확인 부분에서 에러가 발생하고, useLogout의 아래부분이 문제인 것을 확인 4. 내가 생각한 로그인/로그아웃 플로우 차트 알람 useQuery와 프로필 useQuery에 enable을 사용하여, 실행 전 useUser로 로그인 여부를 확인하고 로그인 했을 때만 실행이 되도록 함. 그래서 위 처럼 동작하는 것으로 이해했음 5. 실제 동작하는 부..

기존 코드 UI 파일에서 위와 같이 ReactQuery를 이용하여 데이터를 페칭함 Lighthouse 테스트를 해본 결과 SI(콘텐츠가 시각적으로 표시되는 진행 속도)가 너무 낮은 것을 확인하였다.Performance를 확인해봤다. 그래프가 높은 부분을 보고 시간이 제일 오래 걸리는 것을 추적해보니 UI에서 실행중인 함수들인 것으로 확인 됐다. 그래서 서버에서 미리 데이터를 페칭하여 ui단으로 보내주는 SSR 처리를 하였고 병렬로 처리할 수 있게 하였다. 그 후 Performance 확인 그 결과 전체 시전 시간도 2,100ms 정도로 짧아지고빨간 부분도 줄어든 것으로 확인 됐다. SSR 적용 후 Lighthouse 점수도 현저히 높아진 것을 확인했다.