Internet Explorer 9 베타 검토: Microsoft가 브라우저를 재창조했습니다.

오늘 샌프란시스코에서 Microsoft는 공식적으로 Internet Explorer 9을 공개하고 일반 대중에게 제공할 예정입니다. 이는 의심의 여지 없이 Microsoft가 지금까지 수행한 브라우저 릴리스 중 가장 야심찬 것이며 베타 레이블에도 불구하고 인상적으로 세련된 제품입니다.

Internet Explorer 9 베타 자세히 살펴보기(스크린샷)

IE9의 토대는 비밀이 아닙니다. Microsoft는 지난 가을부터 웹 표준을 준수하고 HTML5를 수용하려는 확고한 노력에 대해 이야기해 왔습니다. 또한 이전 릴리스에 비해 IE9의 성능을 향상시키기 위한 노력을 자세히 설명했습니다. 개발자와 IT 전문가는 지난 6개월 동안 4번의 공개 플랫폼 미리 보기를 통해 호환성 문제와 벤치마크 성능을 해결할 수 있었습니다. 그러나 이번 베타는 Microsoft가 새로운 브라우저의 사용자 인터페이스를 공개적으로 선보이고 Windows 고객에게 매일 사용할 수 있는 제품을 제공한 최초의 사례입니다.

나는 이번 초 Internet Explorer 사업부 총책임자인 Dean Hachamovitch와 함께 자리를 잡았습니다. 한 달 동안 IE9 인터페이스를 처음 살펴보고 Microsoft의 목표와 그 목표에 대해 논의합니다. 경쟁. 그 회의 이후 저는 기본 데스크톱 및 노트북 컴퓨터를 포함한 여러 PC에서 IE9 베타를 광범위하게 사용해 왔습니다. 그 경험을 바탕으로 저는 귀하가 묻는 질문에 대한 몇 가지 예비 답변을 갖고 있습니다. 충분히 빠른가요? 충분히 호환되나요? 다른 브라우저, 처음에는 Firefox로, 최근에는 Google Chrome으로 전환한 이전 IE 사용자를 다시 불러올 수 있을 만큼 멋지나요? 그리고 이 반짝이는 새 브라우저가 훼손된 Internet Explorer 브랜드를 재활성화할 수 있을까요?

여기 내 보고서가 있습니다.

Microsoft는 Internet Explorer 9을 통해 브라우저를 사라지게 만들려고 노력하고 있습니다.

물론 문자 그대로도 아니고 완전히도 아닙니다. PC 사용자가 다른 어떤 작업보다 웹에서 더 많은 시간을 보내고 앱이 점점 더 많이 사용되는 세상에서 온라인으로 이동하면서 HTML 마크업을 빠르고 정확하게 렌더링하고 스크립트를 실행할 수 있는 능력이 더 중요합니다. 항상. 그러나 Microsoft에 따르면 웹 페이지 렌더링이 브랜드 브라우저에서 수행되어야 한다는 개념은 구식 사고라고 합니다.

주로 개발자를 대상으로 한 이전의 네 가지 플랫폼 미리 보기에서 Microsoft는 이미 IE9에서 제공하는 기능 중 일부를 선보였습니다. 최신 웹과의 호환성에 대한 끊임없는 강조와 함께 하드웨어 가속 및 향상된 JavaScript 엔진 덕분에 성능이 향상되었습니다. 표준.

누락된 부분은 Microsoft가 오늘 공개한 이전의 일급 비밀 IE9 인터페이스입니다. Internet Explorer 사업부 총괄 책임자인 Dean Hachamovitch에게 새로운 UI 디자인의 원동력이 무엇인지 물었을 때 그는 지침을 설명했습니다. 디자인 원칙에 대한 질문: "사이트가 빛나도록 브라우저를 어떻게 조용하게 할 수 있습니까?" 답은 아래 스크린샷에 있습니다(전체 내용을 보려면 클릭하세요). 크기):

무엇이 다른가요? 해당 IE9 페이지를 IE8 및 대부분의 다른 브라우저에 표시된 동일한 페이지와 비교하십시오.

가장 분명한 차이점은 당신이 ~하지 않다 화면에서 확인하세요. 우선 작업 표시줄 버튼의 로고(익숙한 파란색 E) 외에는 브랜딩이 없습니다. 제목 표시줄에는 텍스트나 로고가 없으며 "Internet Explorer"라고 비명을 지르거나 속삭이는 것도 없습니다. 좋다 Windows 탐색기, 브라우저의 주요 역할은 눈에 띄지 않게 콘텐츠를 호스팅하는 프레임이 되는 것입니다. 가능한.

