1. Вимірювання продуктивності браузера
2. Робота служби кешування
3. Розмір зразка
4. Спільне використання каналу
5. Спільне використання ресурсів
6. Взаємодія з серверами
7. ефект спостерігача
8. конфігурація комп'ютера
9. Холодний старт проти теплого
10. Вміст веб-сторінок
11. Дизайн сторінок
12. «Готово»
13. надбудови браузера

Добридень! Мене звуть Крістіан Стоквелл (Christian Stockwell) і я очолюю команду розробників IE, яка відповідає за продуктивність браузера.

Вимірювання загальної продуктивності веб-сайтів і браузерів важливо для багатьох: для користувачів, які порівнюють конкуруючі продукти декількох виробників; для розробників, які оптимізують свої портали, прискорюючи завантаження і скорочуючи час відгуку на запити; авторів браузерів, ретельно стежать за тим, як змінюється продуктивність їх продуктів в залежності від змін, що вносяться в програмний код; і, нарешті, просто для всіх бажаючих, кого цікавить, що розуміється під «продуктивністю веб-сайту».

Вважаю, буде цікаво простежити за дискусією навколо питання продуктивності браузерів, обговорити деякі проблеми, що впливають на результати тестування продуктивності, і прийоми, які ви можете використовувати для таких вимірювань.

Вимірювання продуктивності браузера

Зазвичай для вимірювання продуктивності браузера використовуються спеціальні симуляційні тести. І хоча вони можуть служити в якості корисного інструменту, було б помилкою повністю покладатися на невелику кількість таких тестів, якщо ми хочемо оцінити продуктивність браузера в тому сенсі, в якому цей термін розуміють звичайні користувачі. Ми переконані, що найкращі способи вимірювання продуктивності браузера повинні неодмінно містити сценарії, що відображають реальні ситуації, в яких він використовується. Робота з реальними веб-сайтами дозволяє врахувати ті фактори, які в разі застосування імітаційних тестів обліку не піддаються, і передати цілісне враження про продуктивність. Однак, тестування браузерів на справжніх веб-ресурсах пов'язано з рядом нюансів, і в цій статті обговорюються деякі способи, які ми застосовували для адекватного виміру продуктивності IE, що є невід'ємною частиною нашої роботи по створенню Internet Explorer.

Перш ніж заглибитися в деталі, я хотів би зауважити, що вимірювання продуктивності - досить нетривіальне завдання, як не дивно це звучить. Команда програмістів IE поклала чимало праць, створюючи лабораторію тестів і продуктивності, в якій сотні ПК і ноутбуків щодня прокручували тисячі окремих тестів, звертаючись до величезної кількості серверів у всесвітній павутині, і рідкісний день завершувався без того, щоб народилося кілька нових ідей, як домогтися точності , ясності і достовірності оціночних даних.

Частина проблем оцінки продуктивності викликана величезною кількістю різноманітних дій, для яких використовується браузер. Кожен день користувачі звертаються до широкого діапазону ресурсів - від насиченого мультимедійним вмістом Flickr до спартанського Google. Вони можуть зіткнутися з інтерактивним, насиченим AJAX-скриптами сайтом, як Windows Live Hotmail або сайтом, що містить лише статичний HTML, як, наприклад, Craigslist, а деякі з них стануть використовувати браузер для критично важливих ділових додатків (наприклад, побудованих на його основі систем електронного документообігу. - прим. перекл.).

Продуктивність кожного з цих ресурсів часто залежить від продуктивності окремої підсистеми браузера. Наприклад, завантаження насиченогозображеннями сайту може залежати від швидкості, з якою браузер в змозі завантажувати і розпаковувати зображення. Навпаки, продуктивність простенької сторінки залежить від того, як швидко браузер обробляє стандартний HTML. У наступному випадку для гарної продуктивності насиченого AJAX-скриптами порталу потрібно тісна інтеграція JavaScript, CSS і DOM - і це виявиться більшою мірою важливим, ніж індивідуальна продуктивність кожного з названих компонентів. Коли на чашу ваг кладуть Flash і Silverlight, продуктивність буде залежати від того, наскільки добре вбудовані в браузер відповідні підсистеми управління.

