한빛출판네트워크

제공 : 한빛 네트워크
저자 : Jenn Webb
역자 : 한순보
원문 : Using Iframes to Address Third-Party Script Issues and Boost Performance

개발자와 써드파티(Third-Party) 스크립트 작성자가 iframe을 사용하는 방법에 대해 SOASTA 최고 아키텍트인 필립 텔리스가 이야기합니다.

다음의 인터뷰에서 SOASTA 최고 아키텍트인 필립 텔리스는 어떻게 iframe을 사용해서 써드파티 스크립트에 대한 성능과 보안 문제를 다루는지, 그리고 이 요소가 어떻게 써드파티 스크립트 소유주가 far-future expires (역자주: 먼 장래에 캐시가 만료되게 하는) 헤더를 이용할 수 있게 해주는지에 대해 이야기합니다.

성능을 향상하기 위해 어떻게 iframe을 사용할 수 있을까요?

필립 텔리스: 전통적으로 iframe은 성능에 좋지 않았습니다. iframe에서 로드한 서브 페이지가 여전히 메인 페이지의 로드를 막습니다. 너무 많은 iframe은 너무 많은 이미지나 스크립트의 경우와 같이 성능을 떨어뜨립니다. iframe에서 문제가 약간 더 심각한데, iframe이 로드하는 페이지들이 각각이 이용할 수 있는 대역폭을 메인 페이지와 경쟁하는 리소스를 로드하기 때문입니다.

이들 모두는 (1) onload 이벤트가 발생하기 전에 페이지에서 iframe을 로드하며 (2) 그것의 src 속성은 다운로드 받아야 하는 리소스를 가리킨다는 것을 가정합니다. 두 조건 중 하나가 일어나는 것을 막는다면, iframe의 성능상 불이익은 없습니다. 그러면 iframe이 완전한 브라우저 윈도우 인스턴스라는 사실의 장점을 이용할 수 있으며, 그곳에서 메인 페이지에 영향을 주지 않고 원하는 것을 아주 잘 실행할 수 있습니다. 이는 페이지의 onload 이벤트를 막거나 캐시를 다시 로드하지 않고 자바스크립트, 이미지, 그리고 CSS와 같은 리소스를 다운로드 받고 캐시해야 할 때 아주 좋습니다.

어떤 시스템에서 감지된 지연 시간을 줄이기 위한 세 가지 방법은 캐시, 병렬화, 그리고 예측하는 것이며, iframe은 메인 페이지에 영향을 주지 않고 세 가지 모두를 가능하게 합니다.

써드파티 스크립트를 이용하는데 어떤 주요 문제가 있고, 어떻게 가장 잘 다루어질 수 있을까요?

필립 텔리스: 써드파티 스크립트는 세 가지 주요 문제가 있습니다.

• 성능 문제- 추가적인 DNS lookup, 새로운 TCP 연결, 그리고 당신의 제어권 밖의 써드파티 서버로의 왕복(roundtrip)으로 추가된 지연 시간에 의해 일어납니다.
  
  
• 보안 문제 - 페이지에 로드된 써드파티 스크립트가 해당 페이지의 모든 것, 그리고 그 페이지와의 모든 사용자 상호작용에 대한 완전한 제어권을 가지기 때문입니다. 과거에 제가 이것에 대해 글을 작성했습니다.
  
  
• 전체 사이트 장애 - 이는 이제 써드파티가 단일 장애점(single point of failure, SPOF)이기 때문입니다. 이것에 대해 패트릭 미난이 훌륭한 글을 썼습니다. 이는 성능 문제의 정말로 특별한 경우지만, 사이트 소유주가 자세를 바로 하고 듣게 할 만큼 중요합니다.

보안 문제는 스크립트를 다른 도메인에서 실행하고 있는 iframe에서 로드하여 다루게 됩니다. 이는 해당 페이지의 어떤 것에도 접근하는 것을 허락하지 않는다는 단점이 있어서, 페이지와 상호작용이 필요한 스크립트에는 맞지 않을 것입니다. postMessage에 기반을 둔 지능적인 API 디자인을 사용하여 이를 우회하는 방법이 있지만, 이는 성능 컨퍼런스의 범위를 벗어납니다.

성능 문제를 다루는 데는 몇 가지 방법이 있습니다. 우리는 써드파티 스크립트를 onload 이후에 비동기적으로 로드할 수 있습니다. 이것은 일반적으로 onload 이벤트 핸들러로부터 호출된 어떤 함수에서, 자바스크립트를 사용하는 스크립트 노드를 생성하는 것을 포함합니다. onload가 발생한 후에 페이지에 추가된 리소스는 (이미 발생했기 때문에) onload를 막지 않을 것입니다. 이 방법은 onload 이벤트가 발생하기 전, 혹은 발생하자마자 페이지에 있어야 하는 스크립트에는 맞지 않을 것입니다. 예를 들어, 부메랑(boomerang) 같은 성능 분석 라이브러리는 페이지에서 onload와 다른 이벤트가 발생하는 때를 측정해야 합니다. 그래서 onload 후에 로드하면 제대로 동작하지 않을 것입니다.

