Оптимизация на сайт с използване на компресия
Използване на GZIP компресия
Компресирането на страниците при уеб сървъра е лесен и ефективен начин да спестиш трафик (bandwidth) и да намалиш значително времето, за което се зареждат страниците на твоя сайт. За да разбереш защо и кога ти трябва компресиране трябва да имаш елементарни познания по HTTP протокола и начина, по който си разменят данни браузъра и уеб сървъра.
HTTP Заявка и отговор
Когато в браузъра напишеш интернет адрес http://domain.com/index.html той изпраща запитване към уеб сървъра, който хоства сайта domain.com и протича разговор подобен на следния:
.
.
.
.
.
.
.
.
.
.
1. Браузър: Здрасти domain.com, дай ми index.html
2. Сървър: Добре, чакай да видя дали има такъв файл…
3. Сървър: OK намерих файла (response code 200 OK). Изпращам файла.
4. Браузър: Ох, 100KB? Зареждам… зареждам… готово целия файл е зараден и показан (Done).
Разбира се реалната картина е малко по-сложна. Тук не са написани всичките хедъри, които си разменят браузъра и уеб сървъра. Хедърите са служебна информация, която браузъра и сървъра разменят помежду си невидимо за потребителя на сайта. Хедърът „GET /index.html HTTP/1.1″ се нарича хедър на заявка (request header), а хедъра с отговор на сървъра „HTTP/1.1 200 OK“ се нарича хедър на отговор (response header). Името на домейна doamin.com е само за пример.
Преглед на HTTP хедъри
Има различни начини, да видиш всички хедъри, които си разменят браузърът и сървъра.
Ако използваш браузър Google Chrome тази възможност е вградена в браузъра – натисни клавишната комбинация Ctrl+Shift+I и екрана ще се раздели на две. Натисни третия бутон Network и след това зареди в браузъра сайта http://ganbox.com. Ще се зареди списък с елементи, които се съдържат в началната страница на ganbox.com, отиди в началото на списъка и избери с мишката първия елемент. Отдясно ако не е избран избери таб Headers и ще видиш всички изпратени и получени хедъри от браузъра. В раздела Request Headers се вижда, че браузъра е изпратил хедъра „Accept-Encoding: gzip,deflate,sdch“. Всички съвременни браузъри изпращат този хедър, с което казват на сървъра, че могат да приемат компресирано съдържание. Щом могат, нека правим сайтовете си така, че да се възползваме от тази възможност.
Ако използваш браузър Mozilla Firefox ти трябва плъгина Live HTTP Headers. След като го инсталираш и рестартираш браузъра, този плъгин се включва от Tools / Live HTTP Headers и за всяка страница която зареждаш, ще виждаш хедърите.
Скорост на зареждане на сайт
Нека разгледаме как се разпределя времето за зареждане на страницата на всяка от стъпките. Най-бавно се пренасят данните от стъпка 3 към стъпка 4, след това по време е пренасянето на данните от стъпка 1 към стъпка 2, след което са самите стъпки в този ред: 3, 4, 2, 1. Както се вижда най-проблемна е сивата зона означена с Интернет през която преминават данните. Защо това е така? Защото тук се случват много неща. Ще изброя само тези, които имат отношение към статията: превръщане на името domain.com в IP адрес, установяване на TCP връзка между двата компютъра – този с браузъра и този на който е уеб сървъра, разделяне на файла на пакети, като всеки пакет се номерира и адресира, изпращане на пакетите. Колкото по-голям е обема на предаваните данни, толкова повече пакети се получават. Пакетите пътуват през мрежата, като преминават през междинни машини – рутери, ако браузъра и уеб сървъра са в една и съща държава междинните рутери са около 3, но ако е в друга държава може да се 5-6 и повече. Получаващата машина започва да получава пакетите, сглобява ги за да получи оригиналния файл. Възможно е някой от пакетите да се загуби и ще бъде изпратен повторно. За всеки от пакетите се изпраща потвърждение.
За пълнота ще спомена, че на стъпка 3, ако файла не е HTML, а PHP файл или друг скрипт, той може да има обръщение към SQL база данни, от която извлича данни. Ако SQL заявката е прекалено бавна, може да се получи така, че това да бъде най-бавната стъпка от всички. По този начин се вижда, че има само две места, на които можем да направим оптимизация – оптимизиране на SQL заявката и намаляване размера на файла, предаван от стъпка 3 към стъпка 4 и тъй като това не е статия за оптимизация на SQL заявки, няма да разглеждаме този случай, а само компресиране на файла за получаване на по-малък размер. Така стигаме до необходимостта, да се погрижим уеб сървъра да връща някои от файловете компресирани.
Компресиране на данни в HTTP отговор
Когато се ползва компресиране на данните, разговорът между браузъра и уеб сървъра изглежда така:
.
.
.
.
.
.
.
.
.
.
1. Браузър: Здрасти domain.com, искам да получа index.html, мога да получа компресирана версия, ако има.
2. Сървър: Добре, чакай да видя дали има такъв файл и виждам, че може да приемаш компресирани файлове.
3. Сървър: OK намерих файла (response code 200 OK). Компресирам и изпращам файла.
4. Браузър: Супер! Само 10 KB е, ще го разкомпресирам и покажа на потребителя.
Формулата е проста: по-малък файл = по-малък трафик = по-бързо зареждане на страницата => всички са доволни: потребителя защото отваря сайта бързо и собственика на сайта, защото плаща по-малко за трафик (ако има ограничение на трафика).
Тънкият момент при тази комуникация е браузърът и сървърът да се договорят, че ще се пренася компресирано съдържание за конкретния файл. Споразумението протича в две части:
– браузърът изпраща хедър “Accept-Encoding: gzip, deflate“, с което казва на сървъра, че може да приема компресирани файлове, по gzip компресия или по deflate компресия;
– сървърът връща хедър „Content-Encoding: gzip“, ако съдържанието наистина е компресирано.
Браузърът не може да задължи сървъра да върне компресирано съдържание, той само изпраща молба. Ако браузърът е казал, че приема компресирани файлове, но сървърът не върне „Accept-encoding“ хедър, това означава, че сървърът по някаква причина не е компресирал съдържанието.
Кога да се ползва компресиране?
Най-важното е да разбереш, кога да ползваш компресирани файлове: …
Прочетете цялата статия в Оптимизация на сайт с използване на GZIP компресия
