웹 개발을 하면서 중요하다고 생각하는 것은 UI/UX인 것 같다.

그렇다면 프론트엔드에서 성능을 최적화할 수 있는 방법은 뭐가 있을까? 🤔


이미지 최적화

     문제: 큰 이미지 파일은 페이지 로딩을 느리게 만듦.

     

     [해결방법]

  • 이미지 압축: TinyPNG 같은 도구로 용량 줄이기
  • WebP 포맷 사용: JPEG/PNG보다 훨씬 가볍고 품질 좋음
  • 필요한 크기만 로딩: 너무 큰 이미지 불러오지 말고, 사용 위치에 맞는 크기로 리사이즈
<!-- 나쁜 예 -->
<img src="/images/hero-original.png" width="300" height="200">

<!-- 좋은 예 -->
<img src="/images/hero-optimized.webp" width="300" height="200" loading="lazy">

지연 로딩 (Lazy Loading)

     문제: 사용자가 안 보는 부분의 리소스를 처음부터 다 불러오면 느림.

     

     [해결방법]

  • 이미지나 컴포넌트는 필요할 때만 로딩
<!-- 이미지 지연 로딩 -->
<img src="product.jpg" loading="lazy">

<!-- React에서 컴포넌트 lazy load -->
const ProductPage = React.lazy(() => import('./ProductPage'));

DOM 조작 최소화

     문제: DOM을 자주 건드리면 렌더링 성능이 떨어짐.

 

     [해결방법]

  • 변경 사항 한 번에 적용 (ex: documentFragment)
  • React/Vue 같은 프레임워크 사용 시, state 변경 최소화
// 나쁜 예
list.forEach(item => {
  const el = document.createElement('li');
  el.textContent = item;
  document.body.appendChild(el); // 매번 DOM 수정
});

// 좋은 예
const fragment = document.createDocumentFragment();
list.forEach(item => {
  const el = document.createElement('li');
  el.textContent = item;
  fragment.appendChild(el);
});
document.body.appendChild(fragment); // 한 번만 DOM 수정

비동기 처리 활용

     문제: 모든 스크립트를 동기로 실행하면 로딩 막힘.

 

     [해결방법]

  • <script async> 또는 <script defer> 사용
  • API 요청은 fetch나 axios로 비동기 처리
<!-- 좋은 예: HTML 렌더링 끝나고 스크립트 실행 -->
<script src="main.js" defer></script>

[script 실행 순서에 관한 내용은 아래 글의 '자바스크립트 코드는 언제 실행될까?' 부분 참고!] ⤵️

https://y-flm.tistory.com/79

 

[CS] 브라우저의 렌더링 과정

브라우저의 렌더링 과정은 웹 개발자라면 필수적으로 알아야 할 지식 중 하나이다!간단히 말하자면, 우리가 작성한 HTML / CSS / JS를 브라우저가 화면에 그리는 과정을 말한다. 쉽게 이해해보기 위

y-flm.tistory.com


이 외에도 불필요 라이브러리 제거, CSS Animation 활용 등이 있고, LightHouse를 이용해서 성능을 측정할 수도 있다!


[최종 요약]

방법 효과
이미지 최적화 로딩 속도 개선
코드 최소화/압축 파일 사이즈 ↓
지연 로딩 처음 로딩 빠르게
캐싱 재방문 시 빠르게
라이브러리 정리 불필요한 용량 ↓
DOM 조작 최소화 렌더링 부드럽게
비동기 처리 브라우저 멈춤 방지
Core Web Vitals 최적화 SEO와 UX 개선

 

REST API란?

    자원(Resource)을 정의하고, 그 자원을 처리하는 방식(HTTP Method)을 명확히 구분하여 클라이언트와 서버가

     일관된 규칙으로 소통할 수 있도록 만든 아키텍처 스타일이다.

     * REST = REpresentational State Transfer

     * API = Application Programming Interface

    REST API는 보통 HTTP 프로토콜을 기반으로 만들어지며, 브라우저, 앱, 프론트엔드와 백엔드 간의 데이터 교환에 널리 사용된다.


REST API의 특징
특징 설명
무상태성(Stateless) 요청마다 상태를 유지하지 않음 (쿠키, 세션 X)
자원 중심 URL로 자원을 명확히 표현
일관된 규칙 HTTP 메서드를 의미에 맞게 사용
클라이언트-서버 분리 프론트와 백엔드가 독립적으로 개발 가능