SOASTA에서 사용하는 방식은 스토얀 스테파노프와 Meebo나 Olark에 있는 개발자들과 같이 똑똑한 해커들이 수년간 개선한 생각에 기반을 두고 있습니다. 그들 각자는 잘 동작하는 구현을 가지고 있습니다. 저는 그들의 생각을 기반으로, 저만의 것을 몇 가지 추가하여 여전히 페이지에서 되도록 일찍 스크립트를 로드하는 것을 허용하면서 onload 이벤트를 막지 않고 써드파티 자바스크립트를 로드하는 간단한 스크립트 로더를 내놓았습니다. 이 기술은 src 속성 없이 iframe을 사용합니다. (위의 iframe 요구사항 (2)를 처리하고 있습니다.)

far-future expires 헤더에 관한 문제는 어떻습니까?

필립 텔리스: far-future expires는 페이지 내의 리소스를 브라우저와 중간 프록시가 오랫동안 캐시 하도록 보장하는 가장 좋은 방법의 하나입니다. 그 헤더가 매우 오랫동안 이 리소스는 변하지 않는다고 모든 캐시에 알려서, 항상 로컬에 캐시한 카피를 사용합니다. 이는 지연 시간을 줄이는데 매우 좋습니다. 유일한 더 좋은 방법은 아예 그 리소스를 로드하지 않는 것입니다.

당신의 리소스가 변할 때마다, 당신은 단지 리소스와 브라우저의 URL을 바꾸고, 모든 중간 매개체는 새로운 리소스를 다운로드 받고 캐시할 것입니다. 오래된 리소스는 LRU 또는 유사한 알고리즘이 쫓아낼 때까지 캐시에 머물게 됩니다.

하지만 이것은 써드파티 스크립트 소유주에게 약간의 문제를 일으킵니다. 구글 애널리틱스 팀, 페이스북 라이크 버튼팀, 혹은 SOASTA의 부메랑 팀과 같은 써드파티 스크립트 소유주는 그 스크립트를 페이지에 포함하는 수천 개의 사이트에 대한 제어권을 가지지 않습니다. 그래서 URL 변경이 모든 페이지가 업데이트될 때까지 효과가 없고, 업데이트가 결코 일어나지 않을 수도 있습니다. 최종 결과로 대부분의 써드파티 스크립트를 매우 적은 시간 동안 캐시하는 것입니다. 예를 들면, 구글 애널리틱스 자바스크립트는 단지 12시간만 캐시가 됩니다.

더 나은 한 가지 방법은 캐시된 복사본이 아직 만료되지 않았더라도 원래 서버로부터 그 리소스를 다시 받아야 한다고 어떻게든 브라우저와 중간 매개체에 말하는 것입니다.

iframe은 여기에서도 도움을 줍니다. 이 경우 iframe에 src 속성이 정말 필요하지만, onload 이벤트가 발생한 후에 그것을 로드하며, 이는 위에서의 iframe 요구사항(1)을 처리합니다. iframe이 로드하는 페이지는 브라우저에 캐시를 무시하고 다음 업스트림 프록시 혹은 서버로부터 iframe 내의 모든 리소스를 다시 받으라는 자바스크립트를 가지고 있습니다. 또한, 이는 업스트림 프록시에게 그들의 캐시를 무시하라고 알려주는 헤더를 포함합니다. 이것은 모든 중간 프록시가 잘 동작한다는 가정하에 모든 단계의 캐시를 갱신하도록 도와줍니다. 유감스럽게도, 우리는 잘못 동작하는 몇 개의 프록시 서버를 발견하였습니다. 그래서 이 코드를 실행한 지 1년 후에도 오래된 구식 버전의 부메랑으로부터 들어오는 약 0.1%의 성능 표지(beacon)를 발견할 것입니다.

어떤 것이 최고의 해결 방안인지, 그리고 어떤 부류의 개발자가 그것에서 이익을 가장 많이 얻을까요?

필립 텔리스: 소프트웨어에 관련된 것 대부분에서 최고의 해결책이란 없습니다. 모든 해결책은 사이트 개발자가 하나를 선택하기 전에 고려할 필요가 있는 타협을 합니다. 저는 써드파티 스크립트 작성자이므로, 저와 고객에게 가장 잘 동작하는 해결책은 제 스크립트를 비동기적이며 넌-블로킹(non-blocking) 방식으로 로드하는 것입니다.

로드하기 전에 사이트와 상호작용할 필요가 없는 대부분의 써드파티 위젯에, onload 후에 스크립트를 비동기적으로 로드하는 것은 적은 코드로 구현하는 훨씬 더 간단한 좋은 타협입니다.

예를 들어 금융이나 의료 기록과 같은 것을 다루고 항상 SSL을 사용하는 보안에 관심이 있는 사이트에, 정말로 해결책은 당신이 제어하지 않는 서버에서 아무것도 로드하지 않는 것입니다.

당신 강연에 참석한 이후에 사람들이 어떤 거대한 힘을 가지게 될까요?

필립 텔리스: 써드파티 스크립트 작성자는 스크립트를 far-future expires 헤더를 허용하는 방식으로 만드는 방법을 배울 것입니다. 그리고 고객 사이트를 SPOF(Single point of failure)에 노출하지 않고 그것을 로드할 수 있습니다.

웹사이트 소유자는 어떤 타협이 그들이 참조한다고 표시하는 다양한 써드파티 스크립트를 사용하게 하는지를 확인하는 것을 배울 것입니다. 그리고 써드파티 스크립트 소유자가 적합한 해결책을 제공하지 않으면, 사이트 소유자가 스크립트를 올바른 방향으로 향하게 할 수 있습니다.

게다가, 저는 제가 작성한 것과 같은 써드파티 스크립트를 다루어야 하는 참석자들로부터 많은 좋은 피드백을 받기를 바라고 있습니다.