브라우저의 가장 필수적인 인터페이스 요소를 제외한 모든 요소는 기본적으로 IE9에서 제거되거나 숨겨졌습니다. 결과적으로, 여러분이 보고 있는 사이트의 콘텐츠는 로고, 도구 모음, 메뉴 및 버튼과 싸울 필요가 없습니다. 오른쪽 상단에 검색창이 없습니다. 명령 모음과 즐겨찾기 모음이 숨겨집니다. 하단에는 상태 표시줄이 없습니다. 새로 고침 및 중지 버튼은 색상 대신 회색으로 표시되며 오른쪽 상단에 있는 세 개의 회색 버튼은 각각 홈 페이지, 즐겨찾기 및 도구에 대한 액세스를 제공합니다. (모든 버튼 위에 마우스 포인터를 놓으면 색상이 변경됩니다.) 열려 있는 페이지의 탭은 더 작고, 디자인이 더 깔끔하며, 주소 표시줄 오른쪽에 있는 밴드에 있습니다. 이전 제품보다 더 크고 밝은 유일한 요소는 왼쪽 상단 모서리에 있는 파란색 뒤로 버튼입니다.

IE9 사용자 인터페이스의 핵심에 대해 더 자세히 설명하겠습니다. 이 보고서의 3페이지, 그러나 여기서는 몇 가지 높은 수준의 세부정보를 주목할 가치가 있습니다. "브라우저를 조용히"하기 위해 경고와 대화 상자가 더 이상 나타나지 않으며 사용자의 주의가 필요합니다. 대신 알림과 작업 버튼이 창 하단의 눈에 띄지 않는 표시줄에 표시되어 편리하게 해당 기능을 처리할 수 있습니다. IE8에서는 이러한 경고 및 알림(예: 차단된 팝업 창)이 현재 작업을 중단하는 대화 상자로 나타납니다. 다운로드도 같은 방식입니다. IE9에서는 이러한 모든 중단 사항이 창 하단에 나타나므로 탐색을 계속하는 동안 결정을 미루거나 경고를 완전히 무시할 수 있습니다. 여기에 표시된 알림은 간단하지만 효과적인 다운로드 관리자와 연결되어 있습니다.

IE9의 탭 관리에는 탭을 떼어 새 창으로 끌거나 디스플레이 측면에 도킹하는 기능을 포함하여 몇 가지 새로운 기능이 추가되었습니다.

Google Chrome과 마찬가지로 IE9는 주소 표시줄과 검색 상자를 Microsoft가 Private OneBox라고 부르는 기능으로 결합합니다. 당연하게도 Bing은 기본 검색 엔진이며(해당 설정을 변경할 수 있음) Bing을 켜면 주소 표시줄은 기록, 즐겨찾기 및 실시간 검색 결과를 정렬하는 훌륭한 작업을 수행합니다. 입력할 때:

IE9의 가장 흥미로운 혁신이자 과거 IE9를 테스트하면서 나에게 가장 큰 영향을 준 혁신입니다. 2주 후에는 고정된 바로가기라는 새로운 기능을 사용하여 즐겨찾는 웹사이트를 마치 마치 애플리케이션.

IE8에는 이미 개선된 보안 기능 외에도 수많은 보안 개선 사항이 있습니다. 제가 검토한 베타 버전에서는 이러한 기능 중 일부(서버측 코드에 의존함)가 아직 활성화되지 않았습니다. 이에 대해서는 향후 게시물에서 다루겠습니다.

아, 그리고 IE9는 매우 빠르게 느껴집니다.

새 브라우저를 시험해 보기 전에 몇 가지 주의 사항이 있습니다. 아직 베타 버전이며 최종 릴리스에서도 일부 웹 사이트에서는 호환성 문제가 발생할 수 있습니다. (4페이지의 토론에서 이러한 문제가 불가피한 이유를 설명합니다.) IE9은 Windows 7에서 가장 잘 작동하며 Windows Vista 서비스 팩 2에 설치할 수 있습니다. 여러 가지 이유로 인해 Windows XP와 호환되지 않으며 이러한 상황은 지금부터 최종 릴리스까지 바뀌지 않을 것입니다.

프롤로그를 마치고 본격적으로 들어가 보겠습니다.

2 쪽: 웹사이트를 앱으로 취급

페이지 3: 새로운 사용자 인터페이스

페이지 4: 성능

페이지 5: IE에는 무엇이 준비되어 있나요?

2페이지: 웹사이트를 앱으로 취급 -->

이전 페이지

웹사이트를 앱으로 취급

IE9의 가장 유용한 혁신은 Microsoft가 고정된 단축키. 이 기능의 기본 개념은 간단합니다. IE9 탭에서 웹사이트를 열고 해당 아이콘을 드래그하면 됩니다. 주소 표시줄에서(또는 탭 자체를 드래그하여) 작업 표시줄로 이동하면 프로그램처럼 고정됩니다. 그 결과 일반 IE 아이콘 대신 사이트의 파비콘을 사용하는 바로가기가 탄생했습니다. 실제 작동 모습은 다음과 같습니다.

