[웹 성능 최적화] 웹 최적화

1. 웹 최적화란?

 

(1) 웹 최적화란 : 웹 최적화란 최고의 웹 성능을 구현하기 위해 최고의 조건을 만드는 다양한 노력을 의미한다. 즉 최고의 성능을 만드는 최적화 조건을 갖추는 것이다. 최적화에는 크게 세 가지 방법이 있다.

 

(2) 프런트엔드 최적화 : 웹 UI/UX 관련된 최적화이다. 주로 HTML, JS, CSS, Image을 최적화를 진행한다.

최적화가 잘되어 있는 웹사이트는 브라우저에서 콘텐츠를 다운로드, 로딩, 렌더링 할 때 속도가 빨라진다.

브라우징 시간별 콘텐츠를 볼 때 대부분 프런트엔드에서 발생한다.

프런트엔드 최적화하는 대표적 기술은 표와 같다.

스트립트를 병합하여 브라우저의 호출 개수를 줄인다.	도메인 수를 줄여 DNS조회를 최소화한다.
스크립트 크기를 최소화해 바이트자체를 줄인다.	DNS 정보를 미리 읽어 온다.
스크립트를 gzip 등으로 압축하여 전달한다.	CSS를 HTML상단에, JS를 HTML하단에 위치시킨다.
WebP 등으로 브라우저 이미지 형식을 최적화한다	page prefetching한다.
이미지 손실, 무손실 압축한다.	타사 스크립트가 웹 성능을 방해하지 않도록 조정한다.
Cache-Control 응답헤더를 통해 브라우저 캐시를 충실히 사용한다.

 

(3) 백엔드 최적화 : 웹 서버, 웹 애플리케이션 서버, 데이터베이스, 로드 밸런싱, DNS 서버 등을 최적화한다.

백엔드 최적화하는 대표적 기술은 표와 같다.

DNS 응답이 빨라지도록 서버 증설한다.	CDN을 사용해 인터넷상에 콘텐츠 캐싱한다.
DNS 응답을 빠르게 할 수 있도록 DNS정보를 최대한 캐싱한다.	데이터베이스 정규화로 디스크 I/O 최적화한다.
웹 서버가 있는 데이터 센터의 네트워크 출력/대역폭 증설한다.	데이터베이스 캐싱으로 응답을 빠르게한다.
웹 서버, 웹 애플리케이션 서버의 CPU/RAM 증설한다.	로드밸런싱을 통해 가장 성능이 좋은 웹 서버로 요청을 연결한다.
프록시 서버를 설정하여 웹 콘텐츠를 캐싱 한다.	웹 애프리케이션 로직을 가볍고 빠르게 개발한다.

 

(4) 프로토콜 최적화 : HTTP 프로토콜 자체의 효과를 극대화하면 콘텐츠를 최도 속도와 최저 지연 시간으로 전달할 수 있다. 즉 프로토콜 최적화는 웹 콘텐츠를 더 빠르게 요청하고 응답하도록 프로토콜을 업그레이드하는 과정이다.

 

 

 

2. TCP/IP 프로토콜

(1)  : 

 

- 웹은 HTTP를 사용해 콘탠츠를 전달한다.

 

- OSI 7개 계층 모델에서 TCP는  4번째인 전송 계층에 속한다.

 

- HTTP는 7번째인 응용 계층에 속한다.

 

- 전송 계층 : 네트워크상에서 송신자와 수신자 사이에 데이터 전송을 보장하는 역할을 한다.

 

- 응용 계층 : 실제 네트워크상에서 소프트웨어와 사용자의 상호 연동을 담당한다.

 

-두 개의 계층은 독립이 아닌 상위 계층이 하위 계층을 바탕으로 운용되는 구조이다.

 

(2) TCP네트워크 대표적인 성능 지표 : 대표적인 성능 지표는 대역폭과 지연 시간이 있다.

 

- 대역폭 : 특정 시간 동안 얼마나 많은 네트워크 트래픽을 보낼 수 있는지 시간당 전송량을 의미한다.

 

- 지연 시간 : 클라이언트와 서버 간 콘텐츠를 전달하는 물리적인 시간을 말한다. 일반적으로 클라이언트와 서번 사이 요청, 전달, 응답까지 걸리는 시간이다. 단 렌더링 단계는 클라이언트 측에서만 실행하므로 지연 시간에 포함되지 않는다.

 