Я думаю, деякі обговорювані тут підходи послужать краще поданням про ту роботу, яку ми проробили для поліпшення продуктивності IE8 і дозволять вам глибше зазирнути за лаштунки процесу розробки. Перш за все, я сподіваюся, що це повідомлення допоможе вам по-новому підійти до процедур оцінки результатів вимірювання продуктивності і ще раз замислитися над тим, що таке продуктивність браузера, а що таке продуктивність веб-сайту.

Робота служби кешування

Всі браузери по суті своєї роботи залежать від пропускної здатності мережі, тому будь-які тести повинні відображати цю реальність для того, щоб можна було адекватно оцінювати продуктивність.

Один з аспектів розвитку структури всесвітньої мережі, який впливає на продуктивність браузера, полягає в тому, як організований процес збереження часто запитуваної контенту на вузлах мережі. Цей процес називається кешуванням.

Що це означає в разі оцінки продуктивності браузера? Наприклад, при зверненні до ресурсу http://www.microsoft.com ваш браузер може послідовно запитувати дані з декількох джерел - з проксі-сервера вашої локальної мережі, з сервера, розташованого до вас найближче або з декількох географічно віддалених серверів.

Для підвищення швидкості завантаження вмісту сторінок і розподілу навантаження по мережі ці сервера можуть зберігати частину завантажуваних вами даних у себе в пам'яті для того, щоб інші користувачі могли швидше отримувати до них доступ. Наприклад, вранці, прийшовши на роботу, ви першим ділом переглядаєте новини на http://www.msnbc.com . Швидше за все, браузер спробує спочатку завантажити запитувану сторінку з проксі-сервера, потім з найближчого до вас сервера корпоративної мережі - перед тим, як звернутися до інших, віддалених від вас ресурсів. Як тільки сторінка завантажиться, ваш робочий проксі-сервер або сервер в локальній мережі може «вирішити» (зрозуміло, в залежності від попередньо зроблених налаштувань) зберегти частину її вмісту. Коли інший користувач через десять хвилин спробує звернутися за тією ж адресою, його комп'ютер спочатку отримає порцію даних, вже збережених на проксі-сервері, замість їх повторного завантаження з віддалених серверів, що, в свою чергу, значно зменшить час завантаження сторінки і призведе користувача в гарний настрій.

У схожому випадку, вимірюючи продуктивність різних браузерів, важливо враховувати вплив процедури кешування. Наприклад, відкривши десяток вкладок з десятком різних веб-сторінок, і потім відкривши цей же десяток вкладок в іншому браузері, можна помилитися, вирішивши, що другий браузер швидше, в той час як різниця в швидкості може бути обумовлена ​​кешуванням даних на сервері провайдера в той момент, коли перший браузер сформував запити.

Досить складно ретельно проконтролювати, як сервери кешують дані, але одним з головних принципів при оцінці продуктивності є умова ніколи не вимірювати параметр один єдиний раз. Якщо ви не ставите завдання визначити саме ефективність кешування, то слід попередньо хоча б раз завантажити сторінки, продуктивність роботи з якими ви прагнете оцінити. Власне, з тих пір, як проксі-сервера навчилися зберігати кеш для кожного з використовуваних браузерів, необхідно відкривати відібрані для оцінки продуктивності сторінки в кожному з призначених для тестування браузерів.

Я виклав принципи роботи системи кешування дуже примітивно. Якщо вам потрібно детальна інформація з цього питання, ви можете звернутися до відповідних ресурсів, включаючи, власне, принципи роботи НТТР-протоколу. Без сумніву, ви проведете незабутню ніч, вивчаючи його специфікації під ковдрою при світлі кишенькового ліхтарика, і на наступній вечірці у вас, нарешті, з'явиться чудова нагода зав'язати невимушену світську бесіду про це.

