유.무선 네트워크 환경에서 Web Performance Engineering

안녕하세요, SK플래닛 김홍수 매니저입니다. 이번 포스팅에서는 Web Performance Engineering이라는 주제로 유/무선 네트워크 환경에서 모바일 디바이스를 통해 웹 사이트를 접근하는데 있어서 어떤 bottleneck이 있고, 이를 해결하기 위해서 서비스 제공자들은 웹 사이트를 어떻게 개발해야 하는지에 대해서 end-to-end 네트워크, front-end 서버, 그리고 back-end 서버 관점에서 해야 할 최적화 활동들에 대해서 알아보려고 합니다.

물론 이러한 내용들을 모두 다루려는 것은 아니고 end-to-end 네트워크 환경에서 우리가 웹 서버를 통해서 컨텐츠를 서비스 받는 입장에서 어떻게 리소스들이 전달이 되고 네트워크 측면에서의 성능을 최적화할 수 있는 몇 가지 방법들에 대해서 소개를 하고자 합니다. 이 포스팅은 Google의 “Make The Web Faster”팀에서 근무하는 Ilya Grigorik이 Velocity 2013/2014년에 발표한 내용을 참고로 작성되었고, 주요 e-Commerce 사이트들을 오픈 소스 기반 웹 사이트 분석 툴을 이용해서 분석하여 장/단점에 대해서 같이 공유해보도록 하겠습니다.

상위 2000개의 e-Commerce 사이트들이 매년 22%의 성능 저하 (웹페이지 로딩 시간 증가)를 보인다고 합니다(infographic, 2013).  더욱이 페이지를 로드하는데 1 초(second)의 시간이 더 걸린다는 것은 7%에 사용자 이탈을 의미하고, 11%에 페이지 뷰가 감소하며, 16%에 고객들의 만족도가 감소한다고 합니다.

당사의 커머스 사업분야 뿐만 아니라 다수의 서비스가 웹 기반으로 개발되고 있는 상황에서 웹 페이지 로딩 시간은 성공적인 서비스 비즈니스를 위해서  매우 중요한 요소라고 할 수 있습니다. 게다가, 최근 데스크탑 클라이언트 보다는 모바일 클라이언트를 통해 웹페이지를 요청하는 비율이 급격하게 늘어나고 있는 추세입니다. 또한, HTTP 1.0이 1996년 발표된 이래로 큰 변화가 없던 이 표준 인터넷 프로토콜은 이제 곧 IETF에서 HTTP 2.0 규격이 발표된 예정입니다. 과거 20년 동안 인터넷 환경은 물리적인 네트워크 하드웨어 사양은 좋아졌지만, HTTP를 통한 요청 수 및 리소스 사용량은 20배 가량 증가하였습니다. 그에 비해서 HTTP 1.1을 사용하여 처리하는 효율성은 정체가 되어 있는 게 사실입니다.
따라서, 이번 포스팅에서는 무선 환경 및 모바일 디바이스를 통해 웹페이지를 요청하는데 있어서 해결되어야 할 문제들과 서비스 서버를 개발하는 입장에서 고려되어야 할 최적화 문제들에 대해서 같이 고민해보고자 합니다. 그리고 주요 e-Commerce 사이트들의 성능 상의 차이점과 원인에 대해서 같이 고민해보고자 합니다.

End-to-End 네트워크 환경에서 웹 페이지 테스트에 대한 이해

과거에도 그랬고 LTE가 대세인 현재에도 ISP (Internet Service Provider) 들과 통신사업자들은 네트워크 대역폭 (Bandwidth)에 대해서는 광고하지만, 네트워크 지연(Latency)에 대해서 언급하는 것을 들어보셨는지요? 아래 그림과 같이 사용자들의 디바이스는 다양한 유/무선 네트워크를 통해서 특정 서버에 서비스를 요청을 하게 됩니다.

무선 네트워크 환경 구성도

그림1. 무선 네트워크 환경 구성도

위 그림과 같이 우리 고객들이 네트워크에 접속하는 환경은 다양할 텐데, 모바일 디바이스라면 대체로 WiFi 네트워크 환경이나 3G/4G 무선 네트워크 환경을 통해서 서비스 서버에 접속하게 될 것입니다. 우리가 듣고 보는 무선 네트워크 환경 (3G/4G)은 클라이언트 디바이스와 접해있는 말단 네트워크 환경 (last mile)인 것이고, 최종 서비스 서버까지는 다양한 네트워크 환경으로 구성이 되어 있어, 거리에 따른 기본 네트워크 지연이 발생할 수 밖에 없습니다. 또한 이러한 기본 네트워크는 모든 클라이언트들의 요청 패킷들이 난무하며 경쟁하는 상황일 겁니다.

