thumbnail
웹 사이트 성능을 개선하는 기본적인 방법
Frontend
2023.04.04.

썸네일: Unsplash의Paul Hanaoka

출처 : 웹 성능 최적화 기법

웹 성능 최적화 기법(루비페이퍼 사) 도서에 대한 핵심 내용과 지식을 정리한 포스트입니다. 포스트에 올라오는 내용은 도서의 일부이기 때문에 더 자세한 내용이 궁금하신 분들은 출처에서 도서를 구매해 읽어보시는 것을 추천드립니다.

3.1 HTTP 요청 수 줄이기

  • 최근 웹 사이트들은 수많은 이미지와 멀티미디어, 웹 사이트의 독자적 기능 수행을 위한 JavaScript, UI, 폰트, 음원 파일들로 가득하다. 이런 콘텐츠가 많을수록 웹 페이지의 로딩 시간은 길어지기 때문에, 웹 성능을 빠르게 하기 위해선 HTTP의 요청 수를 줄여야 한다.

3.1.1 스크립트 파일 병합

  • 소프트웨어 공학에서는 소프트웨어 개발의 손쉬운 분업화 및 편리한 유지 보수를 위해 최소 기능 단위별로 소프트웨어 모듈을 나누어 개발하는 모듈화(modulation)를 제안한다.
    • 하지만 정복과 분할(divide & conquert) 모듈화는 HTTP 요청 수를 증가시켜 웹 성능에 부정적인 영향을 미친다.
    • 모듈화된 여러 파일들을 하나의 파일로 병합하고 이 하나의 파일을 브라우저가 실행하도록 하여 HTTP 요청 수를 줄일 수 있다.

3.1.2 인라인 이미지

  • HTML의 CSS안에 해시 정보를 통해 웹 페이지 배경 이미지 파일을 삽입할 수 있는데, 이 방식을 사용하면 HTML 파일 크기가 소폭 커지지만, 이미지 파일을 따로 불러 호출하는 방식과 비교하면 전체 로딩 시간을 단축할 수 있다. 이를 **인라인 이미지(inline image)**라고 한다.
  • 인라인 방식은 인터넷이나 브라우저에 캐시할 수가 없어, HTML이 캐시되어야 동시에 캐시할 수 있다는 단점이 있다.

3.1.3 CSS 스프라이트

  • CSS 스프라이트(sprite)는 여러 개의 이미지를 하나의 이미지 파일로 결합해 필요한 이미지가 위치하는 픽셀 좌표 정보를 사용하는 방식이다.
    • 주로 아이콘, 버튼 등 작은 이미지를 사용할 때 유용하며 HTML에 필요한 이미지 영역을 이미지 맵 좌표로 표시한다.

3.2 콘텐츠 파일 크기 줄이기

  • 파일 수를 줄이더라도 파일 자체의 크기가 크다면 웹 성능에 부정적 영향을 준다.(인터넷 전송 기간이 길어진다)
  • 파일 자체의 크기를 줄이되 파일 내용은 변하지 않고 크기를 줄일 수 있는 몇가지 기능들이 있다.

3.2.1 스크립트 파일 압축 전달

  • HTML, JavaScript, CSS, Ajax, JSON 등 모두 스크립트 형태의 텍스트(text) 파일이기 때문에 압축이 가능하다.
  • 웹 서버 역시 각 웹 서버가 지원하는 방식으로 스크립트 형태 콘텐츠를 압축해 클라이언트에게 더 작은 크기로 내려주고, 이를 다운로드한 클라이언트가 압축을 해제하여 사용하면 인터넷 다운로드 속도가 좀 더 빨라질 수 있다.
    • 압축하여 내려주기 전에 웹 서버, 클라이언트는 서로 지원하는 다양한 압축 방식 중 어떤 것을 사용할지 골라 정해야 한다.
  • HTTP 프로토콜은 Accept-Encoding, Content-Encoding 헤더를 사용해 이러한 압축 방식 정보 교환을 지원한다.
  • 클라이언트는 웹 서버에 콘텐츠를 요청하면서 자신이 지원하는 압축 알고리즘을 HTTP 요청 헤더에 나열하여 알려준다.
    • 웹 서버는 내용에 나열된 방식 중 자신이 지원하는 압축 알고리즘 하나를 선택해 HTTP 응답 헤더로 클라이언트에게 알려줌으로써 클라이언트가 해당 방식으로 압축 콘텐츠를 해제할 수 있게 한다.
  • 요청 헤더는 Accept-Encoding, 응답 헤더는 Content-Encoding을 사용한다.
// 클라이언트 요청 헤더 - 브라우저는 gzip, deflate, sdch 압축 방식을 지원
Accept-Encoding : gzip, deflate, sdch

// 웹 서버 응답 헤더 : 클라이언트가 지원하는 압축 방식 중 gzip을 사용할 것을 명시
Content-Encoding : gzip
  • 각 압축 방식
    • gzip : UNIX 운영체제에서 일반적으로 사용하는 LZ77 파일 압축 라이브러리 사용
    • deflate : zlib 파일 압축 라이브러리 사용 (RFC 1951)
    • sdch(Shared Dictionary Compression over HTTP) 구글이 개발한 HTTP 상의 압축 방식이며 주로 크롬 브라우저에서 사용

