커뮤니티토픽게시판

https://github.com/GoogleChromeLabs/quicklink

 

 

구글 크롬 개발팀에서 작년 11월, 오픈소스로 공개한 자바스크립트 라이브러리입니다. 

 

어떤 기능인지를 간단히 요약하자면,,

1) 브라우저가 놀고 있는 시간에 내가 이동할만한 링크들의 데이터를 미리 불러와서 캐싱한다. (브라우저 캐싱) 

2페이지 이동속도가 급격히 향상된다.

 

비슷한 컨셉의 라이브러리가 일전에 아예 없었던 것은 아니지만, idle callback (브라우저 유휴타임 체크) 방식이나  intersection-observer (스크롤 위치에 따라 이벤트를 실행) 방식을 적용한 라이브러리는 최초인 듯 합니다 

 

게다가 압축된 js파일의 용량은 1kb 미만 ㄷㄷ..

물론 ie 등의 환경에서는 폴리필이 필요하지만요. (크롬개발팀에서 만들었으니 크롬 최적화이긴 하겠죠.)

 

작동 원리는 다음과 같습니다. 

1) viewport(현재 사용자가 보고 있는 화면)에 포함된 모든 링크를 미리 감지

(옵션에서 viewport를 특정할 수도 있고, prefetching 우선순위,  url 예외규칙 등을 등록할 수도 있습니다),

 

2) 브라우저가 Idle time(유휴 상태)이 될 때까지 대기,

 

3) 사용자가 느린 인터넷 환경인지, 데이터 절약 모드 중인지 체크

 

4) 1)에서 감지한 링크의 데이터(css,js,이미지 등)를 미리 불러옴(prefetching)

 

만약 위 방법으로 미리 불러온 페이지 안에 이미지가 있었고, 사용자가 그 링크로 이동한다면, 이미지는 이미 disk-cache 상태!

 

사용자의 네트워크 환경이나 컴퓨터 성능이 많이 좋아지다보니, 실시간 프리패칭 + 브라우저 캐싱의 기술까지 연계되다니 놀랍습니다. 

 

그러나 개인적으로 테스트도 해봤을 때, 몇가지 한계를 발견하긴 했습니다.

 

1) 불필요한 요청들..

내가 실제로 지금 이동하지 않을 링크의 데이터까지 여러차례 요청하게 되니, 서버에 부담을 주게됩니다.

사용자 경험(UX)은 향상되지만, 비용 또한 늘어나버리는거지요.

 

2) 정적인 페이지에서만 사용 가능하려나..

위 문제와 연결됩니다만, 로직이 많이 들어가는 여러 페이지를 연달아 prefetching 한다면, 서버는 힘들어할겁니다.  이 상황을 방지하려면 불러오게 되는 주 대상이 완전히 정적인 페이지이거나, 캐싱 설계가 아주 면밀히 되어 있어야할 것 같습니다. 

 

그 때문인지 아직까지는 정적인 페이지를 generate 해주는 Gatsby, Nuxt 등의 프레임워크에서만 응용되고 있는 듯 합니다. 워드프레스에서도 누군가 포팅을 해서 플러그인으로 올려놓았지만, 인기는 그닥인 것 같더군요.. 아무튼 막 적용할 수는 없겠습니다.

 

3) 모바일에서는? 데이터 폭탄

뭐,, 물론 와이파이 환경을 미리 확인하는 방법도 있고, 라이브러리 자체적으로 데이터 절약모드인지 확인해주긴 하지만, 데이터 사용량이 훠얼씬 늘어나게 되는 것도 아직까지는 한계로 봐야겠죠. 

 

xe 에서도 설계만 잘 된다면, 충분히 사용할만합니다. (물론 커뮤니티는 무리..) 

슈퍼캐시 같은 프로그램과 연계된다면 갱신이 많지 않은 사이트에서는 사용할 수 있으려나요?..

 

여튼 전 처음 발견하고 오! 했다가 다시 넣어두었습니다.