REST API 구성 요소
구성 요소 설명
자원 (Resource) 정보를 표현하는 대상으로, URI를 통해 식별됨. (예: /users, /products)
메서드 (Method) 자원에 대한 동작을 정의 (예: GET, POST, PUT, DELETE)
표현 (Representation) 자원의 상태를 전달하는 형식, 대부분 JSON이나 XML로 표현됨
URI (Uniform Resource Identifier) 자원을 식별하는 경로 (예: /users/1는 ID가 1인 유저를 의미)
상태 코드 (HTTP Status Code) 요청 처리 결과를 알려줌. (예: 200(성공), 404(없음), 500(서버오류) 등)

REST API 설계 시 주의할 점 ⚠️

 

1. 자원 중심 URI 설계

  • URI는 명사로 구성
  • ❌  /getUserInfo, /deleteProduct
  • ⭕️  /users, /products

 

2. HTTP 메서드를 의미에 맞게 사용

동작 메서드 설명
조회 GET 자원 가져오기
생성 POST 새 자원 추가
수정 PUT 자원 전체 수정
부분 수정 PATCH 자원 일부 수정
삭제 DELETE 자원 삭제

 

3. 일관된 응답 포맷 사용

{
  "success": true,
  "data": { ... },
  "message": "요청에 성공했습니다"
}

 

4. 상태 코드 제대로 쓰기

코드 의미 비고
200 OK 요청 성공
201 Created 자원 생성됨
400 Bad Request 잘못된 요청
401 Unauthorized 인증 실패
404 Not Found 자원 없음
500 Internal Server Error 서버 오류

REST API에 대해 정리하다보니 문득 HTTP를 정리했을 때와 비슷한 느낌을 받았다.

그렇다면 REST API와 HTTP의 차이점은 뭘까?


HTTP와 REST API의 차이 요약

 

  • HTTP = 통신 방법 자체 (전화기)
  • REST API = HTTP를 "어떻게" 쓸지에 대한 규칙 (전화 예절)

 


HTTP와 REST API 비교
구분 HTTP REST API
역할 웹에서 요청/응답을 주고받는 통신 규약 HTTP를 기반으로 자원 중심의 API를 설계하는 방식
범위 더 넓음 (REST 말고도 SOAP, GraphQL 등 사용 가능) 더 좁음 (HTTP 위에서 동작하는 방식 중 하나)
개념 프로토콜 (어떻게 말할지의 기본 약속) 아키텍처 스타일 (말할 때 어떤 형식으로 할지의 규칙)
메서드 사용 GET, POST, PUT, DELETE 등 제공만 함 이 메서드들을 "자원 중심"으로 알맞게 활용하도록 정의

[HTTP에 대해서 자세히 알고 싶다면 아래 글 참고!] ⤵️

https://y-flm.tistory.com/81

 

[CS] HTTP(Hyper Text Transfer Protocol)란?

HTTP(Hyper Text Transfer Protocol)란?    웹에서 정보를 주고 받기 위한 프로토콜을 말하는데, 한마디로 웹 브라우저(클라이언트)와 서버가 데이터를 주고 받는 통신 방법이다.⚠️ 여기서 잠깐, 프로토

y-flm.tistory.com

 

 

MPA(Multi-Page Application)란?

     페이지가 여러 개로 구성되어 있고, 사용자가 어떤 링크를 클릭하면 브라우저가 서버에 새 HTML 페이지를 요청하고,

     전체 페이지를 새로 로드한다. (각 페이지마다 별도의 HTML, CSS, JS 파일이 있음)

 

[작동 방식 ⚙️]
1) 사용자가 만약 /about을 클릭하면,
2) 브라우저는 서버에 /about 요청을 보내고,
3) 서버는 완전히 새로운 HTML 페이지를 다시 보냄.
4) 기존 페이지는 새로고침되고, 새로운 페이지가 열림.

MPA의 장단점은 뭘까?

 

장점 단점
- SEO에 유리 (서버가 완성된 HTML을 보내주기 때문에 크롤링 쉬움)  - 페이지 이동 시 전체 새로고침 => UX 저하
- 간단한 구조 (전통 방식이라 이해하기 쉬움) - 개발 시 중복 코드가 많아질 수 있음
-페이지가 완전히 분리되어 있으므로 보안상 이점이 있음 - 클라이언트 측 동적 인터랙션 구현이 복잡

SPA(Single Page Application)란?

     하나의 HTML 파일로 구성되어 있고, 최초 로딩 시 모든 JS, CSS, HTML을 로드한다.

     사용자가 이동하는 페이지는 사실 컴포넌트 단위의 동적 화면 전환으로, 페이지 전환처럼 보이지만 실제로는 전체 페이지 리로드가 없다.

 

[작동 방식 ⚙️]
1) /about을 클릭하면,
2) 브라우저는 서버에 HTML을 요청하지 않음.
3) 자바스크립트가 내부적으로 URL을 변경하고, 필요한 데이터만 비동기로 불러와서 화면을 동적으로 렌더링

SPA의 장단점은 뭘까?