Windows 7 작업 표시줄에서 고정된 웹 사이트 바로 가기는 앱 바로 가기와 똑같아 보입니다. 사이트 개발자가 전체 크기 파비콘을 업로드한 경우 고정된 바로가기는 로컬에 설치된 프로그램과 똑같아 보입니다. 여기에 표시된 작업 표시줄 섹션에는 표준 앱과 고정된 바로가기가 혼합되어 있습니다. 하단 행 오른쪽에 있는 전체 크기 Amazon 아이콘을 확인하세요. 그 위에 있는 ZDNet 아이콘은 작은 파비콘을 사용하는 사이트를 방문하면 어떤 일이 일어나는지 보여줍니다.

철학적으로 이러한 특수 단축키는 웹 콘텐츠를 두 가지 유형으로 나누는 방법을 나타냅니다. 기본 탐색의 경우 사이트를 즐겨찾기로 저장할 수 있습니다. 이는 다음에서 열리는 일반적인 바로가기입니다. 관련 작업 표시줄의 IE 아이콘으로 식별되는 탭이 있는 일반 Internet Explorer 창 단추. 그러나 작업 표시줄에 고정한 사이트는 다르게 동작합니다. 두 가지 시각적 차이가 즉각적으로 드러납니다. 먼저 뒤로, 앞으로 버튼이 약간 오른쪽으로 이동하고, 새로 비워진 공간에 해당 사이트의 파비콘이 나타납니다. 둘째, Windows 7 작업 표시줄의 프로그램 버튼이 마우스 포인터가 그 위로 지나갈 때 아이콘의 색상을 선택하는 것처럼 이러한 탐색 버튼은 파비콘의 주요 색상을 선택합니다. 이 스크린샷은 상단의 페이지가 표준 IE 창에서 열린 것과 아래의 페이지가 고정된 바로가기에서 시작된 차이점을 보여줍니다.

IE9에서는 사용자 정의 색상과 왼쪽 상단 모서리에 있는 아이콘이 현재 위치를 파악하는 데 도움이 되는 즉각적인 시각적 피드백을 제공합니다. 커다란 빨간색 ZDNet 아이콘과 밝은 빨간색 탐색 버튼은 놓치기 어렵습니다. 하지만 해당 아이콘은 단순한 장식이 아닙니다. 아이콘을 클릭하면 해당 바로가기에 고정된 URL로 돌아갑니다. 오른쪽의 홈 버튼을 사용할 수 없습니다. 사이트 아이콘은 해당 고정된 사이트에 대한 사용자 정의 홈 버튼이 됩니다. 개발자는 Windows 7 작업 표시줄에 고정될 때 자체 사용자 지정 점프 목록을 사용하도록 사이트를 정의할 수 있습니다. 저는 이러한 점프 목록을 "야생"에서 본 적이 없습니다. 따라서 이 예는 Microsoft 모형에서 가져온 것입니다.

고정된 바로가기를 사용할 때 브라우저 인터페이스의 나머지 부분은 그대로 유지됩니다. 즐겨찾기 및 설정 메뉴는 여전히 할당된 위치에 있습니다. 고정된 사이트와 동일한 창에서 새 탭을 열 수도 있는데, 이는 처음에 제가 우려했던 기능입니다. 특정 사이트를 홍보하는 목적은 단순히 추가 탭 그룹을 임의로 만드는 것이 아니라 해당 사이트를 돋보이게 하는 것입니다. 그러나 실제로는 이 디자인이 유용하고 심지어 중독성이 있다는 것을 알았습니다. 일반적인 활동을 위해 3~4개의 관련 탭 그룹을 만드는 데는 오랜 시간이 걸리지 않았습니다. 예를 들어, 내 블로그의 홈 ​​페이지가 작업 표시줄에 고정되어 있고 일반적으로 사이트에 대한 Google Analytics 및 WordPress 대시보드를 엽니다. 이 세 개의 탭을 단일 그룹으로 유지하면 작업 표시줄에서 ZDNet 아이콘을 클릭하고 이전에 수십 개의 열린 탭에 흩어져 있던 작업 중 하나를 쉽게 찾을 수 있습니다.

Google Chrome의 고급 사용자라면 IE9의 고정된 바로가기와 Chrome의 애플리케이션 바로가기 사이의 유사점을 즉시 발견하게 될 것입니다. 두 브라우저 모두 사이트 아이콘과 함께 저장되는 URL에 대한 바로가기를 저장할 수 있습니다. 해당 아이콘을 클릭하면 관련 브라우저가 별도의 전용 프로세스와 함께 자체 창에서 열립니다. 아이디어는 해당 웹 페이지에 작업 표시줄에 고유한 위치와 고유한 아이콘을 제공하여 열려 있는 모든 브라우저 탭을 검색하는 대신 신속하게 찾을 수 있도록 하는 것입니다. 저는 Mail 및 Reader와 같은 Google 서비스에 Chrome 애플리케이션 바로가기를 사용해 왔습니다.