- RTT(Round Trip Time) : 서버와 클라이언트 두 호스트를 모두 왕복하는 데 걸리는 지연시간이다. 게임, 화상 채팅 등의 품질에 영향을 준다.

 

(3) TCP 혼잡 제어 : 

 

- TCP 혼잡 제어 :TCP 네트워크의 통신량을 조절하여 TCP네트워크가 혼잡해지지 않도록 하는 방식.

 

- TCP 혼잡 붕괴 : TCP 네트워크의 통신량이 실제 처리량보다 많아서 문제가 발생하는 것. 호스트들이 최대한 많은 정보를 전송하려고 많은 네트워크 패킷을 보내기 때문에 발생한다.

 

- TCP 혼잡 제어 기술 : 패킷을 보내는 쪽에서 네트워크에서 수용할 수 있는 양을 파악하고, 그만큼의 패킷만 보내는 약속으로 해결 가능하다. 

받는 쪽은 패킷이 정상적으로 송신되었음을 알리는 ACK 패킷을 보내며 ACK 패킷을 받은 호스트는 지속적으로 패킷을 보낼 수 있다. 호스트가 네트워크의 상태를 시시각각 파악하고 전송 속도를 조절하는 것 또한 혼잡 제어 기능 중 하나이다.

 

- 느린 시작 : 

느린 시작은 전송 가능한 버퍼의 양인 혼잡 윈도우(CWND)의 초깃값을 작게 설정하여 전송한다. 예를 들어 통신이 시작되면 패킷 1개만 보내고, ACK를 받으면 패킷 2배인 2개를 전송한다. 이러한 과정을 패킷 유실이 발생하기 전까지 반복하는 방식이다. ACK 응답을 받지 못하면 혼잡윈도의 크기는 더 이상 늘리지 않는다.

이런 식으로 네트워크에서 수용할 수 있는 혼잡윈도우의 크기를 파악하면 그 이상의 패킷을 보내지 않는다. HTTP에서도 그대로 사용된다.

 

- 빠른 재전송 : 

빠른 재전송은 먼저 도착해야 하는 패킷이 도착하지 않고 다음 패킷이 도착한 경우에도 수신자가 일단 ACK패킷을 보내는 방식이다. 중간에 패킷 하나 손실되면 송신자는 중복된  ACK 패킷을 통해 이를 감지하고 유실되었던 패킷을 재전송한다. 또한 중복된 패킷을 3개 받으면 반드시 손실된 패킷을 재전송한다.

 

- 흐름 제어 : 흐름 제어는 TCP 송신자가 너무 빠르게 혹은 너무 많은 전송 하여 수신자의 버퍼가 오버플로 되는 거을 방지하는 기술이다. 수신자는 수신 버퍼를 가지고 있는데 이로 인해 상위 계층으로 세그먼트를 보내는 애플리케이션 프로세스에서 데이터를 읽는 속도가 느려질 수 있다. 그러므로 송신자가 데이터를 전송하는 속도를 애플리케이션 프로세스를 읽는 속도와 유사한 수준으로 만들어야 한다.

 

 

 

 

3. HTTP 프로토콜

(1)  : HTTP는 콘텐츠를 웹에서 전달하기 위해 만들어진 프로토콜로 HTTP 성능을 개선하면 웹 성능도 향상된다.

 

(2)  HTTP최적화 기술 : HTTP는 크게 여섯 차례 업데이트했다.

 

- HTTP/0.9 : 인터넷 통신 정상화, 가용성, 신뢰성 등 기능에 초점을 뒀다.

 

- HTTP/1.0 : 클라이언트와 서버 사이 요청과 응답을 빠르게 할 수 있는 연구 진행했다.

 

- HTTP/1.1 : 멀티 호스트  환경에 대응하기 위해서 멀티 호스팅 기능과 TCP/IP 연결을 재사용하는 기능을 추가했다. 특히 연결 재사용(persistent connection), 파이프라이닝(pipelining) 기법이 연결 기반의  HTTP 최적화 기술이다.

 

(3)  HTTP 지속적 연결 :

 

-3 way handshake : 