장점 단점
- 빠른 사용자 경험 (페이지 전환 시 부드럽고 빠름) - 초기 로딩 속도가 느릴 수 있음 (전체 JS 파일을 다 받아오기 때문)
- 클라이언트에서 다양한 동작을 할 수 있어 앱처럼 사용 가능 - SEO 불리
   (크롤러가 자바스크립트를 제대로 실행하지 못하는 경우가 있음)
     → SSR or SSG로 해결
- 컴포넌트 재사용성 ↑ → 유지보수 효율 ↑ - 복잡한 상태 관리 필요
   (라우팅, 인증 등 모두 클라이언트 측에서 처리)

MPA와 SPA 요약 비교 🔍
항목 MPA SPA
페이지 수 여러 개 한 개
새로고침 매번 새로고침 없음 (동적 렌더링)
SEO 좋음 나쁨 (대체 기술 필요)
속도 느릴 수 있음 (전환 시) 빠름 (전환 부드러움)
구현 복잡도 낮음 상대적으로 높음
사용 기술 전통적인 서버 렌더링 프론트엔드 프레임워크 중심 (React 등)

 

 

렌더링이란, 웹 페이지의 내용을 눈에 보이게 만들어주는 과정을 말한다.

렌더링 방식화면을 만들기 위한 데이터와 구조(HTML)을 누가 언제 준비하냐에 따라 다르다.

각 렌더링 방식에 대한 느낌을 정리해보자면 다음과 같다.

 

  • CSR은 "브라우저야, 이 JS로 페이지를 직접 만들어!"
  • SSR은 "서버가 만들어줄게. 브라우저는 그냥 보여줘!"
  • SSG는 "미리 만들어둘게. 나중에 그냥 보여줘!"

그렇다면 각 렌더링 방식에 대해 자세히 알아보자!

 


CSR(Client Side Rendering)이란?

    클라이언트에서 페이지 내용을 만드는 방식으로, 사용자의 브라우저가 서버로부터 데이터를 받아와서 웹 페이지를 직접 생성한다.

[CSR의 동작 과정]
1) 사용자가 웹 사이트에 접속하면 서버는 빈 HTML과 JavaScript 파일을 보냄.
2) 브라우저가 JavaScript를 로드하고 실행
3) JavaScript가 동적으로 HTML을 생성하고, 이를 브라우저에 표시
4) 추가 페이지 요청 시, 전체 페이지를 다시 로드하는 대신에 필요한 데이터만 서버에서 받아와 해당 부분만 업데이트
   → 즉, CSR은 서버로부터 빈 접시(빈 HTML)와 요리 재료(JavaScript)를 받고 요리(렌더링)를 직접 하는 방식

그럼 CSR을 사용했을 때의 장점과 단점은 뭘까?

 


SSR(Server Side Rendering)이란?

    서버에서 HTML을 완성시킨 후 브라우저로 보내는 방식이다.

[SSR의 동작 과정]
1) 사용자가 웹 사이트에 접속하면 서버에서 해당 페이지에 필요한 HTML 생성
2) 서버는 생성된 HTML을 브라우저로 보낸다.
3) 브라우저는 받은 HTML을 표시
4) 추가 페이지 요청 시, 해당 페이지에 대한 HTML을 다시 서버에서 생성하여 보낸다.
   → 즉, SSR은 서버에서 요리(웹 페이지 렌더링)를 완성시킨 후 접시에 담아서(완성된 HTML) 손님(사용자)에게 제공하는 방식

그럼 SSR을 사용했을 때의 장점과 단점은 뭘까?


SSG(Static Site Generation)란?

    미리 HTML을 만들어두고 요청이 오면 바로 보여주는 방식이다.

[SSG의 동작 과정]
1) 빌드 시 프레임워크는 모든 경로에 대한 HTML 파일을 미리 생성한다.
2) 사용자가 웹 사이트에 접속하면, 서버는 미리 생성해둔 HTML을 보낸다.
3) 브라우저는 받은 HTML을 표시
4) 추가 페이지 요청 시, 미리 생성해둔 해당 페이지의 HTML을 보낸다.
   → 즉, SSG는 미리 요리(웹 페이지 렌더링)를 완성시켜놓고, 동일한 요리를 계속 제공하는 방식

그럼 SSG를 사용했을 때의 장점과 단점은 뭘까?


그렇다면 언제 어떤 방식을 쓰는게 좋을까?
상황 추천 방식
자주 바뀌는 데이터 / 웹앱 CSR
뉴스/커머스 등 SEO가 중요한 동적 사이트 SSR
블로그, 문서, 마케팅 페이지 SSG

 