그렇다면 IE9의 고정된 단축키는 Chrome의 애플리케이션 단축키를 복사한 것일까요? 표면적 유사성을 벗어나면 몇 가지 중요한 차이점이 있습니다. Chrome에서 해당 바로가기는 탭 표시기가 없는 단일 페이지를 엽니다. 따라서 Gmail을 바로가기에 할당하고 한 번의 클릭으로 열 수 있지만 해당 Chrome 창에서 새 탭을 열 수는 없습니다. 링크를 클릭하면 현재 페이지를 바꾸거나 새 창에서 열립니다. 실제로 탭 표시줄도 없고 뒤로 버튼도 없습니다(단, 마우스 오른쪽 버튼을 클릭하고 바로가기 메뉴에서 뒤로를 선택할 수 있음). 설정 메뉴도 사라졌습니다. 결과적으로 Google 앱 바로가기는 IE9에 고정된 단일 페이지의 바로가기와 동일하게 작동합니다. 마치 앱인 것처럼 실행하려는 경우: 웹 기반 메일 서비스, WordPress 대시보드, 기업 문. 하지만 해당 창 내에서 탭을 그룹화하는 IE9의 기능은 내 사용 시나리오에 있어서 이점을 제공합니다.

IE9 베타에는 일반 Internet Explorer 창과 고정된 바로가기를 사용하여 여는 창 사이에 한 가지 중요한 기술적 차이가 있습니다. IE용으로 설치된 모든 추가 기능은 고정된 사이트 창에서 사용할 수 없습니다. 일상적인 사용에서는 내가 의존하는 몇 가지 IE 추가 기능을 사용할 수 없기 때문에 짜증나는 일이었습니다. IESpell을 사용하여 블로그 게시물의 오타를 확인할 수 있지만 WordPress 편집기가 고정된 사이트 창에서 실행 중인 경우에는 확인할 수 없습니다. 그리고 빼놓을 수 없는 LastPass 비밀번호 관리자 일반 IE9 창에서는 작동하지만 고정된 사이트 창에서는 사용할 수 없습니다. Microsoft는 이러한 동작이 의도적으로 설계된 것이며 모든 추가 기능(가속기는 제외)에 영향을 미칠 것이라고 밝혔습니다. 나는 일부 애드온 제작자에게 이 문제를 어떻게 해결할 것인지 물어볼 계획입니다.

페이지 3: 새로운 사용자 인터페이스 -->

이전 페이지

새로운 사용자 인터페이스

IE9의 작동 방식을 정의하는 많은 주요 결정은 말 그대로 숫자에 따라 이루어졌습니다. Microsoft는 사전 동의된 고객 경험 개선 프로그램을 통해 수많은 실제 데이터를 보유하고 있습니다. 수천만 개의 IE의 수억 세션에서 가져온 Internet Explorer 8용 사용자. 해당 데이터를 마이닝하면 기획자는 Windows 사용자가 탐색할 때 무엇을 하는지(하지 않는지) 파악할 수 있습니다. 현장과 공식적인 사용성 연구실에서 가설과 기능 개선을 테스트할 수 있습니다. 테스트.

Microsoft는 그 숫자 중 일부를 나와 공유했습니다. 일부 잘 확립된 고급 사용자 기능이 대중들 사이에서 얼마나 인기가 없는지 정확히 알면 충격적입니다. 예를 들어, 나는 열려 있는 모든 탭의 축소판을 표시하는 IE의 빠른 탭 기능을 좋아하지만 이로 인해 나는 엘리트 그룹에 속합니다. 전체 IE 사용자 중 1.7%만이 이 기능을 사용합니다. 이와 대조적으로 IE 사용자의 73%는 탭을 찾기 위해 Windows 7 작업 표시줄 버튼 위에 마우스를 올렸고, 59%는 작업 표시줄 축소판 미리 보기 중 하나에 있는 닫기 버튼을 사용하여 창을 닫았습니다.

이러한 정신에서 IE9 디자이너가 수행한 가장 큰 변경 사항 중 하나는 명령 모음을 숨기고 이를 축소된 설정 메뉴로 대체한 것입니다.

Alt 키를 탭하면 기본 전체 메뉴(페이지, 안전, 도구 및 도움말)를 계속 사용할 수 있습니다. 이렇게 단축된 메뉴를 사용하면 대부분의 일반적인 작업에 해당 메뉴가 필요하지 않게 됩니다.

일반적인 작업을 식별하고 개선하는 데이터 기반 접근 방식을 사용하면 IE9에 새로운 고급 사용자 기능이 거의 없다는 것을 이해할 수 있습니다. 실제로 앱을 극단적으로 추진하고 싶다면 Microsoft가 너무 멀리 나갔다고 판단할 수도 있습니다. "브라우저를 조용하게 합니다." 처음에는 빠른 탭 바로가기(Ctrl+Q)가 작동하지 않는다는 사실에 놀랐습니다. 일하다. Microsoft와 몇 차례 이메일을 교환한 후 이제 빠른 탭 보기가 기본적으로 비활성화되어 있다는 사실을 알게 되었습니다. 이를 활성화하려면 인터넷 옵션 대화 상자를 자세히 살펴보아야 합니다. (다음 편에서 방법을 설명하겠습니다.)