위의 사진처럼 TCP의 통신을 연결하는 방식은 3 way handshake 방식이다.

초기 HTTP도  3 way handshake 방식으로 TCP 연결을 맺었다. 하지만 많은 웹 콘텐츠 전달에 번거로움이 발생했다.

 

-지속적 연결 기술 : 콘텐츠가 늘어나면서 TCP 연결 재상용이 필요하게 되어서 등장했다.

HTTP 지속적 연결은 클라이언트와 서버가 TCP상에서 한 번 연결되면 둘 사이의 연결이 완전하게 끊어지기 전까지 맺어진 열결을 지속적으로 재사용하는 기술이다. 

HTTP/1.0에서는  요청 헤더의 Connction : keep-alive를 통해서 가능하다. 그 후 HTTP/1.1 버전에서부턴 지속적 연결을 기본으로 지원한다. 필요하지 않은 경우만 Connection : close를 포함하면 된다.

 

-HTTP/2 이후 : HTTP/2은 스트림 형태로 HTTP 요청과 응답을 주고받는 멀티플렉싱 기술로 만들어져서 지속적 연결을 고민할 필요가 없다.

 

(3)  HTTP 파이프라이닝 : 

HTTP 파이프라이닝은 HTTP 선입 선출 단점을 극복하는 방법이다.

 

- 기존에는 HTTP 요청과 응답이 여럿일 때 하나의 응답이 지연되면 나머지 요청과 응답 모두 지연되는 구조이다. 

 

- HTTP 파이프라이닝은 요청의 응답이 없어도 다음 요청을 병렬적으로 수신자 측에 전송하는 기술이다. 즉 응답 지연이 발생하더라도 클라이언트는 먼저 서버 측의 응답을 받을 수 있어 빠른 웹 로딩이 구현된다. 

 

 

 

4. DNS

(1) DNS란? : DNS는 인터넷 호스트명을 클라이언트와 서버가 이해할 수 있는 IP 주소로 변환해주는 시스템이다. 기억하기 쉬운 호스트명을 사용한다. DNS 질의, 응답 성능은 웹 사이트 로딩에 영향을 준다.

 

(2) DNS의 작동 원리 : 

 

1. 웹 브라우저에 www.naver.com을 입력하면 먼저 Local DNS에게 "www.naver.com"이라는 hostname"에 대한 IP 주소를 질의하여  Local DNS에 없으면 다른 DNS name 서버 정보를 받음(Root DNS 정보 전달 받음)

2. Root DNS 서버에 "www.naver.com" 질의

3. Root DNS 서버로부터 "com 도메인"을 관리하는 TLD (Top-Level Domain) 이름 서버 정보 전달 받음

4. TLD에 "www.naver.com" 질의

5. TLD에서 "name.com" 관리하는 DNS 정보 전달

6. "naver.com" 도메인을 관리하는 DNS 서버에 "www.naver.com" 호스트네임에 대한 IP 주소 질의

7. Local DNS 서버에게 "응! www.naver.com에 대한 IP 주소는 222.122.195.6 응답 

8. Local DNS는 www.naver.com에 대한 IP 주소를 캐싱을 하고 IP 주소 정보 전달 

출처: https://ijbgo.tistory.com/27 [한량 개발자]

 

(3) 사용 중인 다양한 도메인 확인 방법 : 최근 웹사이트는 다른 웹 서비스의 다양한 콘텐츠를 호출하여 사용한다.

 

- 사용 중인 도메인 확인 : 

크롬에서 [도구 더보기] -> [개발자 도구] -> [Source] 항목을 통해 어떤 도메인들이 사용되고 있는지 볼 수 있다.

 

- 타사 서비스는 해당 업체가 DNS를 관리하므로 페이지 안에 삽입된 타사 서비스 도메인이 조회 속도가 느려지면 전반적인 웹 페이지 로딩에 문제가 발생할 수 있다.

 

(4) 웹 성능을 최적화하는 도메인 운용 방법 : 

 

- 많은 도메인 호스트명을 사용하면 DNS질의가 늘어나 웹 성능에 영향을 준다. 따라서 내부 서비스에 도메인 분할을 하려면 상위 도메인을 동일하게 해야 질의가 적어진다.

 