무선 네트워크 환경에서 “Last-mile Problem”이라고 하면 클라이언트가 네트워크를 통해서 서비스 서버에 접속하는데 있어서 대역폭 및 기본적인 물리적인 거리로 인한 네트워크 지연뿐만 아니라 무선 네트워크 환경을 이해할 필요가 있습니다. 무선 네트워크 환경은 아래 그림과 같이 External Network, Core Network, Radio Access Network로 구분할 수가 있습니다. 이러한 환경에서 외부 네트워크를 통해 Radio Access Network의 기지국에 위치한 모바일 디바이스와 통신을 한다고 가정을 하면, 아래와 같은 순서로 통신이 수행합니다.

  1. 외부 네트워크에서의 데이터 패킷은 Core Network의 PGW (Package GW)가 수신.
  2. Core Network에서 PGW는 SGW (Serving GW)로 전달이 되고, 다시 MME (Mobility Management Entity)에게 타겟 디바이스가 어느 기지국(eNB: eNodeB)에 있는지 문의.
  3. eNB는 해당 기지국에 연결되어 있는 타겟 디바이스에게 데이터 수신 알림 (in-active 상태라면, 데이터를 받을 수 있는 active 상태로 변환).
  4. 타겟 디바이스는 데이터를 받을 수 있는 상태라고 답변.
  5. eNB는 MME에게 타겟 디바이스에게 데이터를 보내도 된다는 메시지를 eNB 정보와 함께 SGW로 전달.
  6. 이제서야 SGW 는 외부 네트워크로 부터 전달된 데이터 패킷을 eNB에 전달하게 됨.
  7. 최종적으로 eNB는 타겟 디바이스에게 데이터 패킷을 전달함.

이와 같이 모바일 네트워크 환경에서 모바일 디바이스로 데이터를 보내기 위해서는 복잡한 노드들을 거쳐야 하는, 이러한 문제를 우리는 “Last-mile Problem”이라고 정의합니다. 모바일 디바이스는 이런 last-mile problem으로 인해 네트워크 지연이 기본적으로 발생되게 됩니다. 뒤에서도 설명을 하겠지만, 이러한 네트워크 지연으로 인해 디바이스와 서버 간의 통신 시에는 필수적으로 서버에서는 connection pool을 통한 재사용 방법을 사용해야 하며, 클라이언트에서는 caching policy를 통해서 필요한 오브젝트들은 cache를 사용하는 방법을 사용해야만 합니다.

그림2. 외부 네트워크를 통해 모바일 디바이스와 통신하는 네트워크 흐름도

지금까지 알아본 바와 같이, 성능은 대부분 대역폭과 네트워크 지연을 포함한 값에 근접함을 알 수 있습니다. 여기에다가 전체 웹 사이트의 성능은 CDN (Content Delivery Networks), Image/Text Compression, Domain sharding, Enable keep-live 등의 기술들을 어떻게 잘 활용하느냐에 따라서 많이 차이가 날 수 있습니다. 또한 웹 페이지를 로딩하는데 있어서 네트워크 대역폭과 전송 지연과의 상관관계에 대한 실험 결과를 보면 아래와 같습니다. 결론적으로 네트워크 대역폭은 특정 시점에서 수렴되므로 해당 시점 이후에는 크게 성능상 차이가 없지만, 네트워크 지연의 경우에는 지연이 작으면 작을 수록 전체 웹 페이지를 로딩하는데 있어서 성능은 좋아지는 것을 볼 수 있습니다.


그림3. 네트워크 대역폭과 전송 지연 간의 상관관계, 참고: http://chimera.labs.oreilly.com/books/1230000000545