Розмір зразка

Саме тому, що так багато зовнішніх факторів можуть вплинути на оцінку продуктивності, вирішальне значення має те, які параметри і в якій кількості ви збираєтеся враховувати.

Як я вже говорив, основний принцип оцінки продуктивності - не виміряти який-небудь параметр лише одного разу. Я б розширив цей принцип до «завжди вимірюйте потрібний параметр достатню кількість разів». Існує безліч способів визначити це саме «достатня кількість разів« - наприклад, використовуючи довірчі інтервали, середньоквадратичні відхилення та інші милі статистичні прийоми.

І все ж для багатьох параметрів, які ми використовуємо, цілком достатньо розумного рівня наближення, і в різноманітних складних схемах немає дійсної потреби. Ми в нашій лабораторії прийшли до висновку, що 7-10 повторень певної операції зазвичай вистачає, щоб зібрати необхідні дані і визначити тенденції, але іноді потрібно більше циклів, особливо якщо середовище для тестування обмежено керована.

Коли дані зібрані, необхідно проаналізувати їх для того, щоб зробити висновки. Чи використовуєте ви варіанти середнього арифметичного, гармонійного, геометричного або якісь інші методики, необхідно бути послідовними і повністю уявляти собі схему розгалуження результатів при підведенні підсумків тестування.

Наприклад, давайте подивимося на таблицю пунктів, набраних двома браузерами за підсумками тестів навігації в межах однієї веб-сторінки:

На цьому штучному прикладі добре видно, що, в залежності від того, як ви підводите підсумки тестів, висновки про продуктивність будуть протилежними: при виборі в якості критерію середнього арифметичного браузер А швидше браузера В, а при виборі критеріїв середнього геометричного і гармонійного - все навпаки .

Спільне використання каналу

Той факт, що ви використовуєте мережу не поодинці, а разом з іншими користувачами, може означати, що в якийсь момент ваш браузер раптом без всяких видимих ​​причин уповільнює роботу, і ви помітите, що на виконання тієї ж самої операції йому чомусь то потрібно набагато більше часу.

Одна з переваг роботи на таку велику компанію, як Microsoft полягає в тому, що деякі явища стають зрозумілими і доступними для вимірювання. Наприклад, швидкість завантаження веб-сторінок протягом дня показує, що більшість співробітників компанії починають працювати між 8 і 9 ранку і закінчують між 5 і 6 годинами.

Причина, по якій я можу це стверджувати, в тому, що більшість співробітників Microsoft звертаються до ресурсів мережі більш-менш постійно протягом робочого дня. Переглядаючи MSDN, читаючи документи на порталі Sharepoint або ретельно тестуючи останні гри для приставки Xbox, ми тим самим відтягує на себе ресурси пропускної здатності нашої мережі. Це означає, що, вимірюючи швидкість завантаження сторінки в 9 ранку і 6 вечора, я отримаю більше правдоподібні результати, ніж тоді, коли весь персонал працює в поті чола і розсилає тисячі поштових повідомлень.

Виходячи з того, що існує стільки конфігурації мережі, скільки самих підприємств, досить важко передбачити вплив фактора навантаження на мережу. Щоб уникнути спотворення результатів тестування, я пропоную збирати дані поза годин пік, якщо вам необхідно оцінити продуктивність браузера у виробничому середовищі.

При зборі даних в домашніх умовах необхідно врахувати, що і в цьому випадку ви ділите канал з іншими користувачам, наприклад, членами сім'ї. В цьому випадку тести краще проводити тоді, коли в мережі знаходяться менше користувачів - в робочий час, пізно вночі або дуже рано вранці.

Спільне використання ресурсів

