Подгответе се за HTTP/2: Упътване за уеб дизайнери и девелопъри!

HTTP е стар протокол, чийто инициали са дефинирани през 1991, като последната главна редакция – HTTP/1.1 е публикувана през 1999г. Уеб сайтовете през 1999 г. са се различавали доста от тези, които създаваме днес. В „Http2 explained” Даниел Стернбърг отбелязва, че количетвото информация необходимо за зареждане на начална страница на стандартен уебсайт е 1.9 MB, което е над 100 индивидуални ресурса, нужни, за да се зареди страницата. Като под ресурс разбираме, всичко от обикновена снимка или текст на JavaScript или CSS. 
HTTP/1.1 не се представя много добре, при извличане на голям брой ресурси, които са необходими, за да се зареди модерен уеб сайт. Както ще разберем по-долу в тази статия, много от най-добрите практики за качествена изява, които ние знаем и използваме като уеб девелопъри, произхождат от възможността ни да се справяме с ограниченията на HTTP/1.1. 

През 2009 г., двама инженери в Google публикуват изследователски проект, върху който са работели, наречен SPDY. Този проект съдържа някои от нещата, които срещаме в HTTP/1.1, които определяме така: 
- Възможност за едновременни заявки от една единствена TC връзка, известна като multiplexing. 
- Възможност браузъра да приоритизира активите, така че ресурсите – жизненоважни за поява на страница, да бъдат изпратени първо от сървъра. 

Изпълнение на server push, с което сървъра може да прекара сам жизненоважни ресурси към браузъра, преди да бъде помолен за тях. 
В допълнение към споменатото, SPDY изисква криптирана (HTTPS) връзка между браузър и сървър. SPDY не заменя HTTPs по-скоро, той е тунел към протокола и определя начина, по който съществуващите HTTP заявки и отговори се изпращат. Изисква се двустранна поддръжка, от страна на сървър и браузър, които да са свързани с този сървър. Със съпорта на NGINX и пакетите на разположение от Google, с които да се даде възможност за подкрепа от Apache, се наблюдаваше разумно количество адаптивност от SPDY. 
 

Виждали сме, че SPDY се радва на успех, постигайки адаптивност с двата сървъра и браузъра. Въпреки това, може би сте забелязали, че въпреки поддръжката на Internet Explorer 11, крайният бразузър на Microsoft не тръгва. Защо това се случва? 
 
Поддръжката на SPDY е паднала от Edge заради включването на поддръжка от Microsoft за HTTP/2 - най-новата версия на HTTP протокола. Докато някои настоящи браузъри все още да осигуряват поддръжка на SPDY, Chrome снема поддръжката през 2016 и най-вероятно и други браузъри ще го последват.  Edge, FireFox, Chrome Opera поддържат двата SPDY и HTTP/2. Safari, включително и на iOS, ще се присъединят към тази група по-късно тази година с появата на Safari 9. 

HTTP/2 се гради на успеха на SPDY, който се използва за отправна точка на новия протокол. Поради тази причина и голяма част от елементите на SPDY се срещат в HTTP/2. Изискванията за HTTPS връзките са били свалени. Това означава, че всички доставчици на браузъри са решили да използват само HTTP/2 за TLS (http) връзки. Така че, докато използвате HTTP/2 с чист текст в комуникацията между два сървъра, нашата ползва от осигуряването на HTTP/2 към браузърите означава, че трябва вашият сайт да върви с https преди да си помислите да го сменяте с HTTP/2. 
Спецификациите на HTTP/2 се финализират през февруари 2015 г. Една година след това, поддръжката на браузъра в съвременните браузъри е отлична. Както SPDY, така и HTTP/2 изисква поддръжка и на двата браузър и сървър и вече има създадени множество сървърни реализации. Адаптирането на този протокол се случва бързо, имайки предвид, че е сравително нов. 

HTTP/2 е обратно-съвместим с HTTP/1.1, така че може да го игнорирате напълно и всичко да продължи да работи както преди. Промяната на протокола е напълно прозрачно събитие за потребителите. Много от вас, които четат тази статия ще осъзнаят, че са използвали протокол различен от HTTP/1.1 от години. Ако имате Gmail акаунт и използвате Chrome, за да влезете в него, то би трябвало да сте използвали SPDY, след което HTTP/2 без дори да подозирате това. 

Въпреки това, много от нещата, които приемате за най-добри практики могат да предизвикат провал в изявата с HTTP/2. Във времето, колкото повече сървъри се ъпдейтват  с HTTP/2, вашият уебсайт, от една страна добре оптимизиран що се отнася до най-добрите приети практики, ще започне да ви се струва по-бавен, в сравнение с уебсайтове оптимизирани на новият протокол. 