- 공통된 상위 도메인 사용 : 네임 서버에 캐싱된 정보를 재사용할 수 있어 DNS질의 시간을 단축시킨다. 또한 HTTPS 위한 SSL 인증서를 와일드카드 형식으로 하나만 생성해도 된다.

 

- HTML의 DNS 프리페치(prefetch) : 

프리페치 사용 시 웹페이지 사용된 도메인들의 DNS를 조회하는 시간이 좀 더 빨라진다. 프리 페치란 하나의 웹페이지에 다수의 도메인 호스트명이 섞여있을 때 웹 문서 페이지를 여는 시점에 멀티스레드 방식으로 미리 DNS를 조회해 빠르게 IP주소를 불러오는 기술이다. 단 특정 브라우저는 프리 페치 기능을 지원하지 않을 수 있다.

 

 

 

 

 

5. 브라우저

(1) 브라우저란? : HTTP, DNS를 사용해 사용자가 원하는 HTML, 동영상 등의 웹 콘텐츠를 전달하는 소프트웨어이다.

 

(2) 브라우저의 역사와 특징 : 1900 초반 웹이 만들어진 시대와 함께 개발되었다. 초기 HTTP, DNS 기술 접목한 주소에서 접속할 웹 서버의 ip를 찾고 HTTP로 웹서버에 접속해 콘텐츠를 가져오는 단순한 기능을 수행했다. 그 후 익스플로러 3 버전 출시 후 CSS와 오디오가 추가되었고 점점 비디오 형태 증가로 HTML5, CSS3버전이 개발되었다.

 

 

 

 

 

6. 내비게이션 타이밍 API(Navigation Timing API)

속성들

(1) 내비게이션 타이밍 API란? : 웹 사이트의 성능을 측정하는데 사용할 수 있는 데이터를 제공한다. 정확한 종단 간 대기 시간 정보를 제공합니다.

 

(2) window.performance.timing 속성 :

timing 속성은 탐색과 페이지 로드 이벤트에 대한 데이터를 갖고 있다.

timing 속성은 페이지 로드 이벤트 시간을 1970년 1월1일 자정을 기준으로 측정한 값이다.

이것을 통해서 각 단계가 언제 완료 되었는지, 어떤 항목에서 시간이 지체되는지 확인할 수 있다.

0 값은 이벤트가 발생하지 않은 것이다.

 

(3) window.performance.navigation : 

- navigation객체는 페이지 재전송, 앞뒤 이동버튼, URL이 어떤 페이지 로딩을 발생시키는지 확인하는 속성이 있다.

 

-navigation.redirectCount : 페이지 내에서 재전송이 몇 번 발생하는지 알려준다.

 

-navigation.type : 사용자가 해당 웹 페이지에 어떻게 접속했는지에 관한 정보 알려준다.

 

(4) window.performance.timing.navigation : 을 이용한 사용자가 느끼는 페이지 로딩 시간 값구하기.

<!DOCTYPE html>
<html lang="en">
<head>
    <title>Document</title>
    <script type="text/javascript">
        function onLoad() { //함수 정의
            var now = new Date().getTime(); //현재시간 기록
            var page_load_time = now - performance.timing.navigationStart; //현재시간에서 로딩시간 차이
            console.log("사용자 인식 페이지 로딩시간 : " + page_load_time);
        }
    </script>
</head>
<body>
    사용자가 인식하는 페이지 로딩시간 구하기.
    <script>
        onLoad(); //onLoad 함수 실행
    </script>
</body>

</html>

 

(5) performance.timing의 여러 이벤트들 : 

<!DOCTYPE html>
<html lang="en">

<head>
    <title>Document</title>
    <script type="text/javascript">
        function onLoad() {
            var perfData = window.performance.timing;

            var pageLoadTime = perfData.loadEventEnd - perfData.navigationStart;
            console.log(pageLoadTime);

            var connectTime = perfData.redirectEnd - perfData.redirectStart;
            console.log(connectTime);
        }
    </script>
</head>
<body>
    여러가지 콘텐츠들
    <script>
        onLoad();
    </script>
</body>

</html>

 

- 페이지 전체 로드 시간 : navigationStatrt 이용

 

- HTTP 요청에서 응답까지 걸린 시간 : requestStart 이용