Спільне використання ресурсів додатками на вашому комп'ютері також може вплинути на продуктивність браузера - принаймні так само сильно, як і спільне використання каналу.

Це особливо помітно тоді, коли кілька програм залежать від зовнішніх ресурсів або платформ. Наприклад, деякі антивіруси по-різному вбудовуються в різні браузери, зрозуміло, з невідомої заздалегідь ступенем впливу на продуктивність.

Результати тестування двох браузерів одночасно, «пліч-о-пліч», можуть виявитися зовсім некоректними. Наприклад, платформа Windows має обмеження - можливі лише 10 одночасних вихідних з'єднань; інші запити будуть поставлені в чергу на виконання в міру звільнення ресурсів і можуть, в залежності від необхідного тимчасового інтервалу, завершитися успішно або з помилкою. Такий спосіб тестування означає, що ви, швидше за все, поставите один з браузерів в переважне становище тим, що потім запустити на потрібному кілька мікросекунд пізніше суперника.

Я пропоную розглянути всього два простих прикладу, хоча їх існує безліч. Чи не занадто заглиблюючись у деталі, скажу, що я не рекомендую запускати інші програми, коли ви тестируете продуктивність браузера.

Ви повинні зробити такі обов'язкові кроки для того, щоб уникнути впливу інших програм:

• Закрити всі інші додатки, включаючи ті, що приховані в області повідомлень панелі завдань. Це особливо важливо в разі, якщо якісь із цих додатків використовують мережеві ресурси.
• У командному рядку запустіть наступну команду для обмеження активності комп'ютера в процесі тестування:% windir% \\ system32 \ rundll32.exe advapi32.dll, ProcessIdleTasks

Взаємодія з серверами

Крім впливу спільного використання ресурсів і каналу, на продуктивність може досить суттєво вплинути механізм роботи серверів, до яких ви звертаєтеся.

Одним з основоположних принципів при проведенні ваших тестів повинно стати забезпечення рівних умов на всіх етапах і для всіх аспектів тестування. Для визначення впливу процедур кешування необхідно, щоб сервера, до яких ви звертаєтеся, накопичили певну кількість даних; для тестування мережі необхідно, щоб середовище виконання тестів була ізольована від впливу зовнішніх ресурсів.

Прикладом конструктивних особливостей програми, здатних вплинути на процес тестування, може служити програма управління банківським рахунком. З міркувань безпеки, така програма отримує доступ до даних тільки після того, як пройшла авторизація користувача. Мета тестування полягає в порівнянні поведінки двох або більше браузерів на веб-сторінці банку, що містить таку програму. Для цього необхідно, щоб програма була як би в рівних умовах по відношенню до тестованим браузерам. Зазвичай такого роду програми не дозволяють користувачам входити в систему одночасно з двох або більше сесій: при повторній авторизації попередня сесія завершується (користувач деавторізуется). Якщо попередній стан веб-додатки не буде скинуто перед початком тестування іншого браузера, з додатком може знадобитися додатковий час для обробки повторного запиту, закриття попередньої сесії і запуску нової.

Всі ці процедури значно впливають на процес тестування, і характерні не тільки для онлайнових банківських додатків, так що вам слід спробувати виключити їх як фактор. У загальному випадку, ви повинні дуже добре уявляти собі особливості поведінки тих веб-сторінок, за допомогою яких ви тестируете браузери.

ефект спостерігача

У багатьох областях сам факт спостереження змінює характер поведінки спостережуваних об'єктів. Цей феномен отримав назву «Ефекту спостерігача» .

Ви можете використовувати будь-який набір бібліотек для спрощення завдання тестування деяких сценаріїв використання браузера. Ці набори зазвичай орієнтовані на розробників і технічно просунутих користувачів. Прикладом такого набору бібліотек є Jiffy .

Як і в будь-якому іншому випадку, коли результати потрапляють в залежність від способу вимірювання, необхідно ретельно оцінити і в міру можливості обмежити коливання продуктивності, викликані типами бібліотек, які ви використовуєте.