렌더링 방식 비교 요약
항목 CSR SSR SSG
렌더링 위치 클라이언트(브라우저) 서버 빌드 시 (정적 파일 생성)
속도 느린 초기 로딩, 이후 빠름 초기 빠름, 페이지 이동 느림 매우 빠름
SEO 불리 유리 매우 유리
유동 데이터 잘 맞음 적당함 안 맞음

[추가적으로 브라우저의 렌더링 과정을 자세히 알고 싶다면 아래 글 참고 !] ⤵️

https://y-flm.tistory.com/79

 

[CS] 브라우저의 렌더링 과정

브라우저의 렌더링 과정은 웹 개발자라면 필수적으로 알아야 할 지식 중 하나이다!간단히 말하자면, 우리가 작성한 HTML / CSS / JS를 브라우저가 화면에 그리는 과정을 말한다. 쉽게 이해해보기 위

y-flm.tistory.com

 

 

먼저 쿠키 / 세션 / 로컬 스토리지왜 쓰는 걸까?

간단히 말하자면 웹 브라우저(클라이언트)와 서버가 데이터를 주고 받기 위해서는 HTTP 프로토콜을 사용한다. 

HTTP는 무상태성의 특징을 갖는데, 이는 서버가 클라이언트의 이전 요청을 기억하지 않는다는 특징이다.

 

예를 들어 로그인 정보같은 것을 기억하지 못하기 때문에 페이지 이동 시에도 매번 로그인을 해야한다.

이러한 문제를 해결하기 위해 쿠키 / 세션 / 로컬 스토리지를 사용한다.

 

[HTTP에 대해 더 알고 싶다면 아래 글을 참고!]⤵️

https://y-flm.tistory.com/81

 

[CS] HTTP(Hyper Text Transfer Protocol)란?

HTTP(Hyper Text Transfer Protocol)란?    웹에서 정보를 주고 받기 위한 프로토콜을 말하는데, 한마디로 웹 브라우저(클라이언트)와 서버가 데이터를 주고 받는 통신 방법이다.⚠️ 여기서 잠깐, 프로토

y-flm.tistory.com


쿠키(Cookie)란?

    작은 데이터 조각브라우저에 저장하는 방식으로, 클라이언트에 저장되지만 매 요청마다 서버로 자동 전송된다.

 

[쿠키의 특징]

항목 설명
저장 위치 브라우저 (텍스트 형태)
서버 전송 여부 항상 자동 전송됨 (요청 헤더에 포함)
만료 기간 직접 설정 가능 (expires, max-age)
크기 제한 약 4KB 이하
보안 HttpOnly, Secure, SamSite 옵션으로 보안 강화 가능
사용 예시 로그인 유지, 장바구니, 사용자 식별용 토큰 등

 

* JS에서 쿠키를 확인하려면 document.cookie를 이용해 확인할 수 있다.


세션(Session)이란?

   서버에 저장되는 유저 상태 정보로, 브라우저에는 세션 ID만 저장되며 실제 데이터는 서버 메모리나 DB에 저장된다.

 

 

[세션의 특징]

항목 설명
저장 위치 서버 측 저장
클라이언트 역할 세션 ID만 저장
서버 전송 여부 요청 시 쿠키에 담긴 세션 ID가 전송됨
만료 기간 브라우저 종료 시 or 서버 설정에 따라 자동 만료
보안 서버 관리 가능 -> 상대적으로 보안성 높음
사용 예시 로그인 상태 유지, 장바구니 정보, 사용자 인증 등

 

* JS에서 세션을 확인하려면 window.sessionStorage를 이용해 확인할 수 있다.


로컬 스토리지(Local Storage)란?

   브라우저에 key-value 형태로 데이터 저장하는 HTML5 기술로, 서버로 자동 전송되지 않는다.

 

 

[로컬스토리지 특징]

항목 설명
저장 위치 브라우저 (영구 저장)
서버 전송 여부 자동 전송되지 않음
만료 시점 지우기 전까지 영구 저장
크기 제한 약 5~10MB
보안 JS에서 접근 가능 (XSS 취약)
사용 예시 테마 설정, 임시 저장, 사용자 설정 등

 

* JS에서 로컬 스토리지를 확인하려면 window.localStorage를 이용해 확인할 수 있다.

* 로컬 스토리지에 값을 설정하거나 값을 가져오려면 아래와 같은 코드로 수행할 수 있다.

// 'theme'이라는 key에 'dark'라는 value를 저장
localStorage.setItem('theme', 'dark');

// 'theme'이라는 키에 저장된 값을 theme 변수에 저장
const theme = localStorage.getItem('theme');  // 'dark'