저는 Microsoft의 IE 제품 관리 이사인 Roger Capriotti에게 왜 빠른 탭을 숨기기로 결정했는지 설명해달라고 요청했습니다. 그는 Aero가 올바른 열린 탭을 찾고 전환하는 훨씬 더 나은 방법을 제공한다는 사실 때문에 "의도적으로 빠른 탭 기능을 '강등'시켰다"고 설명했습니다. Aero Peek를 사용하면 실제로 전체 페이지를 볼 수 있으므로 썸네일 비주얼에 의존할 필요가 없습니다.”라고 그는 덧붙였습니다. “아직 베타 버전이므로 계속해서 노력할 것입니다. 계속 피드백을 받습니다." 하지만 최근 경험에 비추어 볼 때 피드백이 사용자의 근본적인 변화를 가져올 것으로 기대하지는 않습니다. 상호 작용. 이번 베타 버전에서 볼 수 있는 내용은 최종 릴리스에서 볼 수 있는 내용과 매우 유사할 것입니다.

Microsoft의 수치에 따르면 즐겨찾기(일명 북마크)는 한때 인기가 있었지만 사용이 감소한 또 다른 기능을 나타냅니다. IE 사용자 중 18%만이 즐겨찾기 표시줄을 클릭한 적이 있으며 100명 중 1명만이 즐겨찾기 표시줄에 폴더를 만든 적이 있습니다. 결과? 즐겨찾기 표시줄과 명령 모음은 IE9에 숨겨져 있으며 이를 다시 활성화하려면 몇 가지 추가 과정을 거쳐야 합니다. 위치 변경(화면 오른쪽 끝으로 이동)을 제외하면 즐겨찾기 메뉴의 디자인은 기본적으로 IE8과 동일합니다.

Microsoft의 데이터 마이닝에 따르면 대부분의 경우 이전에 이미 방문한 사이트를 탐색하게 됩니다. 예를 들어, IE8에서 새 탭을 열 때 주소 표시줄에 입력을 시작하고 자동 완성을 사용할 확률은 47%입니다. 브라우저 기록이나 즐겨찾기에 저장된 URL을 다시 방문하는 경우 IE8에서와 마찬가지로 자동 완성 기능이 매우 잘 작동합니다.

새 탭을 열 때 기본적으로 나타나는 새로운 정보: 탭 페이지를 사용하면 가장 자주 방문한 사이트로 더욱 쉽게 돌아갈 수 있습니다.

여기에서도 고급 사용자는 고급 사용자 정의 옵션이 부족하여 비명을지를 수 있습니다. 디자인 관점에서 볼 때 해당 페이지는 매우 훌륭합니다. 깨끗하고 일관되며 읽기 쉽습니다. 각 페이지의 히스토그램 스타일 막대의 색상은 사이트의 파비콘을 샘플링하여 선택되었으며 각 페이지의 인기 정도를 나타냅니다. (알고리즘이 이 상위 10개 목록에 대한 사이트를 어떻게 선택하는지 정확히 모르겠지만, 테스트 결과 며칠 후 자주 사용하는 경우 내가 가장 자주 방문하는 사이트를 확실하게 선택합니다.) 그러나 목록은 엄격하게 기계적. X를 클릭하여 탭을 제거하고 IE9 목록의 다음 항목을 상위 10개에 추가할 수 있지만 탭 순서를 변경할 수 없으며 여기에 탭을 고정할 수도 없습니다.

IE8의 혁신 중 하나인 탭 그룹은 IE9에서도 변경되지 않았습니다. 링크를 Ctrl 키를 누른 채 클릭하면(또는 마우스 오른쪽 버튼을 클릭하고 새 탭에서 열기 선택) 새 탭이 현재 탭 오른쪽에 열립니다. 탭과 새로 열린 탭 모두 탭으로 식별되는 공유된 고유 색상을 선택합니다. 그룹. 색상으로 구분된 그룹에 새 탭을 추가하여 해당 프로세스를 계속할 수 있습니다. 즐겨찾기 메뉴에서 폴더를 마우스 오른쪽 버튼으로 클릭하고 탭 그룹에서 열기를 선택하면 다음 폴더의 모든 바로가기가 열립니다. 색상으로 구분된 그룹에 있는 해당 폴더를 클릭하고 탭을 마우스 오른쪽 버튼으로 클릭하여 그룹에서 제거하거나 전체를 닫을 수 있습니다. 그룹. 하지만 IE9의 탭 그룹으로 여전히 할 수 없는 한 가지는 파란색, 보라색, 주황색 탭 선택 항목을 그룹으로 저장하는 것입니다. Microsoft는 IE 사용자 중 15%만이 이 기능을 사용한 적이 있다고 밝혔습니다. 이는 실망스럽기는 하지만 이해할 수 있는 디자인 결정입니다.