До речі кажучи, команда розробників IE використовує механізм Event Tracing for Windows (ETW), який веде протокол наші внутрішні тести і забезпечує масштабується протоколювання, що дозволяє нам знизити вплив «ефекту спостерігача» до прийнятного мінімуму.

конфігурація комп'ютера

Двох однакових комп'ютерів, як і двох однакових людей, не буває.

Як уже говорив, наша лабораторія має значною кількістю ПК для цілодобового проведення тестів. Щоб забезпечити гнучкість ресурсів, на ранньому етапі розробки IE8 ми спробували зібрати кілька «однакових» комп'ютерів, які могли б підміняти один одного в процесі збору даних для того, щоб забезпечити безперервність формування їх масиву. Ці ПК мали послідовні серійні номери і збиралися на одному і тому ж конвеєрі, і всі їхні компоненти були «однаковими». Незважаючи на ці зусилля, дані, що збираються з їх допомогою, настільки значно відрізнялися, що ми відмовилися від ідеї безпосередньо порівнювати результати, отримані на двох різних машинах.

Тому не слід дивуватися тому, що я пропоную тестувати всі браузери на одному і тому ж ПК, - хіба що вас цікавить різниця в продуктивності на різних платформах.

Холодний старт проти теплого

Час, необхідний для запуску браузера, може залежати від багатьох факторів, і деякі з них абсолютно не відносяться до якості самої програми.

Як і у випадку з кешуванням, час запуску браузера залежить від зовнішніх умов, особливо якщо ви запускає браузер перший раз. Перш ніж можна буде приступити до серфінгу, необхідно, щоб відповідні модулі браузера завантажилися в оперативну пам'ять - процес, що вимагає часу. Коли ви вперше завантажуєте браузер, важко визначити, яка кількість необхідного коду вже знаходиться в пам'яті. Особливо важко це у випадку з IE, оскільки багато його компоненти спільно використовуються іншими додатками.

Щоб зібрати найбільш несуперечливі дані, відкрийте і закрийте кожен браузер як мінімум один раз перед тим, як почнете тестування. Якщо всі інші програми закриті, це дасть вашій операційній системі можливість завантажити потрібні компоненти в пам'ять і забезпечить послідовність і точність результатів тестування. Це також створить рівні умови конкуренції для різних браузерів, особливо в світлі існування таких функцій операційної системи, як Superfetch , Яка в іншому випадку забезпечить переваги «коханому» браузеру.

Вміст веб-сторінок

Веб-сайти постійно змінюються. На жаль, це відбувається і тоді, коли вам необхідно тестувати продуктивність браузера.

У нашій лабораторії весь вміст веб сторінок, призначених для тестування браузера, попередньо кешируєтся на весь період вимірювання продуктивності. Таким чином, ми можемо гарантувати, що браузер завжди отримує один і той же контент для кожної ітерації тесту. В реальності такого, звичайно ж, не відбувається.

Сучасні сайти оновлюють вміст дуже часто. На Facebook або MySpace ви можете отримати два абсолютно різних результату між двома клацаннями кнопки миші по одній і тій же посиланням: за цей час хтось додав запис або коментар, завантажив картинку або ще якимось чином змінив вміст ресурсу. На багатьох сайтах йде постійна ротація рекламних банерів, тим самим гарантуючи, що будь-які два входи на сайт будуть відрізнятися один від одного.

Поза лабораторного простору контролювати такий характер змін практично неможливо. Зрозуміло, існують певні підходи, наприклад, ви можете використовувати інструмент типу Fiddler для маніпулювання контентом, який отримує браузер. На жаль, подібні методи з великою ймовірністю можуть привести до того, що замість очікуваного результату ви не досягнете. Рішення полягає в тому, щоб слідувати тим же рекомендаціям, які я давав вище, торкаючись питання розміру зразків для тестування, і якщо ви виявите, що важкий рекламний банер з'являється щоразу після певної кількості завантажень сторінки, то буде справедливо повторити вимірювання для забезпечення надійних результатів .