차이점 요약 🔍
구분 쿠키(Cookie) 세션(Session) 로컬 스토리지(Local Storage)
저장 위치 브라우저 서버 브라우저
자동 서버 전송 ⭕️ (요청마다) ⭕️ (세션ID가 쿠키로 전송) ❌ 전송되지 않음
용량 제한 약 4KB 서버가 관리 5~10MB 정도
만료 시점 직접 설정 브라우저 종료 or 설정 직접 지우기 전까지
보안 중간 (옵션으로 보완 가능) 높음 (서버 관리) 낮음 (XSS에 노출 가능)
사용 목적 인증, 추적, 상태 유지 로그인, 사용자 상태 관리 캐시, 개인 설정 등 클라이언트 전용

 

차이점을 보고 대략적으로 언제 사용하면 좋을지 아래와 같이 정리해보았다.

목적 추천 방식 이유
로그인 유지 세션 or 쿠키 세션은 서버에서 관리 → 보안에 좋음
쿠키는 토큰 기반 로그인에 사용됨 (JWT 등)
사용자 설정 저장 (다크모드 등) 로컬스토리지 서버에 전송할 필요 없음
인증 토큰 저장 쿠키 or 로컬스토리지 쿠키는 자동 전송, 로컬스토리지는 수동 전송
민감 정보 저장 저장 X 보안상 브라우저 저장소는 피해야 함

 

HTTP(Hyper Text Transfer Protocol)란?

    웹에서 정보를 주고 받기 위한 프로토콜을 말하는데, 한마디로 웹 브라우저(클라이언트)와 서버가 데이터를 주고 받는 통신 방법이다.


⚠️ 여기서 잠깐, 프로토콜에 대해 알고 싶다면?

https://y-flm.tistory.com/80

 

[CS] 프로토콜(Protocol)이란? (Feat. OSI 7계층)

프로토콜(Protocol)이란?      기계(컴퓨터)끼리 데이터를 주고 받기 위한 규칙 / 약속 / 표준을 말한다.프로토콜은 어디에 쓰일까?분야예시 프로토콜설명웹HTTP, HTTPS브라우저 - 서버 통신파일 전

y-flm.tistory.com


HTTP의 특징 4가지
  • 특징 ①: 클라이언트 - 서버 구조
    클라이언트(브라우저)요청하는 쪽이고, 서버요청을 받아 응답하는 쪽이다.
    HTTP는 이러한 클라이언트-서버 구조를 가지고 있다.
  • 특징 ②: 무상태(Stateless)
    HTTP에서 서버는 클라이언트의 이전 요청 상태를 기억하지 않는다는 무상태의 특징을 가지고 있다.
    그렇기 때문에 매번 요청할 때 마다 서버는 새로운 사람처럼 대응하고,
    로그인 정보 같은 것을 유지하려면 Cookie, Session, Token 같은 걸 따로 사용해야한다.
  • 특징 ③: 텍스트 기반 프로토콜
    사람이 읽을 수 있는 텍스트 형태로 구성되어 있으며, 개발자 도구 → 네트워크 탭에서 실제 요청/응답 내용을 확인할 수 있다.
  • 특징 ④: URL + Method 조합으로 동작
    GET /users HTTP/1.1 와 같은 HTTP 요청 예시가 있다면,
    여기서 GET무슨 동작을 할지 결정하는 메서드이고,
    /users어떤 데이터를 요청할지에 대한 리소스 경로를 말하고 HTTP/1.1HTTP 버전을 말한다.

그럼 실제 HTTP의 요청/응답 구조는 어떻게 될까?

[HTTP 요청]

GET /products/123 HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html

 

  • 무슨 동작인지 (GET)
  • 요청할 리소스 경로 (/products/123)
  • 요청자 정보 (User-Agent)
  • 어떤 형식의 응답을 원하는지 (Accept)

[Method 종류]


* PUT과 PATCH의 차이점

구분 PUT PATCH
의미 전체 자원 교체 일부 자원 수정
데이터 전체 데이터 필요 수정할 필드만 전달
동작 방식 기존 자원을 덮어씀 기존 자원을 부분 업데이트
멱등성 있음 있음 (대부분의 경우)
사용 예시 유저 정보 전체 수정 유저 이메일만 수정

예시로는 아래와 같은 형식의 서버 데이터가 있다고 가정해보자.

{
  "id": 1,
  "name": "Alice",
  "email": "alice@email.com",
  "age": 25
}

PUT을 이용하여 요청을 보내면 아래와 같다.

PUT /users/1
Content-Type: application/json

{   
     "id": 1,
     "name": "Alice B",
     "email": "alice.b@email.com",
     "age": 26
}

기존 데이터를 덮어씌우며, 만약 전달하지 않은 필드가 있다면 사라질 수 있다.


PATCH를 이용하여 요청을 보내면 아래와 같다.

PATCH /users/1
Content-Type: application/json

{
     "age": 26
}

기존 데이터를 유지하면서 일부만 수정하고, 전달하지 않은 필드는 그대로 유지된다.