3.2.2 스크립트 파일 최소화

  • 스크립트 파일 최소화 기법은 스크립트 파일에 포함된 주석, 공백, 개행 문자 등 실제 로직에 영향을 주지 않는 부분을 제거해 파일 크기를 줄이는 방법이다.
    • 이를 도와주는 사이트로 Minify 라는 사이트가 있다.
  • 스크립트 파일 최소화를 할 때 중요한 점은 기존 로직을 변경하거나 새로운 버그를 디버깅하는 등 개발자 작업이 필요한 경우 최소화된 파일로는 작업이 불가능해질 수 있다.
    • 이를 위해 개발 서버와 운영 서버를 분리하는 방법을 이용한다. 개발 서버에는 스크립트 원본 파일을 두고, 로직 테스트 및 검증 작업 완료 후에는 스크립트를 최소화에 운영시 최소화된 스크립트 파일을 사용한다.

3.2.3 이미지 파일 압축

  • 이미지 파일은 파일 정보에 메타 데이터(meta data)를 포함해 저장하는데, 사람의 눈에는 보이지 않는 부분이므로 불필요한 부분을 제거하면 크기를 상당히 줄일 수 있다.
  • 온라인 이미지 압축 서비스를 사용해 실시간 압축을 진행할 수 있다.

3.2.4 브라우저가 선호하는 이미지 포맷 사용

  • 웹상의 이미지는 JPG, GIF, PNG, BMP 등 다양한 포맷이 존재하며, 구글이나 마이크로소프트에서는 동일 품질의 이미지 크기를 더욱 줄일 수 있는 이미지 포맷(WebP, JPEG XR)을 개발했다.

WebP

  • 구글에서 개발한 손실 압축 방식을 사용하는 이미지 형식이다.
  • 크롬 브라우저와 안드로이드 계열에 적용된 형식이다.
  • JPEG 이미지 형식을 대체하면서 트래픽 감소, 로딩 속도 단축을 목적으로 개발되었다.
  • JPEG에 비해 크기를 80%까지 압축할 수 있고, 평균 50% 정도 파일 크기가 작아진다.

JPEG XR

  • 마이크로소프트가 JPEG 형식에 장점을 추가해 개발한 이미지 압축 형식이며 손실 압축과 비손실 압축 방식을 모두 지원한다.
  • 엣지 브라우저와 어도비사 이미지 제작 툴이 이 형식을 지원한다.

3.2.5 큰 파일은 작게 나누어 전송

  • 동영상 같이 큰 파일의 경우 사람에 따라 보지 않는 부분이 있을 수 있으므로, 모든 파일을 다운로드하는 방식은 자원 낭비가 발생할 수 있다.
    • 큰 파일의 일부분을 순서대로 다운로드하는 부분 요청 응답 방식을 사용할 수 있다.
  • 부분 요청 응답 방식은 웹 서버에 특정 부분 파일 전달을 지원하는 기능이 있을 때 사용할 수 있다.
// 웹 서버의 부분 응답 지원 여부 확인
curl - I http://www.example.com/bigfile.jpg

HTTP/1.1 200 OK
(중략)
Accept-Ranges: bytes
Content-Length: 50000000
(생략)
  • Accept-Ranges: byte
    • byte 단위로 파일의 부분 지원 기능을 수락한다는 의미
  • Content-Length: 50000000
    • 해당 파일의 전체 크기가 50MB라는 정보를 클라이언트에게 알려준다.
// 웹 서버 206의 응답
HTTP/1.1 206 Partial Content
Content-Range : bytes 0-1023/50000000
Content-Length: 1024
(생략)
  • Content-Range: byte 0-1023/50000000
    • 전체 파일 범위(50000000바이트) 중 처음부터 1,023 바이트까지만 전달하겠다는 의미
  • Content-Length: 1024
    • 현재 전달한 부분 파일에 전체 용량이 시작 위치와 끝 위치를 알려주는 데이터를 포함하여 1,024 바이트 임을 명시

3.3 캐시 최적화하기

  • IT에서 말하는 캐시는 자주 사용되는 콘텐츠, 특정 데이터 등을 임의의 저장소에 복제해두고 재사용하는 방식을 의미한다.
  • 일반적으로 시스템이 캐시 저장소에 접근하는 시간이 원래 데이터 위치에 접근하는 시간보다 짧고, 시스템 리소스를 아낄 수 있는 점에 착안해 콘텐츠를 다시 받아오는 시간을 절약하고 싶을 때 캐시를 사용한다.
  • 인터넷상에서 캐시는 ISP 회사가 지역에 분포된 특정 시스템에 사용자, 원격 시스템 사이에서 주고받은 데이터를 캐시하고 다음 사용자에게 제공하는 방식으로 사용되며, 콘텐츠를 캐시하는 이 시스템을 **프록시 서버(proxy)**라 부른다.
    • 인터넷 캐시는 캐시 영역에 데이터를 미리 복사하는 PUSH 방식, 실제 요청이 있을 때만 캐시에 저장하는 PULL 방식으로 분류된다.

