| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | 31 |
- Lighthouse
- Python
- html5
- object
- lcp
- 햇소
- This
- CSS
- 함수
- 변수
- 최적화
- react
- es6
- next.js
- github
- dev
- ES6+
- 성능
- DOM
- JS
- array
- hatso
- git
- 선택자
- hooks
- learn next.js
- AI
- ChatGPT
- API
- JavaScript
- Today
- Total
목록전체 글 (130)
codinghatso
일반 CDN vs 이미지 CDN 차이일반 CDN이 데이터를 '단순 배달'한다면, 이미지 CDN은 데이터를 사용자에 맞게 '가공 후 배달'.구분General CDNImage CDN핵심 역할오리진 서버 파일의 단순 복사 및 전송이미지 실시간 최적화, 변환 및 전송주요 대상HTML, CSS, JS, 비디오, 대형 파일 등JPEG, PNG, WebP, AVIF 등 이미지 파일동작 방식원본 파일 그대로 캐싱하여 전달디바이스 환경에 맞춰 실시간 리사이징/압축 후 전달주요 기능대용량 트래픽 분산, 네트워크 지연 감소포맷 변환(WebP), 크기 조절, 워터마크 삽입 등 1. 일반 CDN 사용 예시동영상 스트리밍 서비스: 넷플릭스, 유튜브 등 대용량 비디오 파일 전송웹 서비스 에셋 파일: 전 세계 사용자가 접속하는 웹 ..
클라이언트 측에서 사전 최적화하는 것을 적용하려 합니다.크기별 반응형 이미지 생성Supabase Storage CDN 활용정확한 srcset / sizes 명시이미지 자세히 보기 사용 시 원본 로딩클라이언트에서 이미지 CDN이 할 “변환 작업”을 미리 수행하고, 결과 파일은 Supabase 기본 CDN으로 전달한다는 개념을 적용했습니다. 사용자가 이미지 업로드시최대 1600px 정도로 제한WebP 변환320 / 480 / 640 / 800 / 1200 생성Supabase Storage 업로드정리하면 이미지 전송 개선을 성공했음 현재 리소스 크기가 1,278 kiB -> 875.2 kiB로 개선된 상태입니다.이미지 전송을 더 개선하는 방향이 있겠지만 우선 CLS를 개선하는 게 더 효율적이라고 생각해서 CL..
렌더링 요청 연쇄 제거 작업을 완료했습니다발견한 문제점핵심은 첫 렌더링 때에 API 요청이 절차적으로 실행되는 폭포수 형태의 구조이고 세부적으로알람 기능과 프로필 기능에서 문제점을 찾을 수 있었다.알람은 전체 알람 목록과 새롭게 추가된 알람 개수를 모두 조회하는 구조이다.프로필 데이터는 사용자가 index 페이지에서 사용하지 않는다. 개선 방향새로운 알람 갯수를 조회하는 데이터 요청과 알람 전체 데이터 조회를 분류하고 알람 창을 누를 때 전체 데이터를 요청하도록 한다.프로필 데이터는 프로필 창을 렌더링할 때 데이터 요청하도록 구조를 바꾼다. LCP 1.26초 -> 0.60초0.66초 약 52.38% 개선TTFB 21ms -> 4ms17ms 약 80.95% 개선리소스 로드 지연 1,147ms -> 497m..
Chunk의 사전적 의미는 큰 조각이다.Javascript 큰 파일을 나누어 여러 개의 작은 파일(Chunk)로 쪼개는 것이다. 중요한 파일 조각부터 다운로드하으면서 불러오는 속도를 개선하는 방식으로 사용할 수 있다. 즉, 청크는 쉽게 말해 브라우저가 필요할 때 나눠서 다운로드하는 JavaScript 파일 조각입니다. 초기 청크를 작게 만들면 최초 다운로드·파싱·실행 시간이 줄어들 수 있지만, 너무 잘게 나누면 네트워크 요청과 로딩 화면이 많아질 수 있습니다. https://web.dev/articles/granular-chunking-nextjs?hl=ko 세분화된 청크 분할로 Next.js 및 Gatsby 페이지 로드 성능 개선 | Articles | web.devNext.js와 Gatsby가..
import { lazy, Suspense } from "react";lazyhttps://ko.react.dev/reference/react/lazy lazy – ReactThe library for web and native user interfacesko.react.devreact.lazy()를 사용하면 컴포넌트가 처음 렌더링될 때까지 해당 컴포넌트의 코드를 로딩하는 것을 지연할 수 있습니다.react.lazy()로 랜더링 필요할 때 랜더링 되게 할 수도 있다. 만약 아래코드 처럼 사용하면 첫 번째 랜더링 이후에 정적인 파일이 import 되게 유도할 수 있다.익숙하지 않은 문법이라 하나씩 적용하며 익혀보겠다. 지금으로선 성능향상에 도움이 되는 방식 같아 보인다.import { lazy } from..
발견한 개선점들 초기 JS가 단일 파일 726KB, gzip 221KB입니다. 모달, 이미지 뷰어, 모든 라우트까지 처음부터 포함됩니다./src/root-route.tsx, src/provider/modal-provider.tsx세션 확인 후 프로필 조회가 끝날 때까지 전체 앱을 로더로 막습니다. 그 뒤에야 피드 요청이 시작됩니다./src/provider/session-provider.tsx게시글 이미지는 최대 1920px WebP 하나만 저장하고, 화면 크기에 맞는 썸네일은 없습니다. 또한 첫 페이지의 캐러셀 이미지가 모두 eager 요청될 수 있습니다./src/lib/image-optimizer.ts, /src/components/post/post-item.tsx20px로 표시하는 로고 원본이 378..
이번 목표는 폰트 최적화입니다.폰트를 최적화함으로써 LCP와 CLS를 개선되는 것이 기댓값입니다. 먼저 CLS(Cumulative Layout Shift, 누적 레이아웃 이동)는 웹 페이지가 로드되거나 상호작용하는 동안 발생하는 예기치 않은 화면 요소의 밀림이나 이동을 측정하는 시각적 안정성 지표를 말합니다. 네이버 외부 CSS 연결을 제거하고 폰트 파일을 프로젝트 내부에서 직접 관리하는 방식으로 바꿨습니다.font-display: swap을 적용하고, 대체 글꼴의 크기 차이로 발생하는 CLS는 폰트 측정값 재정의로 줄입니다.woff2로 변환하기 위해서 brew install woff2 변환도구를 설치합니다.변경한 코드 값들은 작성하지 않겠습니다. 현재 발견한 문제점 3가지 네이버 CSS의 @font-f..
LCP(Largest Contentful Paint) 개선해보기콘텐츠가 포함된 최대 페인트 (LCP)는 Lighthouse 보고서의 성능 섹션에서 추적하는 측정항목 중 하나입니다.각 측정항목은 페이지 로드 속도의 일부 측면을 포착합니다.Lighthouse는 LCP를 초 단위로 표시합니다.가장 큰 콘텐츠 요소가 화면에 렌더링되는 시점을 측정한 것 입니다.LCP를 개선하는 방법LCP가 이미지인 경우 타이밍은 4개의 하위 부분으로 나눌 수 있습니다. 가장 오래 걸리는 하위 부분을 알면 LCP를 최적화하는 데 도움이 됩니다. Lighthouse는 '최대 콘텐츠 페인트 요소' 진단에서 하위 요소 분석과 함께 LCP 요소를 표시합니다. 첫 바이트까지의 시간 TTFB로드 지연로드 시간렌더링 지연위처럼 LCP를 최적화..