다음으로, 우리는 클라이언트가 서버로 HTTP를 통해서 웹페이지를 요청 할 때 어떤 일들이 일어나는지 어떤 요청 구간에서 얼마나 시간이 걸리는지에 대해 알아볼 필요가 있습니다. 아래 그림에서 보듯이 HTTP 요청은 DNS lookup, Socket Connect, HTTP Request, Content Download 네 단계로 수행이 됩니다.

  • DNS lookup: 대상 서버의 호스트 이름을 IP 주소를 변환하는 단계
  • Socket connection ( New TCP connection, TLS handshake): 클라이언트와 서버 간 접속을 위해서 TCP handshake 을 수행하고, 필요하면 TLS handshake를 통해서 접속 요청 단계
  • HTTP request: 서버로 HTTP 헤더와 데이터 전송 요청 단계.
  • Content download: 서버로부터 웹 컨텐츠 다운로드 단계.
위와 같이 크게 네 가지 단계로 클라이언트와 서버 간에 데이터 통신을 통해서 웹 페이지를 로딩하게 됩니다.

그림4. HTTP 요청에 대한 컴포넌트들, 참고: http://chimera.labs.oreilly.com/books/1230000000545

위와 같은 기본 HTTP 요청에 대한 이해를 바탕으로 당사 11번가 사이트를 Webapgetest (http://webpagetest.org) 툴을 이용해서 분석하면 아래와 같은 성능 측정 화면을 볼 수 있습니다. 결과에서 볼 수 있듯이 11번가의 메인 페이지는 169번의 요청 및 리소스를 수행하였고, 페이지 로딩 시간은 약 10.5초 걸렸음을 알 수 있습니다. 또한 각 요청에 대한 도메인도 알 수 있어서 몇 개의 도메인을 사용하였는지 각 요청에 대해서 수행한 시간이 얼마인지를 알 수 있습니다. 또 한가지 중요한 정보는 하나의 브라우저와 서버 간의 연결에 있어서 최대 한계 수가 존재한다는 것으로, 예를 들어, IE 9 버전의 브라우저의 경우 동시에 최대 6개의 연결을 유지할 수 있습니다. (참고: http://sgdev-blog.blogspot.kr/2014/01/maximum-concurrent-connection-to-same.html) 이러한 관점에서 11번가의 경우 2개의 이미지 서버(i.011st.com과 c.011st.com)에 대한 domain sharding을 사용하는 것을 볼 수 있습니다.

waterfall view
그림5. WebPagetest 툴을 이용한 11번가 웹 페이지 로딩 성능 측정

웹 페이지 성능 향상을 위해서 전송 계층 (TCP 프로토콜)의 원리를 알아야 한다?

모든 TCP 연결은 3-way handshake 단계(SYN -> SYN-ACK -> ACK)를 거치는데, Sender와 Receiver 간에 1 RTT (round-trip time)에 56 ms의 시간이 걸렸다면 첫 번째 데이터를 전송하기 위해서는 84 ms의 시간이 걸릴 것으로 예측을 할 수 있습니다. Sender와 Receiver 간에 3-way handshake가 끝나면 다음으로 데이터를 전송하게 되는데 초기에 서버는 무조건 4 segment (cwnd= 4, 1 segment = 1460 bytes) 크기의 데이터만 전송할 수 있고, 그 다음에는 두 배수로 CWND 크기를 늘려가며 데이터를 전송하게 됩니다. 일반적으로 우리는 이러한 알고리즘을 TCP slow-start라고 하고 이는 congestion control이라고 부릅니다. TCP slow-start 시에 초기 윈도우 크기는 리눅스 커널 버전에 따라 다른데, Linux kernel 3.2+ 이상의 버전에서는 초기 cwnd 크기가 10으로 설정이 되어있습니다.


그림6. TCP Slow-Start 메커니즘

특정 크기의 데이터를 네트워크를 통해서 전송하는데 있어서 RTT 값이 주어졌을 때, 우리는 아래 수식(RFC 2581)으로 전체 데이터를 전송하는 시간을 예측할 수 있습니다.


여기에서, RTT는 클라이언트 서버 간의 round-trip 시간이고 cwnd는 초기 congestion window 크기 값이며 N은 전송하고자 하는 데이터에 대한 segment 수를 나타낸다. 그렇다면, RTT가 56 ms일 때 64 KB의 데이터를 전송하는데 걸리는 시간을 예측하면 위 수식을 통해서 어떠한 값이 나올까요?

위 결과는 45 KB (46080 bytes)를 하나의 segment 크기 (1460 bytes)로 나누면 32 segment가 되므로, 위 수식에 대입하면 186 ms의 전송 시간이 걸림을 알 수 있고, 여기에 handshake RTT (56 ms)를 더하면 280 ms가 걸릴 수 있음을 유추할 수 있습니다.

그렇다면, 우리가 기존에 연결되어 있는 연결을 재사용(connection re-use)한다면, 전체 성능에 미치는 영향이 어느 정도일지 고민해 볼 필요가 있습니다. 예를 들어, 20 KB의 HTML 파일을 전송하는데 있어서 RTT가 56 ms, Bandwidth가 5 Mbps, 초기 cwnd 크기가 4라면, 236 ms의 전송 시간이 걸립니다. 하지만, 같은 HTML 파일을 이미 연결된 상태에서 재사용하여  전송하면 96 ms로, 275%의 성능 향상 효과를 볼 수 있습니다.

위에 내용을 요약하면, 첫째로 네트워크 대역폭이 충분히 큰 상황이라면 서비스 서버를 Linux kernel 3.2+로 업그레이드를 하여 초기 cwnd 크기를 10으로 설정하는 것을 권고합니다. 둘째로, 서비스 서버의 “slow-start after idle” 옵션을 비활성화 시킴으로써 클라이언트가 idle 상태에 있다가 재접속 했을 때 초기 cwnd 값부터 데이터를 전송하지 않고 최근 cwnd 값부터 데이터 전송을 수행할 수 있어 데이터 전송이 빨라질 수 있습니다. 셋째로, TCP 연결 재사용으로 HTTP는 기본적으로 connection-less 연결 방식으로 네트워크 측면에서 많은 비용이 발생되는데, 클라이언트 측면에서 HTTP를 통한 데이터 요청 시에 keep-alive 값을 설정함으로써 기존 TCP 연결을 재사용할 수 있습니다.  넷째로, 네트워크 지연으로 인한 성능 저하를 막고자 되도록 사용자와 가까운 곳에 서버를 위치하는 CDN 기술을 사용하여, 낮은 RTT로 인해 전체적으로 성능을 향상 시킬 수 있습니다. 마지막으로, 데이터 전송 시에 Text/Image를 압축하여 전송함으로써 전체적인 전송 비용을 줄 일 수 있습니다.

Real-User 성능 측정을 어떻게 할 수 있을까요?

웹 성능 최적화를 위해 사이트를 분석하는데 있어서 중요한 측정 방법 중에 하나가 RUM (Real User Measurement) 으로, 많은 상용 서비스들이 RUM 데이터를 수집하고 분석을 하여 실재 매출에 기여를 하는 사례가 늘어나고 있습니다. 실제로, Airbnb는 RUM을 통해 사용자 데이터를 분석하여 사용자들이 페이지를 떠나는 곳을 집중 분석하여 매출을 5배 향상시키는데 성공하였으며 (참고: https://mixpanel.com/case-study/airbnb/), 미국의 GILT 그룹은 로드 테스트와 RUM기반 사용자 데이터 분석을 활용하여 잠정적인 문제점을 해결하여 매출 향상에 크게 기여(참고: http://www.soasta.com/customers/case-studies/gilt-groupe-brings-web-performance-into-fashion/)하는 사례를 참고할 만 합니다.

웹 사이트의 성능을 측정하는 데에는 크게 두 가지 방법이 존재합니다. Synthetic monitoring 방법과 Real-User monitoring 방법으로, 첫번째 방법은 다양한 네트워크 환경 및 브라우저 환경을 시뮬레이션하기 위해서 다양한 지역 서버에 다양한 브라우저 시뮬레이터를 설치해서 특정 서버에 접속하여 데이터를 수집하고 분석하는 방법입니다. 두 번째 방법은 Agent-based monitoring이라고도 하는데 실 사용자의 자바 스크립트 코드에 삽입하여 서버에서 수집 및 분석하는 방법입니다. 여기에서는 W3C의 WebPerf WG에서 제안한 Navigation Timing API와 Resource Timing API를 사용하여 페이지 로딩 속도를 측정하는 방법에 대해서 알아보겠습니다.

우선 Navigation Timing API를 사용하기 위해서는 window.performance 객체의 프로퍼티로 접근을 해야 합니다. 본 API를 이해하는데 가장 쉬운 방법은 직접 브라우저를 열고 자바스크립트 콘솔에서 window.performance API를 아래와 같이 사용해보는 것입니다.

  1. 크롬 브라우저를 열고, Ctrl+Shift+J를 누르면 자바스크립트 콘솔 창이 열립니다.
  2. 자바스크립트 콘솔 창에 프롬프트에 performance라고 입력하고 엔터를 누릅니다.
  3. 결과에서 performance를 클릭하면 각 객체의 프로퍼티들(memory, navigation, timing 등)을 확인할 수 있는 세부 내용도 볼 수 있습니다.

[그림7. 크롬에서 window.performance API를 수행한 화면]

예전에는 웹 개발자가 페이지를 로딩하여 수행하는 시간을 측정하기 위해서 Date 객체를 사용하였지만, 자바스크립트로 구한 값이 정확하지 않았고 네트워크 지연으로 인한 페이지 로딩 시간에 대한 정확한 값을 구하기 힘들었습니다. 그래서 브라우저에서 제공되는 performance.timing 객체를 이용하면 정확한 값을 구할 수가 있습니다.  W3C의 권고안으로 Navigation Timing API는 페이지를 요청하고 로딩할 때 발생되는 모든 performance.timing 이벤트에 대한 값들을 알 수 있습니다. 예를 들어, loadEventEnd를 보고 싶으면, 아래 예제처럼 performance.timing 객체에 함수들을 이용할 수 있습니다.

window.onload = function(){
	setTimeout(function(){
	var t = performance.timing;
	console.log(t.loadEventEnd - t.responseEnd);
	}, 0);
}

간략하게 살펴본 Navigation Timing API는 시계열에 따른 페이지 성능 데이터를 구할 수 있는 방법을 제공합니다.
더욱이, W3C의 Resource Timing API를 사용하면 요청 페이지의 모든 리소스들 (Text/HTML, JS, CSS, Image 등)에 대한 성능 값들을 세부적으로 살펴 볼 수가 있습니다. 아래 그림과 같이 크롬 브라우저에서 자바스크립트 콘솔을 열고 window.performance.getEntriesByType(“resource”)를 입력하면 해당 페이지의 모든 리소스 정보들을 알 수 있습니다.

그림8. 크롬에서 window.performance API에 “resource” 사용정보를 수행한 화면

위에서 우리는 W3C의 권고안으로 Navigation Timing API를 이용해서 페이지 로딩 시간 뿐만 아니라 각 리소스들의 성능 측정 데이터를 구할 수 있습니다. 이러한 API를 이용해서 Synthetic Monitoring 툴을 개발한 대표적인 오픈소스가 WebPagetest(www.webpagetest.org) 입니다. WebPagetest는 전 세계 클라우드 서버에 시뮬레이터를 운영하면서 특정 웹 사이트를 지역별로 분석이 가능합니다.

Synthetic 모니터링을 이용해서 상용 서비스들에 대한 Benchmark 테스트를 해봅시다.

Benchmark 테스트를 위해서 웹 페이지에 대한 성능 분석을 제공하는 오픈소스 기반 성능 분석 서비스로 WebPagetest 툴을 이용하였습니다. WebPagetest는 오픈소스 프로젝트로 Google의 “Make The Web Faster”팀에서 개발 및 운영 지원을 하고 있습니다. 제가 작년 7월달에 WebPagetest 툴을 이용해서 성능 비교 분석을 진행한 내용을 간략히 공유하고자 합니다. 아래 그림에서 보는 바와 같이 세 가지 e-Commerce 사이트들(11st, Gmarket, amazon)에 대해서 성능 분석을 수행하였는데, 몇 가지 가정 사항은 네트워크 지연 (약 60ms~100ms)이 매우 큰 미주 지역인 Dulles에 클라이언트가 각 서비스 서버에 접속하여 웹 페이지를 로딩하는 시간을 측정하였습니다.

그림9. WebPagetest를 이용한 웹 페이지 성능 테스트 결과

WebPagetest를 통해서 국내 open market 1, 2위 사업자와 글로벌 open market으로 1위를 달라고 있는 Amazon 사이트의 페이지 로딩 시간을 측정하여 비교분석 해보았습니다.

1. CDN 사용에 따른 성능 차이

두 개의 국내 사이트는 상대적으로 네트워크 지연이 큰 미주 지역에서 요청을 해서 불리할 수 있지만, 결과를 놓고 보면 Gmarket 사이트가 월등히 성능이 좋은 것을 볼 수 있습니다. Gmarket사이트는 Akamai라는 CDN 회사의 네트워크를 활용하여 사용자의 요청에서 가까운 미주 지역의 CDN Edge 노드에서 데이터를 받아가서 상대적으로 페이지 로딩 시간이 짧았음을 알 수 있습니다. 아래 그림에서 볼 수 있듯이 B사이트는 해당 사이트의 모든 리소스를 Akamai라는 CDN 업체의 네트워크를 사용하여 다운로드 받는다는 것을 알 수 있습니다.

그림10. Gmarket의 특정 리소스의 위치 스냅샷

2. 효율적인 대역폭 사용으로 인한 성능 차이
사이트의 성능을 나타내는 지표 중에 하나로 얼마나 한정된 사용자의 네트워크 자원을 효율적으로 사용하여 리소스들을 다운로드 받았는지에 대한 관점입니다. 이 지표는 한정된 대역폭 상황에서 최대한 해당 대역폭을 모두 사용하면서 사이트를 로딩했는지에 대한 내용으로, 네트워크 지연이 큰 상황에서는 성능에 큰 영향을 미치는 지표이기도 합니다. 아래 그림에서 볼 수 있듯이 11번가 대비 Gmarket과 Amazon은 상대적으로 특정 시간대에 대부분의 네트워크 리소스 및 CPU 자원을 사용하여 페이지를 로딩하여 좋은 성능을 보임을 알 수 있습니다. 이는 브라우저 하나가 하나의 도메인 당 열 수 있는 연결 수가 한정이 되어 있는 상황에서 얼마나 적절한 도메인 수를 유지하면서 동시에 리소스를 다운로드 받았고, 이미지 서버의 경우 적절하게 domain sharding을 이용하였는지에 대해서 예측해 볼 수 있습니다. 물론 domain sharding을 무조건 많이 한다고 성능이 잘 나오는 것은 아니고 네트워크 상황에 따라서 적절히 사용하는 게 좋은 성능을 유지 시킬 수 있는 방법입니다.


[그림11. 11번가의 리소스 사용 현황]


[그림12. Gmarket의 리소스 사용 현황]

[그림13. Amazon의 리소스 사용 현황]

3. 텍스트/이미지 압축
웹 사이트에서 이미지가 차지하는 비율은 대부분 70%가 넘는 상황에서 이미지의 수와 크기는 웹 사이트 성능에 큰 비중을 차지할 수 밖에 없습니다. 이미지의 수를 줄일  수 없다면 이미지의 포맷을 변경하거나 크기를 줄이는 방법으로 성능을 높일 수 있는데, 이미지의 포맷은 브라우저의 호환성 문제로 아무리 좋은 이미지 포맷이 나왔다고 해도 전면적으로 적용하는 것에는 한계가 따를 수 밖에 없습니다. 그렇다면, 현실적으로 최대한 이미지나 텍스트를 압축하여 전송하는 방법을 사용한다면 한정된 네트워크 환경에서 효율적으로 사용할 수가 있습니다.  11번가의 경우 전체 리소스 중에서 이미지가 차지하는 비율이 82.4%였고, 압축률은 48%였습니다. 상대적으로 Gmarket의 경우 이미지가 차지하는 비율은 70.1%였고, 압출률은 53% 정도였습니다. 결과적으로 Gmarket 사이트와 비교해서 11번가 사이트는 이미지가 차지하는 비율이 12.3% 높았고, 전체 이미지에서 압축하여 전송한 이미지의 비율은 5%정도 낮았음을 알 수 있습니다. 물론 본 데이터가 전체 성능에서 차지하는 비율이나 영향을 정확하게 알 수는 없지만 분명한 것은 Gmarket , Amazon  사이트는 네트워크 및 내부 CPU 자원을 효율적으로 사용함으로써 상대적으로 좋은 성능을 보일 수 있었다는 것입니다.

위에서 몇 가지 기준으로 세 사이트의 성능을 비교해보았지만, 각 사이트에서 DOM tree를 언제 구성하고 Render tree를 얼마나 효율적으로 구성하는지도 중요한 성능 분석 관점이고, 3rd party JS 사용이나 브라우저 캐쉬를 얼마나 효율적으로 사용하는지 등에 대해서 다각도로 분석할 필요가 있습니다.

감사합니다.

김홍수 기술전략실

저는 분산시스템, P2P Grid Computing을 전공하였고, SK Planet에서 Push Notification System에 back-end 서버 개발 및 성능최적화 문제를 해결하는 일에 참여를 하였습니다. 현재 Web Performance Engineering 분야에 관심을 가지고 있습니다.

공유하기