[HTTP 응답]

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 2730

<html>
  <body>...</body>
</html>

 

  • 200 OK: 성공했단 뜻 (응답 코드)
  • Content-Type: 보내는 데이터의 타입
  • 서버는 요청을 처리한 뒤 상태 코드와 함께 응답을 보내고, 본문(body)에 HTML, JSON, 이미지 등이 들어간다.

 

 

 

응답 코드가 뭘까?

 

응답 코드는 말 그대로 HTTP로 요청을 하고 응답을 받을 때 나타나는 코드이다.

서버가 클라이언트에게 요청을 받으면 응답상태에 따라서 다른 상태코드를 클라이언트에게 돌려준다.

응답 코드는 100 ~ 599까지 숫자로 나뉘고, 앞자리로 의미를 구분한다.

코드 범위 의미 예시 코드 설명
1xx 처리 중 100 임시 응답
2xx 성공 200 OK, 201 Created 요청이 잘 처리됨
3xx 리다이렉션 301, 302 다른 위치로 이동함
4xx 클라이언트 오류 404 Not Found 요청 자체가 틀림
5xx 서버 오류 500 Internal Server Error 서버 문제로 실패

이 중에서 자주 보이는 상태 코드들이 있다.

 

  • 200 OK: 정상 처리
  • 201 Created: POST로 리소스 생성 성공
  • 301 Moved Permanently: 페이지 영구 이동
  • 302 Found: 임시 이동 (리디렉션)
  • 400 Bad Request: 요청 자체가 잘못됨
  • 401 Unauthorized: 로그인 필요함
  • 403 Forbidden: 권한 없음
  • 404 Not Found: 페이지 없음
  • 500 Internal Server Error: 서버 터짐
  • 503 Service Unavailable: 서버 과부하 or 점검 중

 

HTTP도 많이 들어봤을테지만 동시에 HTTPS도 많이 들어봤을 것이다.

그렇다면 둘의 차이는 뭘까?

 

HTTP와 HTTPS

    HTTP는 모든 데이터가 평문으로 전송되기 때문에 보안이 없는데, 그래서 등장한 것이 HTTPS이다.
    HTTPS는 HTTP에 SSL/TLS를 추가한 것이고, 이를 통해 암호화를 할 수 있다.

항목 HTTP HTTPS
보안 암호화 안됨 암호화 됨 (SSL/TLS 사용)
주소 http:// https://
데이터 노출 평문 전송 암호화 전송
브라우저 표시 "주의 요함" 표시 가능 자물쇠 아이콘 표시

중요한 차이점은 HTTP누구든 요청/응답을 볼 수 있고, HTTPSSSL/TLS를 통해 암호화되서 제 3자가 볼 수 없다.

 

 

 

프로토콜(Protocol)이란? 

     기계(컴퓨터)끼리 데이터를 주고 받기 위한 규칙 / 약속 / 표준을 말한다.


프로토콜은 어디에 쓰일까?
분야 예시 프로토콜 설명
HTTP, HTTPS 브라우저 - 서버 통신
파일 전송 FTP, SFTP 파일을 네트워크로 전송
이메일 SMTP, IMAP 이메일 보내고 받는 규칙
로컬 네트워크 TCP/IP 데이터 전송의 기본 규칙
보안 SSL/TLS 암호화와 인증을 담당

 


프로토콜은 어떻게 생겼을까? 🤔

    프로토콜은 "이런 순서로 이런 정보들을 보내고 받아라"와 같은 구체적인 형식과 순서를 정해놓은 문서 혹은 표준이다.

    예시로 HTTP 요청 프로토콜을 보면 아래와 같은 형식을 가지고 있다.

GET /about HTTP/1.1
Host: www.example.com

 

  • 첫 줄은 메서드(GET), 경로(/about), 버전(HTTP/1.1)
  • 두 번째 줄은 헤더 정보
  • 마지막은 본문 (필요 시)

     위와 같은 형식으로 보내지 않으면 서버가 요청을 이해하지 못한다.


 

프로토콜이 중요한 이유 🔍

 

    프로토콜이 중요한 이유는 컴퓨터끼리는 사람처럼 추측이 불가능하기 때문에 조금이라도 틀린 형식이라면 통신이 되지 않는다.

    그래서 모두가 따를 수 있는 공식 규칙이 필요했고 그렇게해서 생긴 것이 프로토콜이다!


 

 

나는 더 나아가서 프로토콜이 네트워크 계층 구조(OSI 7계층) 속에서 어떻게 동작하는지 알아보려고 한다!


네트워크 계층 구조(OSI 7계층)란?

    컴퓨터와 네트워크 장비가 어떻게 데이터를 주고받는지를 7단계 계층으로 나눈 모델이다.

    각 계층은 특정한 역할을 맡아서 서로 계층 간에 작업을 나눠서 협력하는 구조이다.

 