다른 브라우저 커뮤니티에서는 많은 고급 사용자 기능이 추가 기능이나 확장을 통해 처리될 수 있습니다. 예를 들어 Firefox에는 탭 조정 확장 기능이 부족하지 않습니다. 그러나 IE는 무료 추가 기능 작성자를 위한 놀이터가 된 적이 없기 때문에 IE9 출시 직후 수많은 강력한 도구가 마술처럼 나타날 가능성은 실제로 희박합니다. (개발자 여러분, 이를 어려운 문제로 생각하고 제가 틀렸다는 것을 증명해 주십시오.) 제가 테스트한 IE8 추가 기능은 이전 페이지에서 언급한 고정된 사이트의 결함을 제외하고는 어떤 번거로움도 없이 작동했습니다.

페이지 4: 성능 -->

이전 페이지

성능

웹 브라우저의 성능을 측정하는 것은 관련된 변수의 수가 너무 많기 때문에 까다롭습니다. 종종 밀리초 단위로 측정되는 페이지 로드 시간으로 인해 네트워크 성능에 순간적인 결함이 있어도 결과가 왜곡되고 테스트 데이터를 신뢰할 수 없게 될 수 있습니다. 종종 다른 서버에서 로드되는 이미지, 광고 및 위젯의 존재로 인해 결과가 왜곡될 수도 있습니다. 예를 들어, 한 테스트 세션에서 매우 인기 있는 기술 사이트의 페이지는 10페이지 이상이 소요되는 것으로 나타났습니다. 제3자 광고 문제로 인해 어떤 브라우저를 사용하든 완전히 로드되는 데 몇 초밖에 걸리지 않습니다. 섬기는 사람. 그리고 종종 특정 브라우저에 최적화된 페이지 자체의 마크업이 있습니다.

보다 정교한 테스트 플랫폼을 갖춘 다른 출판물에서는 이러한 장애물을 극복하고 IE9 성능에 대한 확실한 벤치마크를 생성하려고 노력할 것이라고 확신합니다. 이 게시물에서는 주관적인 경험만 설명하고 널리 사용되는 몇 가지 독립적인 벤치마크를 언급할 수 있습니다.

주관적인 부분을 한 문장으로 설명할 수 있습니다. 이런 젠장, 이 브라우저는 빠릅니다. 대부분의 페이지에서 로드 시간이 빠르고 탐색이 빨랐으며 스톱워치를 사용해도 IE9과 경쟁 브라우저 간의 차이점을 측정하는 것이 불가능했습니다. IE9의 일부 페이지에서는 호환성 문제로 인한 성능 문제가 나타났습니다. 이 주제는 다음 페이지의 요약에서 더 자세히 설명합니다.

IE9의 가장 큰 성능 향상은 하드웨어 가속 지원에서 비롯됩니다. IE9은 Windows Vista SP2 및 Windows 7에서만 실행되므로 일부 렌더링을 오프로드하도록 조정할 수 있습니다. 다른 하드웨어보다 원시 처리 능력이 더 뛰어난 최신 그래픽 하드웨어에 작업을 수행하는 경우가 많습니다. PC. (마이크로소프트는 현재 브라우저가 PC 성능의 10%만 사용한다고 주장하는데, 이는 다소 과장된 표현일 수 있다.) 그러나 일상적인 사용에서 하드웨어 가속은 실제로 텍스트, 이미지 및 렌더링에 차이를 만듭니다. 제도법. 결과적으로 Microsoft는 맹렬하게 따라잡으려고 노력하는 다른 브라우저들보다 앞서 익숙하지 않은 위치에 놓이게 되었습니다. 저는 2010년 9월에 출시되었으며 하드웨어 가속을 지원하는 최초의 Mozilla 제품인 Firefox 4 베타 5와 함께 IE9 베타를 테스트했습니다. 또한 렌더링에 GPU를 사용하지 않는 Google Chrome 6의 최신 베타 버전에 대해서도 테스트했습니다. (구글은 이 기능을 Chrome 7 로드맵에 포함시킨 것으로 알려졌습니다.)

놀랄 것도 없이 가장 큰 성능 차이는 Microsoft의 자체 그래픽 중심 테스트에서 명백히 드러났습니다. IE 테스트 드라이브 대지. 새로운 HTML5 Canvas 태그를 사용하는 FishIE Tank 예제에서 세 브라우저를 비교한 방법은 다음과 같습니다.

가상 탱크에서 애니메이션 물고기의 수를 늘려도 IE9의 프레임 속도는 높게 유지되었습니다. 여러 모니터에 걸쳐 창을 이동하고 Aero Snap을 사용하여 디스플레이 측면에 도킹한 경우에도 성능이 원활하고 결함 없이 유지되었습니다. 이와 대조적으로 Firefox 4는 짧은 순간 동안 높은 프레임 속도를 유지할 수 있었지만 브라우저 프레임을 이동하면 성능이 급락하고 심지어 오랜 기간 동안 디스플레이가 정지되기도 했습니다. Firefox를 사용하면 가장 까다로운 설정(물고기 500마리와 1000마리)을 선택했을 때 프레임 속도가 급격하게 떨어졌습니다. 물론 크롬은 하드웨어 지원이 부족해 부당한 불이익을 당했다. 다른 프로그램이나 Windows 자체에 부정적인 영향을 주지 않고 화면 주위를 부드럽게 이동했지만 프레임 속도는 경쟁사보다 훨씬 낮았습니다.