그래도 앞으로 지켜보고 연구할만한 가치는 충분할듯 합니다.

  • ?

    근데 이런 기술은 솔직히 좀 빛좋은 개살구란 느낌이 듭니다.
    이유가 뭐냐하면
    1) 어차피 느린 모바일에선 데이터 사용량도 제한되기 때문에 사용못한다.
    2) 어차피 인터넷이 충분히 빠른 나라에선 prefetch로 향상되는 성능은 그다지 체감되지 않는다
    3) prefetch로 향상을 느낄 정도의 인터넷 인프라를 가진 나라에선 prefetch 자체가 부담이다

    또는 트래픽에 대해 종량제로 계산되는 나라에서도 prefetch는 엄청난 부담이다.
    뭐 이런 느낌이랄까요... 물론 인터넷이 충분히 느린 상태에서 prefetch를 나 혼자 쓴다면
    꽤 괜찮을 것 같지만 저건 자바스크립트를 사이트에 박아서 사이트 접속한 모두한테

    적용하겠다는거니.. 

    과연 의도대로 되어줄지 모르겠네요. 트래픽에 대해서 별로 제한을 느껴본 적이 없는

    미국 사람이나 할만한 발상이네요. 한국 사람만 되도 저런 자바스크립트를 자기 사이트에

    박아넣고 싶은 사람은 거의 없을거 같은데요. 유럽/북미 빼고는 트래픽에서 자유로운 곳이

    별로 없는거 같던데 말이죠... 

  • ? profile
    확실히 당장은 정적페이지같이 제한적인 영역 안에서 효율을 발휘할 수 있을 것 같긴합니다.

    브라우저의 성능이 계속 업그레이드되면서 운좋게 구현된 곁다리 기술인 느낌도 들구요. ㅋㅋ

    그렇지만, 클라이언트 단의 유휴자원 이용하여 서버 응답속도를 조금이라도 올릴 수 있다는 접근 방식은 확실히 재밌긴합니다.

    최근엔 ai 데이터 분석 기술과 연계되어 연구도 되고 있다고 하더라구요. 통계적으로 클릭될 확률이 높은 링크를 선별해사 불러온다던가하는 방식이겠죠.

    번외로 https://instant.page/ 같은 라이브러리도 있는데, 접근 방식이 퀵링크와 비슷하고 재밌습니다.

    어떤 링크에 hover나 touchstart 되었을 때 prefetch가 시작 되는 방식이구요. hover와 click 사이에 평균 300ms, touchstart 와 touchend 사이에 평균 90ms 정도의 반응 시간이 소요되는 것을 절약해보자는 취지더군요.
  • profile

    단비아빠님 말씀에 공감하며, 미국과 한국의 인터넷 환경 차이도 감안해야 합니다.
    미국은 아직도 선진국 중에서는 인터넷 속도가 무척 느린 편이고,
    원체 땅덩이가 크니까 핑이 늘어나는 것도 어쩔 수 없습니다.
    그러니까 prefetch처럼 우리가 보기에는 도무지 쓰잘데기없어 보이는 기술이 계속 나오지요.

    한국처럼 랜선, 와이파이, LTE 가리지 않고 모두 수백메가~기가급의 속도가 나오는 나라에서는
    사이트를 구성하는 HTML, CSS, JS 파일들을 다운받는 데 걸리는 시간보다
    각종 스크립트와 라이브러리들을 해석하고 실행하는 데 걸리는 시간이 오히려 더 깁니다.
    XE타운만 해도 HTML 로딩 완료는 0.3초인데 각종 스크립트와 광고 로딩에 2초가 더 걸리네요.

    슈퍼캐시를 쓴다면 HTML 로딩 완료 시간을 0.05초 미만으로 줄일 수도 있으니

    심지어 touchstart/touchend 딜레이 사이의 노이즈만큼도 안 됩니다. (미국이라면 절대 상상 불가! ㅋㅋ)
    물론 구글에서는 자기네 광고 때문에 속도가 느려진다고는 죽어도 인정할 수 없을 거예요.

    미국의 대기업이 밀고 있는 새 기술이라고 무작정 따라해보는 사대주의(?)를 버리고
    우리 인터넷 환경에 맞는 기술을 취사선택하는 지혜가 필요합니다 ㅠㅠ

  • profile profile
    국가별 인터넷 환경에 따라 의미가 달라질 수 있다는 관점은 동의하지만, 새 기술을 따라해보는게 사대주의라는 것은 공감하기 어렵네요.

    그 안의 담겨진 아이디어만으로도 배울만한게 있을 수도 있고, 앞으로 어떤 식으로 개선되어갈지 지켜보는 것도 의미가 있을 수 있죠.
  • profile profile

    연구해 볼 가치는 있지요. 그러나 기술적인 장단점뿐 아니라 구글이라는 기업이 웹이라는 플랫폼과 그것을 사용하는 수십억 명의 사람들을 대하는 태도와, 그 커다란 틀 안에서는 이런 간단한 도구 하나마저도 어떤 의도와 편견이 담겨 있을지 모른다는 점 역시 연구해야겠습니다. 그렇지 않으면 기술을 선도하는 (것처럼 보이는) 자의 논리에 그냥 휩쓸릴 수밖에 없고, 그 위험성을 저는 사대주의라고 부르고 싶네요. 물론 파파즈님이 그렇다는 얘기가 아니라, XE타운에 이런 종류의 툴이 소개될 때마다 비슷한 패턴이 보여서 한 말입니다.

    지난 1~2년 사이 HN 같은 해외 개발자 커뮤니티에서 구글에 대한 인식이 급격히 나빠지고 있습니다. AMP는 웹을 독점하려는 트로이 목마 취급을 당하고 있고, 크롬의 개발 방향에 대해서도 불만 투성이이며, 구글러(구글 직원)에 대한 인식이 동경에서 냉소로 바뀌어 가고 있으며, 구글에서 발표하는 오픈소스 라이브러리 하나하나마저 모두 구글스러운 세계관에 오염되어 있다는 주장이 힘을 얻고 있습니다. 왜 그럴까요? 예전에는 구글 기술을 사용하면 모두에게 도움이 되었지만, 이제는 사용자에게 돌아가는 쥐꼬리만한 혜택에 비해 구글에게 돌아가는 혜택이 너무나 많아 보이기 때문입니다.

    클라이언트의 유휴자원이요? 절대 다수의 사용자가 모바일 기기를 사용하는 시대에, 그건 사용자가 애써 충전한 배터리와 비싼 돈을 주고 구입한 데이터를 의미합니다.

    클릭할 확률이 높은 링크를 AI로 분석한다고요? 그건 사용자의 행동을 분석한 방대한 양의 데이터를 구글에게 갖다바친다는 얘기를 완곡히 표현한 것이지요. 클릭할 확률이라니! 애드센스를 운영하는 구글 입장에서는 수십조원의 가치를 지닌 데이터임에 틀림이 없습니다.

     

    말은 똑바로 해야죠. 이건 페이지 로딩 속도를 0.1초 정도 향상시켜 준다는 명목으로, 사용자의 배터리와 데이터를 무단으로 사용하여 구글이 더 많은 개인정보를 수집할 수 있도록 할 의도로 개발된 라이브러리입니다. 나중에 수십조원의 가치가 있을지도 모르니까, 개인정보 수집하는 기능만 빼고 오픈소스로 풀어서 반응을 살피는 거지요.

  • profile profile

    구글의 오만한 행보와 최근의 평가가 좋지 않다는 사실은 알고 있습니다.

     

    그러나 브라우저 캐싱의 이점을 십분 활용함과 동시에 그동안 잘 활용되지 않았던 자바스크립트 내장함수 requestIdleCallback과 interactionObserver를 재치있게 활용해 낸 1kb 내외의 아주 작은 라이브러리를 리뷰함에 있어서까지, 구글이 이제껏 어떤 횡포를 벌여왔는지, 어떤 꿍꿍이를 가지고 사업을 하는지와 같은 기준을 들이댈 필요는 없다고 생각합니다.

     

    그리고 사용자의 움직임을 예측해서 사용자경험을 향상시킨다는 목표는 웹의 세계에서 매우 일반적인 지향점이죠. 구글이라서 문제라면, 머신러닝의 선두주자들인 페이스북과 아마존은 어떤가요? 페이스북은 그 기여한 바와 행보에 대해 개발자들의 평가는 아주 좋은데, 그렇다면 의심하지 않아도 되는지 궁금합니다. 한편으로 이제껏 구글이 웹 생태계에 기여해온 바도 기억에서 지워야하는지요? 이제 소스코드 하나 보는 것도 참 복잡한 일이겠군요.

     

    참고로 이 라이브러리는 Addy Osmani 라는 한 개발자를 깃헙에서 팔로우한 것을 계기로 알게 되었습니다. 미디엄에서 the cost of javascript 라는 장문의 분석 포스팅을 보고, 그 통찰력에 빠져 활동을 염탐하게 됐었죠. 그 사람의 소속이 구글인지도 이 레포지토리에 들어가보고야 알았고요.

     

    소속을 떠나서 대외적으로 유능한 개발자가 아주 라이트한 기술 노하우를 공개한 것 하나로, 그들은 0.1초의 반응속도를 미끼로 유저의 데이터와 배터리를 무단 사용하고 그 개인정보까지 훔쳐갈 것이다라고 단정적으로 말하시는 것은 다소 과도한 선입견이신 것 같습니다.

  • profile profile
    XE의 지향점이 네이버의 이해관계와 충돌하는 것이 불안하다는 지적이 예전부터 있어 왔지요? 비슷한 맥락의 얘기입니다. 단 한 줄의 코드라도 가치중립적인 기술이란 존재하지 않습니다.

    페이스북과 아마존에 대해서도 구글과 비슷한 지적이 오래 전부터 있어 왔습니다. 페이스북의 라이선스 정책 때문에 React.js 등 페이스북에서 개발한 것은 쓰지 않겠다고 하는 개발자도 있고, 아마존 플랫폼의 lock-in 효과 때문에 피하려고 하는 개발자도 있습니다. 쓰지 말자는 것이 아니라 알고 쓰자는 겁니다. 향후 시장에서의 가치가 너무나 명백한 이런 기술을 리뷰하면서 기술적 호기심에 그친다면 반쪽짜리 리뷰가 됩니다. 이미 비슷한 짓을 많이 해온 기업이 또 그런 짓을 할지도 모른다고 의심하는 것은 선입견이 아니라 합리적인 경계심이라고 생각합니다.

    최근 국내에서 논란이 되고 있는 SNI 차단 문제를 생각해 봐도 마찬가지입니다. 누군가가 그 취약점을 처음 발견했을 때는 어? 이런 것도 있네? 하고 말았겠지만, SNI 정보를 암호화하지 않는 스펙을 작성하는 데 기여했던 클라우드플레어 엔지니어는 한국에서 이것이 어떻게 사용되고 있는지 듣고 공개적으로 사과하기까지 했습니다. 악용될 우려가 있는 기술이라면 처음부터 주의했어야 한다는 점을 이분은 잘 이해하고 있는 것이지요.

    유능한 개발자가 구글 크롬 개발팀 공식 계정이 아닌 개인 계정으로, 개인을 저작권자로 명시하여 공개한 소스라면 인정하겠습니다.^^
  • profile profile
    표현의 강도가 좀 세셔서 길게 반박하는 식의 답글을 달았지만, 지적해주시는 바는 이해 합니다. 어떤 분야에 대해서 공부하든 사회적인 맥락안에서의 통찰도 필요하겠죠. 여하튼 좋은 지적 감사합니다.
  • profile profile
    연관된 이슈들을 최근에 많이 접한 터라 좀 민감했던 것 같습니다. 불쾌감을 드렸다면 죄송합니다. 흥미로운 기법인 것은 사실이예요.^^