Дизайн сторінок

Зміна на веб-сторінці залежить не тільки від користувача, але і від веб-майстра, який створив радикально відрізняються версії свого ресурсу для різних браузерів.

Один з трюків, які використовуються в разі, коли необхідно забезпечити доставку одного і того ж вмісту для ваших тестів - сайти, які підлаштовуються під тип браузера. У більшості випадків слід ігнорувати те, що для різних браузерів використовується різний програмний код. Це дає вам можливість реально оцінити враження користувачів при відвідуванні таких ресурсів.

Однак, в деяких випадках, в залежності від того, яким браузером ви користуєтеся, змінюються і функціональні можливості сторінки, причому настільки, що пряме порівняння браузерів стає неможливим. Наприклад, я зараз розглядаю скаргу одного з наших користувачів, який повідомив, що завантаження якогось сайту в IE8 займає в кілька разів більше часу, ніж у конкуруючого браузера. В ході перевірки я виявив, що сайт використовує набір бібліотек, що забезпечує набагато більш широку функціональність для IE, ніж для інших браузерів. На щастя, функціональність ресурсу в цілому не дуже залежала від властивостей саме цього набору бібліотек, і веб-майстри злегка модифікували спосіб реалізації набору так, щоб їх сайт завантажувався в різних браузерах приблизно з однаковою швидкістю.

У цьому прикладі додаткова функціональність, що надається певним набором бібліотек, практично не була задіяна, і тому при модифікації веб-сайту його творці обійшлися "малою кров'ю". Однак, існують ресурси, які насправді пропонують різну функціональність в залежності від типу браузера. Оцінка продуктивності на базі таких сайтів - непросте завдання, але я зазвичай уникаю прямого порівняння браузерів при їх відвідуванні, оскільки мова в цьому випадку йде більше про погляди та вподобання дизайнерів, ніж про продуктивність браузерів як таких.

Визначити, які сайти поводяться подібним чином, не завжди просто, і в цьому випадку веб-дизайнер має перевагу перед «звичайним» тестером. Вони повинні використовувати профайлери, отладчики і інші наявні в їхньому розпорядженні інструменти для того, щоб визначити ділянки контенту, на яких різні браузери поводяться істотно відрізняється чином.

Рядовим тестерам і користувачам без глибоких технічних знань не слід оцінювати продуктивність браузерів на прикладах сайтів, занадто по-різному подаються в різних браузерах, оскільки їм складно провести межу між продуктивністю сайту і особливостями його дизайну.

«Готово»

Чи можете ви точно визначити, що означає - «веб-сторінка завантажена»? Як бути у випадку, якщо вона містить складні AJAX-сценарії?

Проблема при оцінці продуктивності полягає у визначенні того, що, власне, означає напис «готове» в інформаційному рядку браузера при завантаженні сторінки. Проблема ще й у тому, що деякі сторінки ускладнюються і розростаються неузгоджено один з одним. Деякі веб-програмісти використовують маркер «Завантажено» як індикатор того, що браузер завершив розмітку вмісту сторінки для подальшого завантаження. Цей маркер, на жаль, інтерпретується різними браузерами по-різному.

У себе в групі ми можемо використовувати ряд подій, що реєструються в процесі завантаження, для вимірювання продуктивності по сайтам. У зв'язку з тим, що ця реєстрація характерна тільки для IE, вона, на жаль, не може користуватися для коректного відображення статистики ефективності завантажень для інших браузерів. І, хоча існують такі межплатформенному набори бібліотек як Jiffy и Episodes , Покликані допомогти розробникам визначити момент завершення сценаріїв завантаження сторінок, однак маркери, які вони пропонують, все ще недостатньо широко поширені.