3.3.1 인터넷 캐시 사용

  • 프록시라는 단어는 대리인을 의미하며, 인터넷 구간에서 서버 대신 클라이언트의 자원 요청에 응답해주는 본연의 기능에서 유래되었다.
  • 콘텐츠 소비자, 제공자 사이의 인터넷 구간이 멀 때 구간의 중간에 하드웨어 또는 소프트웨어 방식으로 프록시를 설치해 사용한다.
    • 서버와 클라이언트 사이에서 통신을 대신하는 기능 자체를 프록시, 그 중계 기능을 수행하는 서버를 프록시 서버라고 한다.

프록시 서버

  • 클라이언트가 처음 요청한 콘텐츠를 원본 서버(origin server) 대신 요청하여 클라이언트에게 전달해주고 이를 스스로 저장한다.
  • 사용자가 많은 지역에 여러 곳을 선택하여 설치하는데, 먼 곳의 원본 서버 콘텐츠를 캐시하여 저장하고 클라이언트 요청시 대신 응답해준다.
    • 프록시 서버 응답 속도는 원래 서버보다 응답 속도가 빠르다는 장점이 있다.
    • 인터넷 트래픽을 프록시 서버로 분산해 원본 서버의 자원을 절약한다.

3.3.2 브라우저 캐시 사용

  • 브라우저 캐시는 클라이언트 위치의 캐시를 말하며, 특정 웹 사이트에서 받아온 웹 콘텐츠들 중 브라우저가 저장할 수 있는 콘텐츠들을 저장해, 인터넷 상의 요청을 하지 않겠다는 개념이다.
  • 특정 콘텐츠에 브라우저 캐시 사용 여부는 웹 서버에서 먼저 결정해야하므로, 웹 서버 관리자가 캐시 정책을 조사하고 캐시 설정에 적용해야 한다.
  • 웹 서버는 Cache-Control 응답 헤더를 통해 얼마나 긴 시간 동안 캐시해도 되는지에 대한 정책을 클라이언트에 전달한다.
// 캐시 TTL 설정
Cache-Control : max-age = <캐시를 할 시간(초 단위)>

Cache-Control : max-age = 3600 (1시간 동안 캐시 가능)
  • 원본 서버의 콘텐츠 갱신 여부를 미리 조사해 변경이 없을 때만 캐시된 콘텐츠를 사용하도록 할 수 있다.
Cache-Control : no-cache
  • 캐시 가능 주기를 확인하여 범위 내에서만 캐시를 사용하도록 할 수 있다.
Cache-Control : must-revalidate
  • 캐시가 가능한 지 불가능한지를 헤더 값을 통해 확인할 수도 있다.
// 캐시가 절대 불가능함을 알려주는 헤더 값
Cache-Control : no-cache, no-store, must-revalidate

// 캐시할 수 있음을 알려주는 헤더 값
Cache-Control : public, max-age = 31536000

3.4 CDN(Content Delivery Network, 콘텐츠 전송 네트워크) 사용하기

  • 웹 콘텐츠를 사용자에게 빠르게 전달하기 위해 캐시 서버(cache server) 혹은 에지 서버(edge server)라 불리는 대용량 인터넷 캐시 영역에 콘텐츠를 저장해 사용하는 네트워크 방식
  • 촘촘히 분산된 서버로 이루어졌으며, 사용자의 웹 콘텐츠 요청에 직접 응답한다.
  • 원본 서버라 불리는 콘텐츠 서버와 사용자 사이에서 중재자 역할을 한다.
  • 주로 ISP 데이터 센터 내에 캐시 서버를 두고 이를 직접 사용자와 연결해 데이터를 전송한다.
  • 최근에는 데이터 센터에서 클라우드로 이동하는 추세이기 때문에 인터넷상에서 콘텐츠 전달시 발생할 수 있는 문제점을 개선하거나 성능을 유지하고 관리해야 하는 새로운 과제가 등장하고 있다.

CDN 사용의 장점

  1. 인터넷상 원거리에 있는 콘텐츠를 전달받는 과정에서 클라이언트와 웹 서버 사이에 발생할 수 있는 네트워크 지연(network latency)과 패킷 손실(packet loss)현상을 줄일 수 있다.

  2. 사용자는 가까운 에지 서버에 캐시된 콘텐츠를 전달받으므로 전송에 필요한 RTT(Round Trip Time)이 줄어들어 빠르게 콘텐츠를 받을 수 있다.

  3. CDN의 에지 서버가 캐시된 콘텐츠를 전송하므로 원본 서버의 부하를 줄일 수 있다. (인프라 비용 절감 효과)

  4. 콘텐츠가 에지 서버와 주변 에지 서버 사이에 ICP(Internet Cache Protocol)을 이용한 서버 전파를 할 수 있어 캐시 콘텐츠의 재사용률이 매우 높다.

  5. CDN 사업자들은 사용자 요청 트래픽, 기술적 특이 사항을 모니터하는 시스템을 통해 시스템 및 인적 관리 비용이 절감된다.


© 2022 Developer Abel, Powered By Gatsby.