# Lazy loading
[TIL] 웹 화면 최적화 방법
📍 Image Lazy Loading 웹 페이지 성능을 향상시키기 위해 사용되는 기술 중 하나로, 웹 페이지에서 이미지를 불러올 때 페이지가 처음 로드될 때 모든 이미지를 동시에 불러오지 않고 필요한 이미지를 필요한 시점에 불러오는 방식임. 즉, 페이지 안에 있는 이미지들이 실제로 화면에 보여져야 할 때 로드되도록 하는 방식으로, 웹 페이지 내에서 바로 불러오지 않고 그 시점을 뒤로 미루는 것임. 이렇게 하면 페이지의 초기 로딩 시간을 단축하고, 사용자 경험을 향상시킬 수 있음. (웹 성능 및 디바이스 내 리소스 활용도 및 이와 연관된 비용을 줄일 수 있음) 🌸 [추가] Lazy Loading이란? 페이지 내에서 사용되는 리소스가 실제로 필요할 때까지 불러오는 그 시점을 미루는 것으로, Image Lazy Loading은 이 방식의 한 종류임. 페이지를 로드하자마자 리소스를 불러오는 기존 방식 대신, 실제로 사용자 화면에 보여질 필요가 있을 때
JPA 지연 로딩(Lazy Loading)과 즉시 로딩(Eager Loading)
✅JPA에서 지연 로딩(Lazy Loading)과 즉시 로딩(Eager Loading)는 엔티티 간의 관계를 마련할 때 데이터를 가져오는 전략을 결정하는 방법입니다. 이 두 가지 로딩 전략의 차이점에 대해 자세히 살펴보겠습니다. 👉지연 로딩(Lazy Loading) 지연 로딩은 관련된 엔티티를 실제로 사용할 때까지 로드를 연기하는 방법입니다. 엔티티를 처음 로드할 때 관련 연관 엔티티를 한 번에 가져오지 않고, 필요한 시점에 데이터베이스에서 추가적인 조회를 통해 가져옵니다. 이 방법은 성능상 이점이 있는 경우가 많습니다. 예를 들어, 게시물(Post)과 댓글(Comment)이 있는 상황에서 특정 게시물을 가져오고자 할 때, 지연 로딩 전략을 사용한다면 처음에는 게시물(Post)만 가져옵니다. 이후 댓글(Comment) 정보가 필요한 경우 데이터베이스에서 해당 정보를 로드합니다. 위 코드에서 Post 엔티티는 Comment 엔티
Eager/Lazy Loading 과 N+1 Problem
좋은 쿼리를 위해서는 적절한 쿼리문 생성, 인덱스 사용 등과 같이 쿼리 속도 향상을 위한 방법이 필요하다. 내가 작성한 PR 에서 "이렇게 하면 쿼리 속도가 느리지 않을까요?" 혹은 "쿼리가 이상해요!" 라는 코멘트를 받지 않으려면 N+1 Problem 이라는 개념을 꼭 알고 있어야 한다. N+1 Problem 이란? 한번의 쿼리로 가져올 수 있는 데이터에서 관련된 데이터를 가져오기 위해 N 번의 쿼리를 다시 질의해야 하는 문제이다. 예를 들어 아래 쿼리를 보자. 빌딩의 세입자를 가져오기 위해서 빌딩을 쿼리 질의 하고, 이어서 빌딩에 있는 모든 호수를 반복해서 질의한다. DB는 쿼리 질의가 비용과 연결되기 때문에, 매우매우 비효율적인 방법이라고 할 수 있다. N+1 Problem 을 해결하기 위해서는? join 을 사용 하면 쉽다! 하지만 우리는 어플리케이션 단에서 해결해보자고 한다. (라라벨 기준) **Lazy loading
Optimazing / Lazy Loading 번역
WYSIWYG 에디터를 쓰며 공식문서를 읽어야하는 부분이 발생해서 번역했다. 게으른 로딩(Lazy Loading) Next.js에서의 게으른 로딩은 라우트를 렌더링하는 데 필요한 JavaScript 양을 줄여 애플리케이션의 초기 로딩 성능을 개선하는 데 도움이 됩니다. 이를 통해 클라이언트 컴포넌트와 가져온 라이브러리의 로딩을 지연시킬 수 있으며, 필요할 때만 클라이언트 번들에 포함시킵니다. 예를 들어, 사용자가 모달을 열 때까지 로딩을 지연시킬 수 있습니다. Next.js에서 게으른 로딩을 구현하는 방법은 두 가지입니다: next/dynamic과 dynamic import를 사용합니다. React.lazy()와 [Suspense](https://re
이미지 최적화와 Lazy Loading
개요 > 웹 페이지의 성능 최적화는 사용자 경험을 향상시키고 페이지 로딩 속도를 개선하는 데 중요한 역할을 합니다. 이미지는 웹 페이지에서 주요한 자산이지만, 그 크기와 로딩 방식에 따라 성능에 큰 영향을 줄 수 있습니다. 이 포스팅에서는 이미지 최적화와 Lazy Loading 기술을 활용하여 웹 성능을 향상시키는 방법을 자세히 알아보겠습니다 1. 이미지 최적화 웹 페이지에서 사용되는 이미지는 대부분 고해상도의 사진이나 그래픽 요소입니다. 이러한 이미지는 크기가 크고 다운로드에 시간이 걸리므로, 최적화된 이미지를 사용해야 합니다. 이미지 최적화를 위해 다음과 같은 접근 방법을 사용할 수 있습니다. 이미지 포맷 선택 JPEG, PNG, GIF, WebP 등 이미지 포맷의 특징과 사용 사례를 파악하여 최적의 포맷을 선택합니다. 이미지 압축 이미지 파일의 용량을 줄이기 위해 압축 도구나 온라인 서비스를 활용합니다. 압축 과정에서 이미
Lazy Loading 과 SSR의 서버사이드 관련 차이점
Lazy와 SSR이 어떻게 보면 비슷하지 않을까? 언제 한번 이런 이야기를 들은 적이 있다. > SSR이 서버와의 통신을 통해 자바스크립트를 Hydrate해준다면, lazy도 어떠한 관점에서 바라보면 해당 페이지나 컴포넌트에서 필요한 자바스크립트 번들 파일을 다운받아서 채워주지 않는가. 그렇다면 그 둘은 어떻게보면 비슷할 수도 있고, SSR이 사용되는 환경에서는 Lazy가 필요없지 않을까? 이 질문을 듣고서 어디 나가서, 저 Next.js 얕게라도 써봤고, SSR의 구조도 어느정도 파악한 사람인 것 같아요!! 라고 이제는 말을 못하게 되었다. 어찌됐든 SSR도 해당 페이지나 컴퍼넌트를 로드할 때, Lazy 처럼 불필요한 네트워크 리소스를 막기 위해서 해당 부분의 로드를 뒤로 늦춰서, 먼저 접근
어떻게 유저를 붙잡을 수 있을까?
속도가 느린 웹사이트의 사용자 이탈율은 높을 수 밖에 없습니다. 그렇기에 웹사이트 속도 향상을 위한 노력은 개발자의 숙명과도 마찬가지입니다. 속도 성능 향상을 위해서는 여러가지 방법들이 존재하지만 이번 시간은 그 중 일부인 lazy loading, code splitting, suspense, automatic batching에 대해 알아보고자 합니다 :) 1. 지연 로딩 (Lazy Loading) > 웹사이트 페이지의 리소스를 필요할 때 불러와주는 친구! 지연 로딩이란 ? 사용자가 페이지를 읽어들이는 시점에 필요한 리소스들이 우선 로드가 되고, 그 외 리소스들은 사용자가 필요로 할 때 추후에 로드하는 방법을 의미. 지연 로딩이 나오게 된 배경 일반적으로 웹 페이지가 열리면 페이지 전체가 렌더링 되어 모든 내용이 다운로드 됨. 브라우저가 웹 페이지를 캐싱한다는 점은 좋지만 다운로드 된 전체 내용을 사용자가 모두 확인할지는 미지수. 사용자가 확인하지 않는 리
즉시로딩(Eager Loading)과 지연로딩(Lazy Loading)
즉시로딩(Eager Loading) vs 지연로딩(Lazy Loading)   Spring Data JPA에서 @XXXToOne으로 연관관계가 설정되어 있는경우 기본적으로 즉시로딩(Eager Loading)으로 처리하게 됩니다. 이는 불필요한 join 쿼리가 포함되기 때문에 지연로딩(Lazy Loading)의 사용이 권장됩니다. (단 @XXXToMany는 기본적으로 지연로딩(Lazy Loading)) 지연로딩(Lazy Loading)은 객체의 초기화를 지연시켜 로딩하는 방법으로써 실제 객체 대신 프록시 객체를 로딩 해두고 해당 객체를 실제 사용할 때만(ex. getter 메서드를 사용할 때) 영속성 컨텍스트를 통해 실체 객체를 호출하는 로딩입니다. 즉시로딩(Eager Loading) 예시   Member엔티티와 Team엔티티는 N대1 관계   테스트 코드에서 확인 
[JS] - BUG: `Can't' find variable: IntersectionObserver`
프론트엔드 개발자이며 페이지 성능에 관심이 있다면 화면에 보이지 않는 이미지를 레이지 로딩하기 위해 IntersectionObserver을 사용해본 사람이 많을 것이다. IntersectionObserver? IntersectionObserver는 브라우저의 빌트인 자바스크립트 API이며 상대적으로 최신 브라우저들에서만 지원 뷰포트 내에 특정 엘리먼트가 보이는지에 대한 여부를 비동기적으로 확인할 수 있다 이를 사용하여 뷰포트 내에 보이는 요소를 추적하고 이를 기반으로 동영상, 이미지, 헤비한 컴포넌트의 다이나믹 임포팅을 통해 페이지 로딩시간 최적화, 빌드 파일 사이즈 축소 등 다양하게 성능을 향상 시킬 수 있다. Intersection을 이용한 이미지 레이지로더 커스텀 훅 예시 (이를 제공하는 외부 라이브러리가 있지만 직접 만들어서 사용해보는 것을 추천) ❗️Error : `Can't find variable: Intersect
React Module Federation를 이용한 Lazy Loading 예제 (TypeScript)
예제 React Module Federation을 이용한 Lazy Loading 예제를 통해 이를 더욱 자세히 알아보겠습니다. Host 애플리케이션 Host 애플리케이션에서는 다음과 같이 webpack.config.js 파일을 설정합니다. 위의 설정에서 name은 현재 애플리케이션의 이름을, remotes는 현재 애플리케이션이 사용할 원격 애플리케이션의 정보를, shared는 원격 애플리케이션과 공유할 모듈을 설정합니다. Remote 애플리케이션 Remote 애플리케이션에서는 다음과 같이 webpack.config.js 파일을 설정합니다. 위의 설정에서 name은 현재 애플리케이션의 이름을, filename은 현재 애플리케이션이 생성할 파일 이름을, exposes는 현재 애플리케이션이 제공하는 모듈을 설정합니다. Host 애플리케이션에서 Remote 애플리케이션의 모듈 사용하기 Host 애플리케이션에서는 다음과 같이 Lazy Loa
React Module Federation를 이용한 Lazy Loading
이 문서에서는 React Module Federation이 무엇인지와 함께, 이를 이용한 Lazy Loading 예제를 설명합니다. React Module Federation이란? React Module Federation은 웹에서 다양한 JavaScript 모듈들을 독립적으로 개발하고, 이를 하나의 애플리케이션으로 통합하는 기술입니다. 이를 통해 각 모듈은 독립적으로 개발될 수 있고, 이를 하나의 애플리케이션으로 통합할 때 불필요한 중복 코드를 제거하고, 서로 다른 모듈들 간의 통신을 통해 더욱 효율적인 개발이 가능해집니다. Lazy Loading Lazy Loading은 필요한 자원이 필요한 시점에 로드되는 기술입니다. 이를 통해 초기 로딩 시간을 줄이고, 필요한 자원만을 로드하여 네트워크 속도를 향상시킬 수 있습니다. 예제 React Module Federation을 이용한 Lazy Loading 예제를 통해 이를 더욱 자세히 알아보겠습니다.
QueryDsl Transform & JPA @OnetoOne Lazy Loading 적용 불가 문제
현재 DND 8기에서 진행하고 있는 프로젝트 하루 블럭의 문제 해결기이다. 문제의 발단은 통계(Report API)를 만들면서였다. 통계로써 월간 리포트를 만드는 일이 주어졌고, 여기서 정말 다양한 문제가 발생했다. 일단 월간 리포트의 다양한 기능을 위해서 제일 처음 해야했던 일은 해당 사용자의 월간 블록과 연관된 Task를 전부 가져오는 일이었다. 이를 위해 MonthlyBlockGetDao를 추가하였다. 일단 제일 초기의 MonthlyBlockGetDao이다. 1. N+1 문제 조회 상에서 N+1이 발생했다. 일단 다음과 같이 테스트 이전에 8개의 블록과 각각의 블록에 3개씩 태스크를 추가해두었는데, 블록의 개수가 24개로 나오게 되었다. 이는 oneToMany를 l
장바구니 탐색 API 리팩토링 (N+1 문제 해결)
관련 ERD 구조와 기능 설명장바구니 조회 관련 ERD 장바구니 탐색 API는 고객에게 상품 정보와 이미지까지 보여줄 필요가 있기 때문에 현재 로그인한 유저의 Profileid를 이용해 Cart, Product, ProductImage 정보를 가져와야한다. 이때 Category Detail과 Category는 장바구니를 보여줄 때 필요한 정보가 아니니 제외되어야한다. 이전코드 이전 코드는 Spring Data JPA에서 제공해주는 QueryMethod를 활용해 Profile_Id를 가지고 있는 모든 Cart에 대한 정보만 뽑아냈다. 하지만 이런 코드는 위에 설명한 기능을 구현하기에는 굉장히 큰 문제가 있다. 왜? 내가 이 코드를 리팩토링 하는 이유
[Spring Data JPA] fetch join에서 Lazy Loading이 작동하지 않는 문제
Spring Data JPA를 사용하다 보면 fetch = FetchType.LAZY을 설정했음에도 불구하고 Lazy Loading이 적용되지 않는 상황이 발생 할 수 있다. 이 포스팅에서는 해당 문제가 발생하는 경우 2가지를 적어놔 이 글을 본 다른이가 나처럼 개고생하는 일이 없었으면 좋겠다... 우선 해당 포스팅에서는 다음과 같은 @ManyToOne, @OneToOne의 기본값이 Eager Loading이니까 fetch = FetchType.LAZY을 작성해 주고 fetch join을 하라든가 Lazy Loading된 값을 접근해서 추가적인 Query를 발생시켜서 그렇다는 얘기는 제외하고 하겠다. Lazy Loading이 동작하지 않는 2가지 경우 @OneToOne 양방향 연관관계에서 주인이 아닌 쪽 entity를 조회할 때 참고 링크 @ManyToOne 연관
React Suspense와 lazy Loading
컴포넌트 또는 비동기상태의 로딩상태를 선언적으로 처리 할 Suspense와 Suspense와 함께 컴포넌트를 동적으로 import하는 방식으로 번들링 사이즈를 줄여 초기 페이지 로드 감소시킨 lazy loading을 프로젝트에 적용한 부분을 작성하려고 한다. Suspense란? Suspense는 아직 렌더링이 준비되지 않은 컴포넌트가 있을때 로딩 화면을 보여주고 로딩이 완료되면 해당 컴포넌트를 보여주는 React에 내장되어 있는 기능이다. Suspense를 사용하는 이유는 다음과 같다. 먼저 code spliting을 통해 필요할때 동적으로 컴포넌트를 import하는 lazy loading 방식을 Suspense와 함께 구현 할 수 있다. 또한 Suspense를 통해 컴포넌트나 비동기 관련 로직상태를 명령형 방식이 아닌 선언적인 방식으로 처리 할 수 있다. Suspense의 동작원리? 비동기 관련 로딩상태를 처리할때,
스트림이 게으르기 때문에 얻을 수 있는 장점!!
모던 자바 인 액션 5장을 읽으면서 filter는 쇼트셔킷을 지원하지 않는다는 것에 놀라웠다. 나는 기본적으로 모든 스트림이 쇼트셔킷을 지원하는 걸로 알고 있었기 때문이다. 그래서 내가 쇼트셔킷으로 잘못 알고 있던 루프퓨전과 쇼트셔킷에 대해 알아보기로 했다. 스트림 파이프라인을 실행하기 전 어떤 작업을 수행하는가? 스트림 파이프라인을 실행하게 되면, JVM은 스트림 연산을 바로 실행시키지 않고 필수적인 연산만을 하고자 준비작업을 수행한다. 여기서, 준비작업이란 스트림 파이프라인이 어떠한 중간연산과 최종연산으로 구성되어있는지에 대한 검사를 하고 이를 바탕으로 JVM은 어떠한 방식으로 최적화를 진행할지 계획하고, 그 계획에 따라 스트림 개별 요소에 대한 스트림 연산을 수행한다. 스트림에서
React의 선언형 에러처리(Error Boundary)
프로젝트에서 Suspense와 Error Boundary를 이용한 선언적 Error, Loading을 처리한 부분과 React.lazy를 사용해 초기 페이지 로드시간을 감소시킨 글을 작성하려고 한다. 이번글에서는 Errorboundary에 대해 중점적으로 다루고자 한다. React의 선언형 프로그래밍 선언형 프로그래밍이란, 프로그램이 어떤 방법으로 해야 하는지를 나타내기보다 무엇과 같은지를 설명하는 경우에 맞춰 코드를 작성하는 방법이다. (위키백과 출처) React는 기본적으로 선언형 프로그래밍 방식을 사용한다. 즉 컴포넌트별 코드의 재사용, UI를 화면에 그리는(render)로직을 분리함으로써, 코드가 간결해지고 한눈에 컴포넌트 구성을 알아볼 수 있다. 명령형 프로그래밍 방식 에러처리와 로딩처리 Suspense와 Error Boundary를 적용하기 전에는 명령형 프로그래밍 방식으로 loading 상태와 error 상
[Frontend] Lazy Loading, Suspense 그리고 SSR
Lazy Loading 🛏️ 탄생 배경 > 웹 프로젝트의 규모가 커지면서 모듈화된 여러 javascript 파일을 로드하는데 시간이 오래걸린다는 이유에서 번들링이 등장하게 됐습니다. 번들링을 통해 개발 단계에서는 모듈 단위로 개발하는 편의를 즐김과 동시에, 베포단계에서는 하나의 javascript 파일을 로딩하여 성능면에서 이점을 누릴 수 있게 됐습니다. 문제는 번들링 결과로 나온 하나의 javascript 파일의 크기가 너무 크다면, 파일을 로드하는데에 너무 많은 시간이 걸려버리는 상황이 발생하게 됩니다. 이런 상황에서 등장한 것이 바로 Lazy Loading이죠. 저희가 제공하는 웹 사이트에는 바로 로드됐으면 하는 컴포넌트와 그렇지 않은 컴포넌트가 있습니다. 가령 서버에서 데이터를 불러오는 일부 컴포넌트, 혹은 상대적으로 용량이 큰 이미지를 로드하느라 전반적인 UI를 불러오지 못한다면 좋지 않은 사용자 경험을 제공하게 됩니다. 작동 방식 React에서는 Re
웹 앱의 번들 크기 줄이기
1. 웹 번들러는 번들을 어떻게 최적화할까요? 웹 번들러의 번들 분할: 코드와 코드에서 사용하는 다양한 종속성을 단일 파일로 번들하고 가능한 가장 적합하게 분할하려고 시도하는 프로세스 트리 쉐이킹: 프로그램에서 사용하지 않는 모듈, 코드 등을 제거 사이드 이펙트: 파일을 가져오기만 하고 함수를 호출하지 않아도 실행되는 동작들. 트리 쉐이킹을 진행할 때, 사이드 이펙트가 발생하지 않는지 확인 필요. 번들러에서 사이드 이펙트를 감지하여 import하는 코드를 무시해도 안전한지 판단. 2. 번들 크기 측정 지표 번들 크기 번들에 포함된 내용 번들의 진입점: 구조에 따라 index
[번역] HTML에서 이미지 최적화하기
Optimal Images in HTML를 번역한 글입니다. 피드백은 댓글로 부탁드립니다. 자 여러분은 멋진 페이지를 만들었고, 이제 배경 이미지를 넣으려 하는데... 잠깐! 이러면 여러가지 이유로 성능 최적화가 안된다는 걸 아셨나요? CSS에서 (보통) background-image를 피해야하는 이유 최적의 이미지 크기 정하기 SVG를 사용하는 경우를 제외하고, 요즘 기기들의 다양한 화면 크기와 해상도를 생각해 보면, 사이트의 방문자 모두가 동일한 이미지 파일을 받아야 하는 경우는 사실상 없습니다. 여러분 사이트는 스마트 워치에서도 작동하죠? (농담입니다… 제 생각에는요) 여러분은 "