파이어폭스, 크롬 NPAPI 기반 플러그인 지원 점차적 중단.

2014년인 올해 크롬과 파이어폭스가 Netscape Plug-in API (NPAPI) 을 점차적으로 중단해 나갈것이라고 발표했습니다.
크롬은 Java로 지원중인 플러그인도 2014년까지 지원한다고 합니다.

[지원 중단 내용 요약]
요즘 나온 브라우저들은 더 빠르고, 더 안전하며, 예전보다 할 수 있는 것도 더 다양합니다. 그러나 90년대적 개발된 NPAPI의 아키텍처는 너무 오래되어 이제 이는 브라우저를 느리게 하고, 다운시키고, 보안 사고까지 일으키는 주범이 되었습니다. 이 때문에 이제 Chrome은 내년엔 NPAPI 지원을 중단하려 합니다.

모질라에 이어 구글도 크롬 브라우저에서  넷스케이프 플러그인 애플리케이션 프로그래밍 인터페이스(NPAPI) 기반 플러그인을 지원을 중단한다. 대부분의 크롬 플러그인은 NPAPI 기술을 사용한다고 한다.

23일(현지시간) 미국 씨넷에 따르면 구글은 2014년 1월부터 NPAPI 지원 중단에 들어간다. NPAPI 차단 작업은 이미 시작됐다. 23일부터 개발자들은 크롬 웹스토어에서 NPAPI 기반 플러그인을 포함하고 있는 익스텐션이나 애플리케이션을 제공할 수 없다.

NPAPI는 90년대 나온 기술이지만 지금도 대부분의 브라우저 플러그인 개발에 사용되는 아키텍처다. 구글은 NPAPI 기반 플러그인은 브라우저에서 영상과 음성을 지원하는 기반을 제공했지만 지금은 필요치 않은 기술이라고 지적했다. 지금은 오히려 충돌, 보안 사고, 복잡한 코드의 원인이라는 것이다.

구글은 표준 기반 웹 플랫폼이 NPAPI를 대체할 수 있을 것으로 보고 있다.
대부분의 사용자들은 이같은 변화를 알아채지 못할 것이란게 구글 설명. 크롬 사용자의 5% 이상이 쓰는 NPAPI 플러그인은 실버라이트, 유니티, 구글어스, 자바, 구글토크, 페이스북 비디오 6개 뿐이다. 구글은 이들 플러그인에 대해서는 잠정적으로 화이트리스트로 분류해 지원할 계획이다. 그러나 2014년 연말까지는 지원이 중단된다.

현재 NPAPI를 사용해 앱이나 익스텐션을 만드는 개발자들은 2014년 5월까지만 앱을 업데이트할 수 있다. 이후에는 웹스토어 홈페이지에서 이들 앱은 사라진다. 2014년 9월에는 검색 결과에서도 제외된다.

NPAPI 대안이 필요한 개발자들을 상대로 구글은 네이티브 클라이언트(NaCI), 패키지드 앱스네이티브 메세징 API레거시 브라우저 지원 등을 추천하고 있다.

[최근 1년간 브라우저 점유율 (테스크탑, 테블릿 분야만 조회)]
IE 점유율이 높은것은 아시아권이지만, 전세계적으로 점유율 1위는 크롬 입니다.
브라우저 점유율

[관련기사]

 

다국어 사이트를 위한 SEO 처리. (구글 검색엔진 최적화)

아래 방법은 검색엔진이 당신의 다국어 사이트를 잘 검색하기 위해서 권장하는 방법들 입니다.

[페에지 언어가 명확한지 확인]
  • Google에서는 페이지에 표시된 콘텐츠만 사용하여 언어를 결정합니다.
    lang 속성 같은 코드 수준 언어 정보는 사용되지 않습니다.
[각 언어 버전을 쉽게 찾을 수 있는지 확인]
  • 쿠키를 사용하여 페이지의 번역을 표시하면 안된다.
  • 사용자가 인식하는 언어를 기반으로 자동 리디렉션을 피하세요.
    리디렉션은 사용자 및 검색엔진이 사이트의 모든 버전을 보지 못하게 차단합니다.
    예) apple.com 검색시 영문, apple.co.kr 접속시 -> apple.com/kr 로 리디렉션
  • 페이지의 각 언어 버전을 상호 링크하는 방법을 고려해 보세요.