[OSI 7계층 전체 구조]
계층 이름 역할 예시 프로토콜
7 응용 계층 사용자와 가장 가까운 계층, 실제 요청/응답 HTTP, FTP, SMTP
6 표현 계층 데이터 인코딩, 암호화, 압축 JPEG, SSL/TLS, GZIP
5 세션 계층 통신 세션(접속, 유지, 종료) 관리 NetBIOS, RPC
4 전송 계층 데이터의 신뢰성있는 전송 TCP, UDP
3 네트워크 계층 경로 선택, 주소 지정 IP, ICMP
2 데이터 링크 계층 MAC 주소, 프레임 전달 이더넷, 스위치
1 물리 계층 실제 전기 신호, 하드웨어, 케이블 LAN, USB, 전선

 

 

브라우저의 렌더링 과정은 웹 개발자라면 필수적으로 알아야 할 지식 중 하나이다!

간단히 말하자면, 우리가 작성한 HTML / CSS / JS를 브라우저가 화면에 그리는 과정을 말한다.

 

쉽게 이해해보기 위해서 요리하는 과정에 비유하여 설명해보자면 다음과 같다.

📄 HTML: 요리 레시피
🎨 CSS: 플레이팅 / 장식
⚙️ JavaScript: 자동 조리 기계 (동작 / 인터랙션)
🧑🏻‍🍳 브라우저: 요리사 (렌더링 엔진)

 

그럼 이제 단계별로 렌더링 과정을 알아보자!


1단계: HTML 파싱 ➡️ DOM 트리 생성

     먼저 HTML 문서를 파싱하여 태그들을 DOM(Document Object Model) 트리 구조로 변환해준다.

[💡 개념 알고가기 !]
1. 파싱(Parsing)이란? ➡️ "문자 덩어리를 구조로 바꾸는 과정"
   - 브라우저는 처음 HTML 문서를 처음 받으면 그냥 글자들로 보여진다.
      그렇기 때문에 화면에 보여주기 위해서는 구조를 알아야하는데,
      예를 들어 "<h1>은 제목이고, <p>는 단락이구나."와 같이 의미를 해석하는 작업이 필요한데 이를 파싱이라고 한다.

2. DOM(Document Object Model)이란? ➡️ "HTML을 트리 구조로 표현한 것"
   - 만약 HTML 문서에 <h1>안녕하세요</h1>라고 저장되어있다면, 내부적으로는 아래와 같은 구조로 바뀌게 된다.
      Document > h1 > "안녕하세요"
      DOM은 웹 페이지의 뼈대 구조라고도 할 수 있다.

 


[예시]

<body>
  <h1>브라우저의 렌더링 과정</h1>
  <p>HTML 문서 파싱</p>
  <p>DOM 트리 생성</p>
</body>

⬇️


2단계: CSS 파싱 ➡️ CSSOM 트리 생성

     DOM 트리와 마찬가지로 style 태그나 .css 파일을 파싱하여 CSSOM(CSS Object Model) 트리를 구축한다.

[💡 개념 알고가기!]
1. CSSOM(CSS Object Model)이란? ➡️ "CSS를 트리 구조로 정리한 것"
   - CSS도 처음에는 그냥 텍스트이기 때문에 브라우저가 파싱해서 구조화해야하는데, 이를 CSSOM이라고 한다.
      만약 HTML에서 <h1>를 빨간색 폰트로 지정했다면 "h1이라는 요소는 빨간색 글자"라고 저장해놓는 객체 구조이다.  

[예시]

<body style="font-size: 10px;">
  <h1 style="font-size: 20px;">브라우저의 렌더링 과정</h1>
  <p style="color: red;">HTML 문서 파싱</p>
  <p style="display: none;">DOM 트리 생성</p>
</body>

⬇️


3단계: DOM + CSSOM = Render 트리 생성

     DOM 트리와 CSSOM 트리를 결합하여 Render 트리를 구축하는데, Render 트리는 화면에 표시될 요소들만 포함하여 생성한다.


     위에서 보여줬던 예시 DOM 트리와 CSSOM 트리를 결합하여 Render 트리를 생성하게 된다면 아래와 같은 트리가 완성된다.

    * display: none 스타일이 적용되어있는 <p>DOM 트리 구축</p> 부분은 실제 화면에 보여지지 않기 때문에 제외된다.


4단계: Layout (Reflow)

     Layout 단계에서는 각 요소의 위치와 크기를 계산한다.

     예를 들어, "버튼은 화면의 왼쪽 여백이 20px이고, 너비는 100px이다."와 같이 계산하게 된다.


