Аналізуємо завантаження веб-сторінки

1. Що впливає на завантаження сторінки?
2. Моделюємо паралельні запити
3. Вимірюємо ефективну ширину каналу користувачів
4. Поради щодо зменшення часу завантаження
5. Висновок
6. Читати далі

Наша взаимовыгодная связь https://banwar.org/

Нижче переклад статті "Optimizing Page Load Time" , В якій автор математично розраховує оптимальний розмір файлів для ефективної передачі при веб-запитах, розглядає деякі прикладні питання оптимізації завантаження сторінки з урахуванням особливостей браузерів, а також дає кілька розгорнутих і цінних порад. Мої коментарі далі курсивом.

Існує поширена думка, що швидко завантажує сторінки позитивно впливає на враження користувача (improve the user experience). В останні роки багато сайтів почали використовувати для цієї мети технологію AJAX , Щоб зменшити час очікування (при завантаженні даних). Замість того, що запитувати з сервера нову сторінку повністю під час кожного кліка, браузер часто можна або поміняти вид самої сторінки (відобразивши або приховавши будь-які блоки), або довантажити невелику порцію HTML-, XML- або JavaScript-коду і внести зміни на існуючу сторінку. У будь-якому випадку, це значно зменшує час, що проходить між кліком користувача і закінченням візуалізації браузером нового змісту.

Що впливає на завантаження сторінки?

Однак, для більшості сайтів, завантаження сторінки зачіпає десятки зовнішніх об'єктів, основний час завантаження витрачається на різні HTTP-запити картинок, JavaScript-файлів і файлів стилів. AJAX, можливо, допоможе в даній ситуації, але прискорення або видалення цих HTTP-запитів може принести набагато більше користі, хоча на даний момент немає єдиної думки (a common body of knowledge), як саме це слід робити.

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

Я б відзначив кілька цікавих фактів:

• В IE, Firefox і Safari, за замовчуванням, вимкнена техніка HTTP-конвеєра ( HTTP pipelining ); Opera є єдиним браузером, де вона включена. Відсутність конвеєра при обробці запитів означає, що після кожної відповіді на запит його з'єднання звільняється перш, ніж відправляти новий запит. (Не слід плутати конвеєрну обробку з Connection: keep-alive, коли браузер може використовувати одне з'єднання з сервером, щоб завантажувати через нього досить велика кількість ресурсів. У разі конвеєра браузер може послати кілька GET-запитів в одному з'єднанні, не чекаючи відповіді від сервера . Сервер в такому випадку повинен відповісти на всі запити послідовно.) Це тягне додаткові затримки на проходження запиту туди-назад, що, в загальному випадку, приблизно дорівнює часу ping'а (перенесеному до дозволеному кількості одночасних сполуки Іненю). Якщо ж на сервері немає елементів підтримки активних HTTP-з'єднань (HTTP keep-alives), то це спричинить ще одне триступеневе TCP «рукостискання», яке, в кращому випадку, подвоює затримку.
• За замовчуванням, в IE можна встановити тільки два зовнішніх з'єднання на один хост при запиті на сервер, що підтримує HTTP / 1.1, або всього 8 вихідних з'єднань. У Firefox'е діють ті ж самі обмеження. Використання про 4 хостів замість одного може забезпечити більшу кількість одночасних з'єднань (IP-адреса в такому випадку не грає ролі: всі хости можуть вказувати на одну адресу.)
• У більшості DSL- або виділених Інтернет-з'єднань несиметрична смуга пропускання, вона варіюється від 1,5Мб вхідного / 128Кб вихідного, 6Мб вхідного / 512Кб вихідного і т.д. Ставлення входить до вихідного каналу, в основному, знаходяться в межах від 5: 1 до 20: 1. Це означає для ваших користувачів, що відправка запиту займає стільки ж часу, як і прийняття відповіді, який в 5 ... 20 разів більше самого запиту. Середній запит займає близько 500 байтів, тому найбільше впливу відчувають об'єкти, які менше, ніж, може бути 2,5 ... 10кб. Це означає, що доставка невеликих об'єктів може істотно обмежити швидкість завантаження сторінки в силу обмеження на вихідний канал, як це не дивно.