[URL 선택을 신중하게 고려]
  • Google에서는 페이지의 콘텐츠를 사용하여 언어를 결정하지만, URL은 실제 사용자에게 페이지의 콘텐츠에 대한 유용한 정보를 제공합니다.
  • URL은 fr을 하위 도메인 또는 하위 디렉토리로 사용하여 프랑스어 콘텐츠를 명확하게 나타냅니다.
    – http://example.ca/fr/vélo-de-montagne.html 또는 http://fr.example.ca/vélo-de-montagne.html 권장.
    – 파라메터 방식은 비추.
[URL 구조]
다른 지역으로 손쉽게 사이트의 일부를 지역 타겟팅할 수 있는 URL 구조 사용을 고려해 보세요

URL 구조
장점
단점
ccTLD
example.ie
  • 명확한 지역 타겟팅
  • 서버 위치가 중요하지 않음
  • 간편한 사이트 분리
  • 많은 비용 필요(가용성이 제한될 수 있음)
  • 추가 인프라 필요
  • 경우에 따라 ccTLD 요구사항이 엄격함
gTLD를 포함하는 하위 도메인
de.example.com
  • 간편한 설정
  • 웹마스터 도구 지역 타게팅 사용 가능
  • 다양한 서버 위치 허용
  • 간편한 사이트 분리
  • 사용자가 URL만으로 지역 타겟팅을 인식하지 못할 수 있음(예: ‘de’가 언어인지 국가인지 확실하지 않음)
gTLD를 포함하는 하위 디렉토리
example.com/de/
  • 간편한 설정
  • 웹마스터 도구 지역 타게팅 사용 가능
  • 저렴한 유지 관리비(동일 호스트)
  • 사용자가 URL만으로 지역 타겟팅을 인식하지 못할 수도 있음
  • 단일 서버 위치
  • 사이트의 분리가 어려움
URL 매개변수 site.com?loc=de
  • 권장하지 않음
  • URL 기반 세분화가 어려움
  • 사용자가 URL만으로 지역 타겟팅을 인식하지 못할 수도 있음
  • 웹마스터 도구에서 지역 타겟팅 불가능

지역 타겟팅이 항상 정확하지는 않으므로 사이트의 ‘잘못된’ 버전을 방문하는 사용자를 고려해야 합니다.이러한 방법 중 하나로 사용자가 지역 또는 언어를 선택할 수 있도록 모든 페이지에 링크를 표시할 수 있습니다.

[중복 콘텐츠 및 국가별 사이트]

다른 지역에 대한 콘텐츠를 다른 언어로 제공하는 웹사이트는 같거나 유사하지만 다른 URL에서 사용할 수 있는 콘텐츠를 만드는 경우가 있습니다. 이는 콘텐츠가 서로 다른 국가의 다른 사용자를 위한 경우 대개 문제가 되지 않습니다. 각각 다른 사용자 그룹에 대해 고유한 콘텐츠를 제공하는 것이 좋지만 불가능한 경우도 있습니다. robots.txt 파일 크롤링을 허용하지 않거나 “noindex” robots 메타 태그를 사용하면 일반적으로 중복을 ‘숨길’ 필요가 없습니다. 하지만 다른 URL에서 동일한 사용자에게 동일한 콘텐츠를 제공하는 경우(예: example.de/ 및 example.com/de/가 독일에 있는 사용자를 위해 독일어 콘텐츠를 표시하는 경우), 선호 버전 및 리디렉션을 선택하거나 rel=canonical 링크 요소를 적절하게 사용해야 합니다. 또한 rel-alternate-hreflang에 대한 가이드라인에 따라 검색자에게 올바른 언어 또는 지역 URL을 제공해야 합니다.

[결론]
보편적으로 수행되는 방법은 아래와 같습니다.
  • example.com/de/ 형태로 다국어 사이트 URL을 구성한다.
  • rel-alternate-hreflang 해당 컨텐츠 언어를 설정해준다.
  • 한 언어에 제한된 크롤링을 막기 위해 쿠키를 사용하여 페이지의 번역을 표시하시 하면 안되고,
    URL또는 사용자가 언어를 선택하도록 한다.
[참고]