코드 땜장이

큰 이미지가 느릴 때 렌더링 속도를 높이는 법: 포맷, 크기, 로딩 전략 한 번에 정리 빠른 답 원본 이미지를 그대로 내려보내지 말고 실제 표시 크기와 DPR에 맞춘 파일을 서버나 CDN에서 변환해 제공합니다. AVIF와 WebP를 우선하되 로 JPEG 또는 PNG fallback을 함께 두어 브라우저 호환성을 확보합니다. 첫 화면 핵심 이미지는 무조건 lazy 처리하지 말고 fetchpriority="high" 또는 preload를 검토하고, 나머지 이미지만 지연 로딩합니다. Network와 Performance 패널에서 전송 크기, 선택된 소스, 디코드 시간, LCP 후보 이미지를 함께 봐야 병목을 정확히 찾을 수 있습니다. 브라우저 렌더링 흐름을 중심으로 초안을 다시 정리하고, 현재 기준의 포맷 지원과 우선순위 관련 공식 문서 포인트를 짧게 확인하겠습니다. 오래된 설명과 지금 설명이 갈리는 부분도 함께 정리해서 발행용 본문으로 맞추겠습니다.# 큰 이미지가 느릴 때 렌더링 속도를 높이는 법: 포맷, 크기, 로딩 전략 한 번에 정리 목차 시간 흐름으로 이해하기 흐름으로 보기 브라우저 안에서 실제로 무슨 순서로 일어날까 큰 이미지가 느린 이유는 다운로드만이 아니다 현재 기준 포맷 선택과 오래된 설명의 차이 요청 시점과 우선순위 다루기 표시 크기와 레이아웃 안정성 맞추기 CDN, 캐시, 변환 파이프라인에서 줄일 수 있는 비용 DevTools로 병목 확인하기 무엇부터 바꾸면 좋을까 공식 문서와 레퍼런스 시간 흐름으로 이해하기 HTML 파싱 시점 img 는 비교적 빨리 발견되지만 CSS 배경 이미지는 CSS를 읽은 뒤에야 요청 후보가 되는 경우가 많습니다. → 전송 시점 파일 크기, 캐시 적중 여부, CDN 거리 차이가 첫 바이트와 다운로드 시간을 바꿉니다. → 디코드 시점 압축된 파일을 화면용 비트맵으로 풀어내는 과정에서 CPU와 메모리를 사용합니다. → 레이아웃 시점 이미지 비율이 늦게 확정되면 자리 계산이 다시 일어나고 CL...

웹 애플리케이션 성능 최적화, 로딩 경로별로 정리하는 핵심 방법 빠른 답 첫 화면에 필요 없는 JavaScript는 분리하고 늦게 불러와야 초기 로딩이 빨라집니다. 이미지와 비디오는 화면에 보일 때 로드하고, 크기와 포맷을 먼저 줄여야 체감 성능이 좋아집니다. 캐시는 단순 저장이 아니라 정적 자산과 HTML의 정책을 다르게 가져가야 효과가 큽니다. 최적화는 감으로 하지 말고 Network, Performance, Lighthouse 같은 측정 결과로 우선순위를 잡아야 합니다. 목차 왜 웹 성능은 로딩 경로로 봐야 할까 흐름으로 보기 요청 시작과 리소스 다운로드에서 생기는 병목 파싱과 실행: DOM, CSSOM, JavaScript가 서로 만나는 지점 렌더링: 렌더 트리, 레이아웃, 페인트, 컴포지팅의 비용 초기 로딩을 줄이는 설정 무거운 자산을 늦게 가져오는 방법 재방문 속도를 높이는 캐시 전략 DevTools로 병목을 반복 측정하는 방법 흔한 오해와 함께 보는 정리 포인트 왜 웹 성능은 로딩 경로로 봐야 할까 같은 300KB라도 언제 내려오고 무엇을 막느냐에 따라 체감은 크게 달라집니다. 첫 화면에 바로 필요한 CSS 300KB와, 아직 열지 않은 설정 페이지의 JavaScript 300KB는 사용자 경험에 미치는 영향이 다릅니다. 그래서 성능 최적화는 파일 크기를 줄이는 일에만 머물지 않고, 어떤 자원이 어떤 단계의 병목이 되는지 파악하는 작업에 가깝습니다. 브라우저 관점에서 병목은 보통 세 갈래로 나타납니다. 네트워크에서 늦게 내려오는 경우, JavaScript 파싱과 실행 때문에 메인 스레드가 오래 묶이는 경우, 렌더링 단계에서 레이아웃과 페인트가 반복되는 경우입니다. 이 세 지점을 로딩 경로 하나로 묶어 보면 코드 스플리팅, 레이지 로딩, 캐시, CSS 최적화가 각각 어디에 영향을 주는지 자연스럽게 연결됩니다. 흐름으로 보기 이 순서를 먼저 잡아두면 최적화 기법의 위치가 정리됩니다. 코드 스플리팅과 defer 는 초기 다운로드와...

script async와 defer 차이, 실행 시점과 선택 기준까지 한 번에 정리 빠른 답 async는 다운로드가 끝나는 즉시 실행되어 HTML 파싱을 끊을 수 있습니다. defer는 문서 파싱이 끝난 뒤 선언 순서대로 실행되어 앱 초기화 코드에 안전합니다. 의존성이 없고 독립적으로 동작하는 외부 스크립트는 async가 잘 맞습니다. 실행 순서와 DOM 준비 시점이 중요하면 defer를 먼저 검토하는 것이 실무적으로 안전합니다. 목차 한눈에 비교 왜 둘 다 비동기인데 체감은 다를까 흐름으로 보기 HTML 파싱과 렌더링 사이에서 스크립트가 끼어드는 지점 async가 맞는 경우와 defer가 맞는 경우 설정 예시로 보는 배치 전략 콘솔과 DevTools로 실행 순서 확인하기 자주 놓치는 예외: inline script와 module script 선택 기준을 한 줄로 정리하면 한눈에 비교 Point 1 다운로드: async 와 defer 모두 HTML 파싱과 병렬로 다운로드를 시작할 수 있습니다. Point 2 실행 시점: async 는 다운로드가 끝나는 즉시 실행되고, defer 는 문서 파싱이 끝난 뒤 실행됩니다. Point 3 실행 순서: 여러 async 스크립트는 먼저 받아진 순서대로 실행되고, 여러 defer 스크립트는 문서에 적은 순서대로 실행됩니다. Point 4 DOM 접근 안정성: async 실행 시점에는 DOM이 아직 덜 만들어졌을 수 있지만, defer 는 문서 파싱 후라 DOM 접근이 훨씬 예측 가능합니다. Point 5 DOMContentLoaded 관계: defer 와 기본 module 스크립트는 DOMContentLoaded 전에 실행되며, 이 이벤트는 그 실행을 기다립니다. async 는 보통 그 흐름 바깥에서 실행됩니다. 왜 둘 다 비동기인데 체감은 다를까 헷갈리는 이유는 둘 다 “비동기로 로드된다”는 문장만 기억하기 쉽기 때문입니다. 하지만 실제 성능과 렌더링에 더 큰 영향을 주는 것은 다운로드 자체보다 스크립트...