Моделюємо паралельні запити

На основі заявлених передумов я приблизно змоделював ефективну ширину каналу для користувачів, враховуючи деякі мережеві особливості при завантаженні об'єктів різних розмірів. Передбачалося, що кожен HTTP-запит займає 500 байтів і що HTTP-відповідь містить додатково до розміру запитаного об'єкта ще 500 байтів заголовків. Це найбільш проста модель, яка розглядає тільки обмеження на канал і його асиметрію, але не враховує затримки на відкриття TCP-з'єднання при першому запиті для активного (keep-alive) з'єднання, які, однак, сходять нанівець при великій кількості об'єктів, переданих за один раз. Слід також зазначити, то розглядається найкраща нагода, який не включає інші обмеження, наприклад, «повільний старт» (slow-start) TCP, втрату пакетів і т.д. Отримані результати досить цікаві, щоб запропонувати кілька шляхів для подальшого дослідження, проте, не можуть жодним чином розглядатися як заміна експериментів, проведених за допомогою реальних браузерів.

Щоб виявити ефект від активних сполук і введення декількох хостів, я змоделював користувача з інтернет-з'єднанням з 1,5Мб входять / 384кБ виходить каналом, що знаходиться на відстані 100 мс без втрати пакетів. Це дуже грубо наближає середнє ADSL-з'єднання на іншій стороні США від ваших серверів. Нижче показана ефективна пропускна здатність каналу при завантаженні сторінки з безліччю об'єктів певного розміру. Ефективна пропускна здатність визначалася як відношення загального числа отриманих байтів до часу їх отримання:

Слід зазначити наступне:

