Performance

100% 수집이라는 환상이 운영 비용을 잡아먹는다 분산 아키텍처로 전환하고 나면 팀은 자연스럽게 모든 요청을 추적하고 싶어합니다. 우리 팀 역시 초기에 OpenTelemetry SDK를 붙이고 모든 trace를 Jaeger로 내보내는 설정을 처음 기본값으로 택했습니다. 문제는 트래픽이 늘면서 빠르게 드러

필드 데이터 없이 성능 개선을 논하는 것은 환자 없이 처방을 쓰는 것과 같다 Lighthouse 점수 100점을 받아도 CrUX(Chrome User Experience Report) 대시보드에 "Poor" 판정이 뜨는 경험을 해봤을 것입니다. 우리 팀은 대형 이커머스 프로젝트에서 정확히 이 상황을 겪었

클릭했는데 화면이 늦게 반응하는 이유 웹 성능을 이야기할 때 오랫동안 LCP와 CLS가 중심이었습니다. 첫 화면이 빨리 뜨고 레이아웃이 흔들리지 않는 것은 여전히 중요합니다. 하지만 사용자가 실제로 서비스를 "빠르다"고 느끼는 순간은 버튼을 눌렀을 때 화면이 즉시 반응하는가에 달려 있습니다. Intera

캐시는 빨랐지만 장애는 더 빨리 왔다 캐시는 백엔드 성능 최적화에서 가장 먼저 떠올리는 도구입니다. Redis를 앞에 두면 데이터베이스 조회를 줄이고, p95 응답 시간을 낮추고, 트래픽 피크를 흡수할 수 있습니다. 그런데 캐시는 제대로 설계하지 않으면 장애를 막는 장치가 아니라 장애를 증폭시키는 장치가

JavaScript의 한계가 드러나는 순간: 핫패스를 Rust로 옮긴 1년의 기록 우리 프론트엔드 개발자들은 V8 엔진의 JIT 컴파일러를 신뢰합니다. 평범한 폼 검증, 라우팅, 상태 관리 같은 일반 워크로드라면 굳이 더 빠른 무언가를 찾을 이유가 없습니다. 그러나 어느 화면에든 한두 군데의 핫패스(ho

웹 성능은 사용자 경험과 비즈니스 성과를 좌우하는 핵심 요소입니다. 구글의 연구에 따르면 페이지 로딩 시간이 1초에서 3초로 늘어나면 이탈률이 32% 증가하고, 5초가 되면 90%까지 치솟습니다. 이 글에서는 프론트엔드 개발자가 반드시 알아야 할 웹 성능 최적화 기법들을 체계적으로 정리해 봅니다. 1.

들어가며 — gzip을 "당연히 켜는 것"으로 다뤄온 우리의 착각 Nginx 설정 파일을 열고 gzip on; 한 줄을 추가한 뒤 "자, 압축 완료"라고 PR을 닫은 경험이 있다. 어느 날 저녁 CDN 로그를 보다가 JPEG 이미지 응답에 Content Encoding: gzip 이 찍혀 있는 걸 발견했

캐시는 서버 앞에 놓는 성능 예산이다 웹 서비스가 느려질 때 가장 먼저 떠올리는 해결책은 서버 증설입니다. 하지만 모든 요청을 오리진까지 보내는 구조라면 서버를 늘려도 같은 종류의 비용이 반복됩니다. 정적 자산, 공개 API, 변경 빈도가 낮은 문서, 상품 목록 일부는 매번 데이터베이스와 애플리케이션 서