В останалата част на тази статия ще обърнем внимание на някои от най-често срещаните практики, които ще се превърнат в анти-модели след адаптацията на HTTP/2. Както сме ставали свидетели и преди, промяната ше бъде бавна за много уебсайтове. Преди да се прехвърлите на HTTP/2, вашият софтуер на сървъра трябва да се ъпдейтне да поддържа новият протокол, което само по себе си може да е лесно или почти невъзможно, зависи от хостинга. 
Преди да предприемете промени по вашият уебсайт свързани конкретно с HTTP/2, ще трябва да обмислите дали браузърите на вашите потребители поддръжат новият протокол. Собственици на сайтове, които привличат множество потребители използващи съвременни браузъри ще могат да се прехвърлят на новият протокол по-скоро, отколкото онези от тях, които използват по-стари браузъри. За да избегнете такива усложнения, ще ви дадем някои съвети, които да ви помогнат в процеса на прехвърляне. 

За много уебсайтове, най-трудната част в прехвърлянето към HTTP/2 съвсем не е свързана със самия HTTP/2, а по-скоро с изискването сайта да работи при отлично защитена връзка. Ако създавате нов сайт или обновявате някой стар, първата крачка, която трябва да предприемете е да се прехвърлите на https, колкото се може по-скоро! Това има значение не само за HTTP/2, а и за Google, който се влияе от защитните връзки, приемайки ги като сигнали, определящи  позицията в класиране. В бъдеще ще видите, че някои мощни HTML5 характеристики, като geolocation, няма да са на разположение без защитни връзки. Ако в момента имате уебсайт само с http, то ние ви съветваме да предприемете стъпка първо към https и след това обмислете своята HTTP/2 стратегия. 

При HTTP 1.1 преобразуването на едно голямо изображение е много по-ефикасно за браузъра, отколкото да предаваме редица заявки за по-малки такива. Това се дължи на факта, че твърде много искания образуват заплетена опашка след себе си. За да се справите с това, бихме посъветвали да превърнете вашите малки икони в sprite файлове. Създадените sprite, водят до само една HTTP заявка, която ви предпазва от хаоса преди това. Въпреки това, дори посетителят да е на страница, която показва само една от тези икони, той пак ще трябва да свали доста по-голям файл, за да види по-големия размер на изображението. 

Със способността за мултиплексиране на HTTP/2, това преплитане на източници вече не е на дневен ред. Обслужването на малки изображения индивидуално ще бъде по-добро в много отношения. Ще трябва да обслужвате само онова, което се изисква от страницата, на която е даден посетител. Създаването на sprite все още ще бъде гаранция в някои случаи. HTTP заявките са само един от аспектите свързани с изявата. Комбинацията на няколко изображения в едно скрито, ше постигне по-добри резултати при компресиране, както и по-малък размер за сваляне, особено когато тези изображения се използват на страницата, която зареждаме.

Друго решение на проблема свързано с редица HTTP заявки при HTTP/1.1 е да вградим изображения на CSS използвайки текстови Urls. Вградените изображения по този начин ще направят стилният лист много по-голям. Ако сте комбинирали това с друга оптимизираща техника за конкатенации на активи, тогава посетителите ще могат да свалят целия код дори, ако никога не са посетили страниците, в които се използват тези изображения. Тъй като HTTP заявките са много леки в HTTP/2, тази „най-добра практика“ ще навреди повече, отколкото да помогне на изявата. 

Като последна стъпка в процесът на изграждане, мнозина от вас ще свързват всички малки CSS и JavaScript файлове. Често ние предпочитаме да ги държим разделени докато изграждаме, за да направим нещата по-лесни при управлението на източниците. Но сме наясно, че доставката на един файл до браузъра е много по-ефикасен начин за добрата изява, отколкото да доставим 5. Отново се опитваме да ограничим HTTP заявките. Ако правите това, когато посетител влезе във вашата начална страница, то той би могъл да свали всички кодове на CSS и JavaScript, дори и никога да не използват по-голямата част от него. Като девелопър, може да се отървете от този проблем като внимателно избирате и включвате специфични файлове за всяка зона на уебсайта в процеса на изграждане, но имайте предвид, че това може да ви коства доста работа. 

Допълнителен проблем с конкатенацията е, че всичко ще трябва да се изчисти от кеша наведнъж. На някои файлове, които не се променят може да дадете дълъг срок на годност, а на често сменящите - по-кратък срок. Всичко трябва да изтече, дори ако един ред на CSS използван на отделна страница е променен. 
HTTP заявките са евтини в света на HTTP/2. Изтеглянето на много тънки стилови листове няма да има значение. Може също така да организирате, основавайки се на това, колко често нещата се менят. Активи с дълголетие могат да се обгрижват по-дълго. 

С HTTP/1.1 вие сте ограничени за количеството отворени връзки. Ако зареждането на голямо количество ресурси е неизбежно, метод, който да ви отърве от това ограничение е да ги извлечете от няколко домейна. Това е известно като domain sharding. Така ще постигнете по-добро време за зареждане, както и може да възникнат някои проблеми, да не говорим за глвоболието в развитето на това на вашият сайт. 
 