• Для відносно невеликих об'єктів (ліва частина графіка) можна сказати, судячи з великої порожньому місці над лініями, що користувач дуже слабо використовує свій канал, при цьому браузер запитує об'єкти так швидко, наскільки може. Для такого користувача ефективне використання вхідного каналу настає при завантаженні об'єктах розміром 100 Кб і більше.
• Для об'єктів розміром приблизно в 8Кб, можна подвоїти ефективну пропускну здатність каналу, включивши постійні з'єднання на сервері і розподіливши запити по 4 серверам. Це значна перевага.
• Якщо користувач включить конвеєрну передачу запитів в своєму браузері (для Firefox'а це буде network.http.pipelining в about: config), число використовуваних хостів перестане відігравати значну роль, і він буде використовувати свій канал ще більш ефективно, однак, ми не зможемо це контролювати на стороні сервера.

Можливо, більш прозорим буде наступний графік, на якому зображено кілька різних інтернет-з'єднань і виведено відносне прискорення для запиту сторінки з безліччю дрібних об'єктів для випадку використання 4 хостів і включення активну з'єднання на сервері. Прискорення вимірюється щодо випадку 1 хоста з вимкненим keep-alive (0%).

Що тут цікавого:

• Якщо ви завантажуєте багато дрібних об'єктів менше, ніж 10кб, обидва користувачі, і той, хто знаходиться локально, і той, хто по інший бік океану, відчують значне прискорення від включення активного з'єднання і введення 4 хостів замість одного.
• Чим далі знаходиться користувач, то більша виграш.
• Чим більше швидкість з'єднання, тим більше виграш. Користувач з ethernet-каналом в 100Мб на відстані всього 20мс від сервера відчує найбільше прискорення.

Ще хотілося б перевірити вплив розмірів заголовків на ефективну пропускну здатність каналу. Вищерозміщений графік передбачає, що розмір заголовків становить 500 байтів додатково до розміру об'єкта як для запиту, так і для відповіді. Як же зміна цього параметра позначиться на продуктивності нашого 1,5Мб / 384кБ каналу і відстані до користувача в 100мс? Передбачається, що користувач вже спочатку використовує 4 хоста і активне з'єднання.

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

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

Вимірюємо ефективну ширину каналу користувачів

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

Перш, ніж давати браузер будь-які посилання на зовнішні об'єкти (<img src = "...">, <link rel = "stylesheet" href = "...">, <script src = "..."> і т . Д.), ми можемо записати поточний час. Після завантаження всієї сторінки можна буде його відняти і отримати, таким чином, повний час завантаження сторінки (за винятком HTML-файлу і затримок, пов'язаних з першим з'єднанням з сервером). Отримане час можна потім додати до виклику будь-якого URL (наприклад, картинки), розташованої на вашому сервері.

JavaScript-код для цього буде виглядати приблизно так:

<Html> <head> <title> ... </ title> <script type = "text / javascript"> <! - var began_loading = (new Date ()). GetTime (); function done_loading () {(new Image ()). src = '/timer.gif?u=' + self.location + '& t =' + (((new Date ()). getTime () - began_loading) / 1000 ); } // -> </ script> <! - Тут будуть розміщуватися посилання на будь-які зовнішні JS- або CSS-файли, головне, щоб вони йшли нижче верхнього блоку // -> </ head> <body onload = " done_loading () "> <! - Тут йде звичайне зміст сторінки // -> </ body> </ html>

Ця конструкція зробить приблизно такий запис в лог-файл:

10.1.2.3 - - [28 / Oct / 2006: 13: 47: 45 -0700] "GET /timer.gif?u=http://example.com/page.html&t=0.971 HTTP / 1.1" 200 49 .. .

У цьому випадку, як можна зрозуміти із запису, завантаження решти сторінки http://example.com/page.html зайняла у користувача 0,971 секунди. Якщо припустити, що всього на сторінці було завантажено файлів загального розміру в 57842 байтів, 57842 байтів * 8 бітів в байті / 0,971 секунди = 476556 бітів в секунду (4б5Кбіт). Така ефективна пропускна здатність каналу при завантаженні цієї сторінки. Якщо у користувача фізичний входить канал 1,5Мб, значить, є великий простір для збільшення швидкості завантаження .

Поради щодо зменшення часу завантаження

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

Наведені нижче поради частково вже фігурували в інших статтях: поради від Yahoo , об'єднання CSS-файлів , оптимізація часу завантаження сторінки і багатьох інших . Однак, повторення - вчення, до того ж, в наступних радах є кілька свіжих моментів.

Можна спробувати наступні речі:

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

• Завантажуйте менше невеликих об'єктів. У зв'язку з накладними витратами на передачу кожного об'єкта, один великий файл завантажиться швидше, ніж два дрібніших, кожен в два рази менше першого. Варто витратити час на те, щоб привести все викликані JavaScript-файли до одного або двох (або навіть, використовуючи техніку «Ненав'язливий» JavaScript , Взагалі обійтися без викликів зовнішніх файлів), так само як і CSS-файли. Якщо на вашому сайті використовується більше, спробуйте зробити спеціальні скрипти для публікації файлів на «бойовому» сервері або зменшіть їх кількість. Якщо користувальницький інтерфейс повсюдно використовує десятки невеликих GIF-файлів, варто розглянути їх перетворення в більш простий CSS - дизайн (Який не зажадає такого великого числа картинок) і (чи) об'єднання в кілька великих ресурсних файлів, використовуючи поширену техніку CSS sprites .

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

  При генерації сторінки перед вами постане завдання розподілу картинок по 4 різних хостів. Це найлегше зробити за допомогою будь-якої хеш-функції, наприклад, MD5. Замість того щоб завантажувати все <img> з одного http://static.example.com/, створіть 4 хоста (наприклад, static0.example.com, static1.example.com, static2.example.com, static3.example.com ) і використовуйте 2 біта з MD5-суми для кожної картинки, щоб вибрати, на який саме хост ставити посилання на її завантаження. Переконайтеся, що всі сторінки використовують один і той же алгоритм відповідності (вказують на один і той же хост для кожної картинки), інакше ви будете безрезультатно боротися проти кешування .

  Варто, однак, зауважити, що додавання ще одного хоста збільшує витрати на додаткові DNS-пошук і установку HTTP-з'єднання. Якщо у користувачів включена конвеєрна обробка запитів або сторінка підвантажує менш десяти об'єктів (особисто я б рекомендував орієнтуватися на 5-6 на хост, тобто при 10 об'єктах можна вводити другий хост, при 16 - третій, а при 25 - четвертий), то користувачі не відчують виграшу від збільшення числа паралельних запитів і замість прискорення завантаження сайту помітять її уповільнення. Переваги даного підходу з'являться тільки для сторінок з великим числом зовнішніх об'єктів. Варто якимось чином виміряти різницю в часі завантаження для ваших користувачів перш, ніж повністю впроваджувати дану методику.

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

  Виставляйте HTTP-заголовок Expires всюди, де тільки можливо, на кілька днів або навіть місяців в майбутньому (насправді, це залежить від аудиторії вашого сайту - як часто вона змінюється - варто орієнтуватися на час, протягом якого повертається до 80% від усіх відвідувачів). Такий заголовок буде повідомляти браузеру, що ресурс не потрібно перевіряти при кожному завантаженні сторінки, що допоможе зменшити затримку або час на встановлення з'єднання для об'єктів, які і так можна не завантажувати.

  Замість того щоб покладатися на логіку кешування на стороні браузера, можна змінити об'єкт, просто змінивши його URL. Одним з найбільш простих шляхів у даному випадку буде створення нової директорії з номером версії, яка буде містити оновлений статичний файл, організація підключення таких файлів в HTML-коді і їх розпізнавання на сервері, як посилань на дійсні файли (через mod rewrite, швидше за все, але я проти таких рішень: набагато надійніше додавати номер версії в GET-рядку виклику ресурсу). Замість <img src = "http://example.com/logo.gif"> можна використовувати <img src = "http://example.com/build/1234/logo.gif">. Якщо ви захочете випустити нову версію наступного тижня, то всі посилання на файл потрібно буде замінити на <img src = "http://example.com/build/1235/logo.gif">. Це вирішує також ту частину проблем, коли браузер кешує будь-які файли довше, ніж передбачалося - так як URL об'єкта змінився, то це вже зовсім інший об'єкт.

  Якщо ви вирішити архівувати ( gzip ) HTML, JavaScript або CSS, можливо, варто додати « Cache-Control: private »в заголовок Expires. Це запобіжить кешування цих об'єктів на проксі-серверах, що не розпізнають, що ваші стислі файли можна доставляти всім користувачам (а тільки тим, які відправили на сервер відповідні заголовки). Тема Vary покликаний вирішити цю проблему більш елегантно, але на нього не можна повністю покладатися через помилки в IE.

  У всех других випадка, коли для однаково URL'ов передбачається віддаваті однаково Зміст з сервера (например, статічні картинки), в заголовки Варто Додати Cache-Control: public, повідомляючі проксі, что смороду ма ють право закешіруваті результат и віддаваті его різнім користувач. Если в локальній кешіруєтся проксі Вже є ваш файл, то затримка на его доставку до користувача буде ще менше; так чому б не дозволити проксі віддавати ваші статичні об'єкти, якщо вони в ній є?

  Уникайте використання GET-параметрів в URL'ах картинок, ресурсних файлів і т.д. Прінаймні, Squid відмовляється кешувати, за замовчуванням, будь-який URL, який містить знак питання (в такому випадку, ми отримаємо кешування на клієнті, деяку додаткову затримку при завантаженні файлів в перший раз і відносно швидку розробку, коли нові версії можна буде позначати через GET-параметр файлу, на мій погляд, якщо ми не розглядаємо максимально оптимізовану під кешування систему, то такий підхід цілком припустимо). До мене доходили чутки, що деякі інші додатки взагалі не кешируєтся такі URL'и, але точної інформації у мене немає.

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

  При видачі статичних файлів (включаючи HTML) з диска більшість веб-серверів автоматично генерують заголовок Last-Modified і (чи) ETag у відповіді з вашого боку і обслуговують відповідні If-Modified-Since і (чи) If-None-Match заголовки в клієнтських запитах. Але якщо ви використовуєте включення на стороні сервера, динамічні шаблони або генеруєте ваші сторінки «на льоту», вам доведеться подбати про таких позначках в заголовках самостійно.

  Загальна ідея дуже проста: при генерації сторінки ви забезпечуєте браузер деякою кількістю додаткової інформації про те, що ж це конкретно за сторінка, яку ви йому відправляєте. Коли браузер запитує цю ж сторінку знову, він відправляє отриману інформацію назад на сервер. Якщо вона збігається з тим, що ви збираєтеся відправляти, то ви точно знаєте, що на клієнті вже є ця інформація, і передаєте тільки 304-відповідь (Not Modified), який набагато менше 200, замість того, щоб видавати зміст сторінки заново. І якщо ви досить кмітливі щодо інформації, яку ви передаєте в ETag, то можна уникнути запитів (які можуть бути досить інтенсивними) до бази даних, необхідних для генерації сторінки.

• Зменшуйте розмір HTTP-запитів. Найчастіше cookie виставляються на весь домен або навіть на все піддомени, що означає їх відправку браузером навіть при запиті кожної картинки з вашого домену. Це може вилитися в те, що 400-байтний відповідь з картинкою перетвориться в 1000 байтів або навіть більше, в залежності від доданих заголовків cookie. Якщо на сторінці у вас багато некешіруемих об'єктів і великі cookie на домен, розгляньте можливість винесення статичних ресурсів на інший домен (до речі, так вчинив Яндекс, винісши статику на Yandex.net ) І переконайтеся, що cookie там ніколи не з'являться.

• Зменшуйте розмір HTTP-відповідей, включивши gzip-стиснення для HTML і XML для браузерів, які це підтримують. Наприклад, завантаження документа розміром в 17Кб, яким є дана стаття, займає 90МС для користувача з DSL-каналом в 1,5Мб. Він же може займати 37мс, якщо документ стиснути до 6,8Кб. Цілих 53мс виграшу в часі завантаження сторінки через простої зміни. Якщо розмір ваших HTML-сторінок значно більше, то прискорення буде ще більш значним.

  Якщо вам не чуже новаторство і ви володієте достатньою сміливістю, можна спробувати віддавати браузерам стислий gzip'ом JavaScript і подивитися, які браузери з цим впораються. (Підказка: від IE4 до IE6 запитують стислий JavaScript , А потім жорстоко обламуються, отримуючи його саме стислим. За моїми власними даними, не все так погано, десь 1/1000 користувачів IE володіє описаної проблемою, докладніше про заголовках для стиснення JS і CSS можна прочитати тут ). Також можна поглянути в сторону обфуськатор JavaScript-коду, які вирізують зайві прогалини, коментарі і т. Д. Як правило, таким чином можна зменшити файл від 1/3 до 1/2 від його початкового розміру .

• Розгляньте можливість розташувати невеликі об'єкти (або дзеркало, або їх кеш) максимально близько від користувачів в термінах мережевих затримок. Для великих сайтів з міжнародною аудиторією можна використовувати як платні мережі доставки змісту ( Content Delivery Network ), Так і окремі віртуальні машини в межах 50 мс для 80% ваших користувачів разом з безліччю доступних методів для розподілу запитів користувачів на найближчу до них віртуальну машину (до слова сказати, як раз так працюють сайти багатьох міжнародних компаній, в тому числі, і Acronis , Розподіляють користувачів по локальних версій в залежності від географічної ознаки).

• Регулярно перевіряйте ваш сайт, заходячи за допомогою «рядових» з'єднань. У моєму випадку використання «повільного проксі-сервера», який емулюватися погане DSL-з'єднання з Нової Зеландії (768Кбіт входить, 128кбіт вихідний, 250мс затримка, 1% втрати пакетів) замість гігабайтного каналу з декількома мілісекундами від серверів в штатах, виявилося вельми корисним. Ми дуже оперативно виявили та усунули ряд функціональних помилок і проблем зручності використання.

  Для моделювання такого повільного з'єднання, я використовував модулі ядра Linux netem и HTB , Які доступні з версії 2.6. Обидва цих модуля встановлюються з командою tc . Це дозволяє домогтися найбільш точної емуляції, яку мені вдалося знайти, але я б не назвав її ідеальною. Особисто я не користувався, але, на загальну думку, Tamper Data для Firefox, Fiddler для Windows і Charles для OSX можуть виставити обмеження на ШВИДКІСТЬ завантаження і, можливо, легко налаштовуються, але, швидше за все, вони не вміють акуратно налаштовувати мережеві затримки.

• Для Firefox можна використовувати Firebug , Який дозволяє побудувати реальний графік завантаження сайту в часі і відобразити, що вантажиться в браузері в даний момент. Це розширення також дозволяє побачити, як Firefox чекає закінчення одного HTTP-запиту, щоб почати наступний, і як час завантаження зростає з кожним підключається об'єктом. Розширення YSlow до Firebug також пропонує ряд рад, як поліпшити продуктивність вашого сайту.

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

  Якщо ж ви добре знайомі з HTTP-протоколом і TCP / IP на пакетному рівні, то можна спробувати подивитися, що відбувається, використовуючи tcpdump , ngrep або ethereal . Ці інструменти є просто обов'язковими для мережевих отладок будь-якого роду.

• Спробуйте протестувати часто завантажуються сторінки вашого сайту на продуктивність з локальної мережі, використовуючи ab , Який поставляється разом з веб-сервером Apache . Якщо сервер відповідає довше, ніж 5-10 мілісекунд при генерації сторінки, значить, варто добре розібратися, на що ж йде серверне час.

  Якщо в результаті таких тестів затримки виявилися досить високими, і процес веб-сервера (або CGI, якщо ви використовуєте його) «з'їдає» занадто багато CPU, то причиною цього часто може виявитися необхідність в компіляції скриптів в процесі виконання при кожному запиті. Таке програмне забезпечення, як eAccelerator для PHP, mod_perl для perl, mod_python для python і т. д. можуть кешувати серверні скрипти в скомпільованому стані, істотно прискорюючи завантаження вашого сайту. Крім цього, варто знайти профілюючий інструмент для вашої мови програмування, щоб встановити, на що ж витрачаються ресурси CPU. Якщо вам вдасться усунути причину великих навантажень на процесор, то сторінки будуть віддаватися швидше, і ви зможете видавати більше трафіку при меншій кількості машин.

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

• (За бажанням) Подати петиція виробникам браузерів з метою включити конвеєрну обробку HTTP-запитів за замовчуванням в нових браузерах. Якщо це буде зроблено, то нам не доведеться виконувати ці «танці з бубнами» (these tricks), і велика частина веба буде завантажуватися швидше для середнього користувача. (В Firefox'е це відключено, імовірно, через деяких проксі, деяких балансувальник навантажень і деяких версій IIS (привіт, Microsoft!), Які впадають в шок при конвеєрних запитах. Але в Opera, мабуть, провели істотну роботу для того, щоб включити цю можливість за замовчуванням. Чому так не можуть вступити всі інші браузери?)

Висновок

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

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

Читати далі

Всі Коментарі (habrahabr.ru)