Проблеми при оцінці продуктивності браузерів, Різне, Інтернет-технології, статті

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

Схожі статті:


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

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*