5단계: Painting (Repaint)

     Painting 단계에서는 Layout 단계에서 계산된 요소의 위치와 크기를 픽셀 단위로 화면에 그린다.

 [💡 개념 알고가기 !]
1. Reflow란? ➡️ "요소의 위치나 크기 변경되었을 때 발생"
   예를 들어, 요소의 크기(width, height)나 위치(margin, position, display 등)가 변경되면
   전체 레이아웃을 다시 계산해야하기 때문에 리플로우가 발생한다.

   리플로우는 비용이 큰 작업이며, 발생 시 변경된 요소 뿐만 아닌 연관된 다른 요소도 다시 계산될 수 있다.
   또한, 리플로우가 발생하면 자동적으로 리페인트로 발생하기 때문에 DOM 구조나 스타일을 자주 바꾸는 것
   성능 저하의 원인
이 될 수 있다는 점을 명시해야한다.

2. Repaint란? ➡️ "요소의 시각적인 스타일만 변경되었을 때 발생"
   배경색을 변경한다던지 글자색을 변경하는 등의 시각적인 스타일만 변경될 경우,
   브라우저는 위치나 크기를 다시 계산하지 않고 화면에 그리는 작업만 다시 수행하는데, 이를 리페인트라고 한다.

   리플로우에 비해 상대적으로 가벼운 작업이지만 이 또한 빈번하게 발생하면 성능에 영향을 줄 수 있다.

 

그렇다면 JavaScript 코드는 언제 실행될까? 🤔

 

기본적으로 HTML 파싱 중에 <script>를 만나면 바로 실행된다!

<body>
  <h1>안녕!</h1>
  <script src="main.js"></script>
  <h1>반가워요!</h1>
</body>

하지만 위의 코드에서는 DOM을 다 생성하기 전에 실행되므로 '안녕'이 아닌 null이 출력될 수 있다.

그래서 원하는 타이밍에 맞게 자바스크립트를 실행할 수 있도록 조절해야한다.


1. 기본 <script>  (동기 실행)

     위에서 말했듯이 기본적으로 파싱 중에 <script>를 만나면 파싱이 중단되고 JS가 실행된다.

     한마디로 동기적으로 실행되는 것인데, 그렇기 때문에 <script>의 위치에 따라 실행되는 타이밍이 달라진다.


  • <head>안에 <script> 사용
<head>
  <script src="main.js"></script>
</head>
<body>
  <h1>안녕!</h1>
  <h1>반가워요!</h1>
</body>

이 경우 스크립트 파일을 전부 불러올 때 까지 body 파싱을 멈추기 때문에 브라우저의 초기 렌더링이 느려진다.

그렇게 되면 스크립트 파일에 따라 사용자가 빈 화면을 보고있는 시간이 길어질 수 있기 때문에 좋지않은 방식이다.


  • <body> 중간에 <script> 사용
<body>
  <h1>안녕!</h1>
  <script src="main.js"></script>
  <h1>반가워요!</h1>
</body>

중간에 스크립트를 사용하면 body 파싱 중에 script를 만나기 때문에 그 다음 요소들은 파싱되지 않고,

스크립트 파일이 전부 실행될 때까지 파싱이 멈추게 된다.


  • <body> 끝에 <script> 사용
<body>
  <h1>안녕!</h1>
  <h1>반가워요!</h1>
  <script src="main.js"></script>
</body>

마지막에 스크립트를 사용하게 되면 이미 위에 요소들을 전부 파싱한 후 실행되는 것이므로 DOM을 조작하기에 안정적인 시점이다.


2. defer 사용
<head>
  <script src="main.js" defer></script>
</head>

defer를 사용하면 script 파일은 HTML 파싱이 끝날 때까지 기다렸다가 실행된다.

따라서 DOM이 완성된 후에 실행되고 순서도 보장할 수 있다.

대부분 head안에 <script defer>로 사용한다.


3. async 사용
<head>
  <script src="main.js" async></script>
</head>

많이 보는 async는 비동기적으로 실행된다.

script 파일을 불러오는 동안 HTML을 파싱하고 다 불러와지면 바로 스크립트가 실행된다.

이렇게 비동기적으로 실행되기 때문에 순서를 보장할 수 없다.


[요약]

방식 실행 시점 HTML 파싱 중단 여부 순서 보장
<head>에 <script> 사용 즉시 실행 ⭕️ ⭕️
<body> 중간에 <script> 사용 즉시 실행 ⭕️ ⭕️
<body> 끝에 <script> 사용 즉시 실행 ⭕️
defer 사용 파싱이 완료된 후 실행 ⭕️
async 사용 다운로드 완료 후 즉시 실행 실행 시 중단

[브라우저 렌더링 과정] 최종 요약 ⭐️

+ Recent posts