보다 독립적인 성능 테스트를 위해 YouTube의 HTML5 채널에 대해 세 가지 브라우저를 모두 활성화하고 720p 및 1080p 해상도에서 소수의 고화질 비디오를 재생해 보았습니다. 세 가지 브라우저 모두 창 내에서 전체 화면 해상도로 뛰어난 성능을 발휘했습니다. IE9 및 Chrome 6은 브라우저 창에서 탭을 떼어내서 자체 창으로 드래그하는 경우에도 완전한 충실도 재생을 유지할 수 있었습니다. 반면에 Firefox 4는 이 테스트에 실패하여 새 창에 도착했을 때 재생을 중지하고 클립을 다시 시작했습니다.

IE9의 또 다른 새로운 성능 향상 구성 요소는 새로운 Chakra JavaScript 엔진입니다. 다중 프로세서 코어를 갖추고 있으며 이미 플랫폼 미리보기를 통해 광범위하게 벤치마킹되었습니다. 릴리스. Microsoft는 인상적인 개선 사항을 보여주는 여러 차트를 배포했습니다. 대부분의 차트에는 IE9보다 거의 10배 느리고 차트 규모가 크게 왜곡되는 음울한 IE8 점수가 포함되어 있습니다. 좀 더 공정하게 만들기 위해 IE8 결과를 버리고 IE9, Firefox 및 Chrome의 최신 베타 릴리스만 사용하여 SunSpider 벤치마크를 실행했습니다. 결과는 다음과 같습니다.

각 브라우저 간의 차이는 약 1/10초에 불과하며, 그 복합 결과에는 수십 개의 복잡한 작업이 포함됩니다. 독립 JSB벤치마크 테스트에서는 비슷한 결과가 나왔습니다. IE9 베타는 최신 Firefox 4 베타보다 21% 더 빠르지만 Google Chrome 6의 최신 테스트 빌드보다 29% 느립니다. 결론? JavaScript 성능은 최신 브라우저 간의 중요한 차별화 요소가 아니며 IE9는 이 점수에서 모든 Webkit 기반 브라우저와 함께 자체적으로 사용할 수 있습니다. (어제 첫 번째 리뷰를 예상하여 IE 블로그에 다음과 같은 흥미로운 토론이 게시되었습니다. JavaScript 벤치마크가 실제로 측정하는 것.)

이전 IE 버전에서는 브라우저 추가 기능으로 인해 속도 저하가 자주 발생했습니다. IE8은 효과적이지만 찾기 어렵고 단순한 필사자에게는 너무 어려운 추가 기능 관리자를 도입했습니다. IE9에서는 여전히 사용할 수 있지만 더욱 깔끔한 조정 키트로 보완되었습니다. IE9을 잠시 실행하면 화면 하단에 알림이 표시됩니다. 이를 따르기로 선택하면 이 간단한 목록으로 이동하여 문제가 있는 추가 기능을 식별하고 필요한 경우 비활성화할 수 있습니다.

내 경험을 토대로 Google Chrome이 계속해서 많은 성능 테스트에서 승리할 것으로 예상합니다. 그러나 IE9은 그 격차를 인상적으로 좁혔습니다. 하드웨어 가속이 관련된 작업에서는 전반적으로 Firefox보다 빠르고 Chrome보다 빠릅니다. 경쟁사들이 IE9를 따라잡거나 통과하더라도(아마 그럴 것입니다), 성능 차이가 크지 않을 것입니다.

페이지 5: IE9의 미래 -->

이전 페이지

HTML5, 호환성, IE9의 미래

Internet Explorer 9은 Microsoft의 과거와의 거의 완전한 단절을 나타냅니다. 이는 Microsoft가 만든 브라우저 중 가장 표준을 준수하는 브라우저이며 CSS3 및 HTML5 표준을 거의 완벽하게 지원합니다. Microsoft는 똑똑하고 미래 지향적인 개발자가 웹 페이지에 대한 마크업을 한 번만 작성하면 IE9에서도 최신 브라우저에서와 마찬가지로 동일하게 작동할 것이라고 확신할 수 있다고 주장합니다.

그것이 바로 이론이다. 현실은 좀 더 복잡합니다. 표준 호환 브라우저를 구축하려는 Microsoft의 진정으로 인상적인 노력에도 불구하고 그들은 안장을 밟고 있습니다. 수천, 어쩌면 수백만 개의 웹페이지가 손상되거나 부적절하게 표시될 수 있습니다. IE9. IE9 베타를 테스트하는 동안 이러한 문제가 반복적으로 발생했습니다. 예를 들어 다음은 Time.com 페이지의 일부입니다.