Крім індикаторів, які працюють на рівні програмного коду, деякі використовують, наприклад, прогрес-бар браузера, текстові поля та інші загальноприйняті елементи графічного інтерфейсу. Як правило, поведінка цих елементів ніяк не регламентоване, і веб-програмісти можуть на свій розсуд змінювати його, визначаючи, коли (якщо взагалі!) Відображати їх на екрані.

Стикаються з такими ситуаціями тестерам і користувачам я раджу застосовувати ті методи наближення, які ґрунтуються на індикаторі прогрес-бару з тим, щоб спостерігати поведінку цього індикатора в процесі завантаження сторінок. Наприклад, ви вимірюєте швидкість первинного завантаження певної сторінки, і в той же час взаємодієте з її вмістом. Якщо сторінка все ще нібито завантажується, індикатор показує «в прогресі», але при цьому ви можете взаємодіяти з контентом, ви можете вирішити не звертати уваги на індикатор і орієнтуватися на візуальні параметри оцінки, завантажилася сторінка до кінця чи ні. З іншого боку, індикатора прогрес-бару може виявитися досить для попередньої оцінки швидкості завантаження в різних браузерах. Однак якщо швидкість, з якою сторінка завантажується в дійсності, не відповідає індикації в прогрес-барі, буде досить важко зрозуміти, до якої міри в цьому випадку можна довіряти результатам вимірів продуктивності.

надбудови браузера

Використання надбудов означає, що з цього моменту ви вимірюєте продуктивність не тільки самого браузера.

Як я вже писав в квітні минулого року, надбудови можуть істотно впливати на продуктивність. Згідно з даними, отриманими з джерел в Microsoft, IE використовується в сукупності з дюжинами надбудов, і я вважаю, мої колеги з Mozilla можуть підтвердити те ж саме щодо їх власного браузера.

Будь-яка з цих надбудов може проявляти довільну активність всередині браузера. Ілюстрацією впливу може служити наступна ситуація: користувачі, які відстоюють свої переваги щодо певного браузера, раптово виявляють, що будь-яка альтернативна програма працює швидше лише тому, що їх улюблений праузер перевантажений надбудовами і доповненнями, а альтернативний являє собою чисту, без всякого «сміття», програму. Наприклад, користувач обтяженого декількома доповненнями Firefox може змінити його на IE, побачивши, що той працює швидше, а в цей час користувач IE переходить на Firefox за тією ж схемою, виходячи з тих же причин. Тут немає ніякого протиріччя - такі приклади лише демонструють вирішальний вплив надбудов.

Тому в нашій лабораторії ми тестуємо як «чисті» конфігурації, так і з найбільш часто встановлюються доповненнями. Для блокування надбудов в IE8 необхідно викликати пункт Manage add-ons з меню Tools. У діалоговому вікні виберіть All Add-ons і послідовно заблокуйте всі надбудови зі списку. Якщо ви дружите з командним рядком, можете виконати команду iexplore.exe -extoff для запуску IE без доповнень.

Оскільки більшість програмістів вважає за краще не скорочувати обсяг коду, щоб тим самим гарантувати очікуване поведінка надбудов після оновлень, важливо, особливо під час використання пробних версій, мати можливість відключити будь-який з некоректно поводяться доповнень.

Я розумію, що, ймовірно, вже втомив вас, але все ж сподіваюся, розповідь про деяких використовуваних нами прийомах оцінки продуктивності IE допоможе вам пристосувати їх для ваших власних потреб. Розуміння того, як ми думаємо, допоможе вам розібратися і в тому, як здійснюється процес оцінки продуктивності і чому. І, нарешті, я сподіваюся, що дозволив вам частково задовольнити цікавість з приводу того, що відбувається за лаштунками підготовки до офіційного релізу IE8.

Крістіан Стоквелл (Christian Stockwell),
програмний менеджер Internet Explorer

джерело: http://blogs.msdn.com/ieru

всі коментарі