HTTP/2 премахва нуждата от domain sharding, защото можете да извикате толкова ресурси, колкото са ви необходими. Всъщност, тази техника е вероятно да намали производителността, защото създава допълнителни TCP връзки и пречи на HTTP/2 да приоритизира ресурсите. 
 

Ако стартирате проект, от който очаквате да бъде дълготраен, но не можете да подкарате HTTP/2 вероятно заради поддръжката на сървъра, то би трябвало да обмислите как да се подготвите за HTTP/2. Може да добавите няколко неща в процеса на изграждане, които да направят по-лесно превключването на по-късен етап. 

Ако създавате спрайтове, добавете към тях изграждането и оптимизацията на тези индивидуални аспекти или по-малки специфични спрайтове, ако смятате, че ще подобрите производителността чрез тях. Това ще ви улесни в превключването от големи спрайтове към малки, когато бъде достигната повратната точна на вашият уебсайт. Всичко това се отнася и към Data URLs. Aко в момента използвате тези във вашият CSS, изображенията трябва да са подготвени.

Чрез сливането на CSS и JavaScript се изкушаваме за оптимизация за лесно развитие, защото всички файлове така или иначе ще бъдат смачкани. Когато превключите на HTTP/2, ще получите най-добрата производителност чрез внимателно управлявани ресурси, така че само нещата необходими за определена страница да бъдат представени. Също така, организацията на развитието по този начин ще започне да ви се отблагодарява. За сега, все още може да сливате и когато повратната точка бъде достигната, може да прекратите частта от изграждането и да обслужите ресурсите индивидуално. 

Най-добрата практика в момента при http/1.1 е да се ограничи sharding-а до две host имена. Има начин да се доберете до HTTP/2, за да слеете връзките, ако TLS сертификата е валиден за двата host-а и те се обърнат към еднакво IP. Откакто изпълнителите изискват HTTP/2 да върви по-добре от HTTPS е необходимо да получите TLS сертификат, за да подкарате HTTP/2. 
 

За дизайнери и девелопъри, които нямат пълен контрол над сървърите, към които са свързани, ще трябва да изчакат определен период от време докато тези сървъри бъдат ъпдейтнати. Има хостинг компании, които предлагат вече HTTP/2 – дори за споделен хостинг- така че свързването му към поддържащ сървър е нещо, което може да препоръчате на клиенти, ако мислите че биха приели. 
Веднъж когато вашият уебсайт е хостнат от сървър, който поддържа HTTP/2, решението дали да продължите оптимизацията за HTTP/1.2 или да оптимизирате http/2 ще опре до протокола, който поддържат мнозинсвото от вашите потребители. Запомнете че, HTTP/2 е обратно-съвместим – няма нужда да правите нещо специфично. Решението, което трябва да вземете е кога да се оптимизирате за него. Ще решите като се допитате до вашата аналитична информация. Ако повече потребители използват HTTP/2, то това е повратна точка, определяща, че и вие трябва да се оптимизирате в тази посока. Може да използвате информация от сайтове като Can I Use, заедно с информация събрана от вашият собствен аналитичен процес и знания за публиката. Например, много от предимствата на HTTP/2 ще се почувстват осезателно от потребители на HTTP/2 поддържащи го на своите мобилни устройства. Ако потокът от хора е повече от мобилни устройства, то и вие трябва да се ориентирате в тази посока и възможно по-скоро. 

1. Преминете към безопасна връзка или се обърнете към TLS сега! 
Това трябва да бъде приоритет!
 
2. Подгответе за HTTP/2  в процесът на изграждане. 
Всеки сайт, който създавате ще бъде с предимство доживот, ако е оптимизиран за HTTP/2. Използвайте гореспоменатите съвети, за да създадете изграждащ процес, който да се оптимизира за двата протокола. 
 
3. Проверете статистиките.
Сравнявайки употребата на браузъри на вашият сайт чрез поддържата функция на Can I Use, ще видите какъв процент от посетителите ще бъдат доволни от HTTP/2 оптимизацията. 
 
4. Проверете своя хостинг. 
Когато достигнете точката, при която осъзнавате, че бихте спечелили от превключване, то трябва да се убедите, че вашият сървър поддържа HTTP/2. Свържете се с вашата хостинг фирма или администратор на сървър, за да представят техният миграционен план. 
 
5. Развийте оптимизацията на HTTP/2. 
Веднъж когато сървърът вече поддържа HTTP/2, останалото зависи от вас. Спрете да използвате старите практики и преминете към новите. 
 
Когато се прехвърлите на HTTP/2 ще бъде интересно. Проверете дали се отбелязва нарастване в скоростта и дали ще откриете техника, която бележи голяма разлика в уебсайта. Всички впечатления ще бъдат от значение, защото ще поставят началото на изцяло нови.