Facebook 및 Twitter 아이콘은 위의 위젯과 같은 행에 있어야 하지만 해당 페이지를 디자인한 사람은 소수의 작은 아이콘을 사용하여 이를 코딩했습니다. 이전 IE 버전의 레이아웃 버그를 수정하기 위해 설계된 비틀기이며 향후 버전의 IE에서는 이러한 버그가 필요하지 않을 가능성을 고려하지 않았습니다. 수정.

ZDNet.com에서 버튼이 제대로 작동하지 않고 여러 이미지를 회전해야 하지만 대신 단일 이미지에 고정되는 JavaScript 기반 그래픽이 포함된 유사한 버그를 발견했습니다.

심지어 Microsoft 관리 사이트에서 잘못 렌더링되거나 지원되는 Internet Explorer 버전을 사용해야 한다고 불평하는 여러 페이지를 발견하기도 했습니다. 이 같은:

다행히 IE9에는 이전 버전과 동일한 호환성 보기 옵션이 있으므로 주소 표시줄의 "깨진 페이지" 아이콘을 클릭하여 이와 같은 문제를 해결하는 것이 상대적으로 쉽습니다. 디자이너는 항상 IE7 호환 모드에서 표시되도록 페이지를 코딩할 수도 있지만 이러한 전략은 이러한 해킹 없이 페이지를 볼 수 있어야 하는 IE9 사용자를 속이는 것입니다.

물론 IE9에는 여전히 버그가 있습니다. 이것이 결국 베타 버전인 이유입니다. 일부 인기 있는 JavaScript 라이브러리는 새 브라우저에서 제대로 작동하도록 조정해야 합니다. 그리고 아직 발전 중인 CSS3 및 HTML5 표준에 대한 다양한 해석이 있어 문제가 정리될 때까지 웹 개발자에게 사소한 골칫거리가 될 것입니다. IE9, Firefox 및 Chrome의 별도 코드 블록을 확인하세요. 이러한 moz- 접두어(Safari의 webkit-)는 정확히 상호 운용성을 구성하는 요소는 아닙니다.

이러한 변화는 시간이 지나면서 일어날 것입니다. 이 베타의 광범위한 가용성은 올바른 방향으로의 큰 추진을 나타냅니다. IE9의 최종 릴리스는 훨씬 더 큰 추진력을 의미할 것입니다. Microsoft는 지금까지 많은 버그를 수정할 것이며, 전부는 아니지만 일부 웹 개발자는 IE9를 수용하도록 코드를 업데이트할 것입니다. 고맙게도 수정 사항은 사소합니다. 브라우저에 표준 모드에서 페이지를 렌더링하도록 지시하는 코드 줄만큼 간단합니다. 다행히도 IE6과 IE7에 필요한 엄청난 해킹은 포함되지 않습니다. 개발자들은 "한 번 불타면 두 번 부끄러워진다"고 생각하는 것에 대해 변명할 수 있지만 그런 시절은 지나갔습니다.

그렇다면 IE9 베타를 설치해야 할까요? 모든 베타 소프트웨어와 마찬가지로 주의를 기울이는 것이 좋습니다. 제 생각에는 놀랍도록 세련된 릴리스이지만 아직은 베타 버전입니다. 베타 소프트웨어에 익숙하지 않고 결과를 이해하지 않는 한 설치하지 않는 것이 좋습니다. 모든 Internet Explorer 업데이트와 마찬가지로 이는 일방통행입니다. Windows 7에 이 베타를 설치하는 경우 백업을 복원하지 않는 한 이전 버전의 Internet Explorer로 돌아갈 수 없습니다. 업데이트: 프로그램 제어판의 설치된 업데이트 섹션에 나타나는 IE9를 실제로 제거할 수 있습니다. 그러나 플랫폼 프리뷰와 달리 IE9는 기존 IE 버전과 나란히 설치할 수 없습니다.<

아이러니하게도 이 베타 버전의 가장 좋은 후보자는 Windows 7을 사용하지만 다른 브라우저를 선호하여 Internet Explorer를 포기한 사람들입니다. 이 시나리오에서는 Firefox, Chrome 또는 Opera를 계속 사용하고 IE9를 백업 브라우저로 사용할 수 있습니다. 기본 브라우저 선택에 영향을 주지 않고 IE9에서 일부 사이트를 실행하기 위해 고정된 사이트 바로가기를 만들 수도 있습니다. 이상적인 테스트 시나리오입니다.

개인적으로 저는 IE9의 성능과 유용성 향상이 거의 거부할 수 없다고 생각합니다. 사소한 렌더링 문제와 일부 사이트와의 비호환성 문제보다 훨씬 더 큽니다. 당신이 IE8을 만족스럽게 사용하고 있다면 당신도 나만큼 IE9에 깊은 인상을 받을 것이라고 예상합니다.

업데이트: 베타 코드는 이제 Microsoft 웹사이트에서 다운로드 가능(29개 언어 및 몇 가지 추가 표시 언어).