- 1.1. Мэты і задачы аптымізацыі
- Асноўныя задачы аптымізацыі
- Кароткі агляд тэхналогій
- 1.2. Псіхалагічныя аспекты прадукцыйнасці
- Памяркоўнае час чакання
- Эфекты павольнай хуткасці загрузкі
- Як час адказу сайта ўплывае на карыстацкую псіхалогію
- 1.3. Стадыі загрузкі старонкі
- расстаўляем прыярытэты
- вузкія месцы
- 1.4. Кліенцкая і серверная аптымізацыя: падабенства і адрозненні
- Кэшаванне ў аснову
- Менш запытаў - лягчэй серверу
- Архіваваць і кэшаваць на сэрвэры
- Хто ў каго на службе?
- 1.5. Прымяненне ў распрацоўцы прыкладанняў
- Этап 1: Дастаўка інфармацыі і афармлення
- Этап 2: Кэшаванне файлаў афармлення і паралельныя запыты
- Этап 3: Жыццё пасля загрузкі старонкі
- Этап 4: Папярэджваем дзеянні карыстальніка
Кіраўнік 1. Што такое кліенцкая аптымізацыя?
1.1. Мэты і задачы аптымізацыі
Кожная вэб-старонка складаецца з асноўнага HTML-файла і набору знешніх рэсурсаў. Кажучы пра памер старонкі (або сайта), вельмі часта маюць на ўвазе памер менавіта першага файла, што, натуральна, няправільна.
Мал.1 .1. Тэндэнцыя змены памеру старонкі і колькасці аб'ектаў для сайтаў, якія правяраюцца праз Web Optimizator у 2008 годзе У цяперашні час на кожнай старонцы выклікаецца некалькі дзясяткаў знешніх аб'ектаў, а памер зыходнага файла складае не больш за 5% ад агульнага памеру. Як паказалі шматлікія даследаванні, памер вэб-старонкі за апошнія 5 гадоў павялічыўся ўтрая, а колькасць аб'ектаў на ёй - амаль у два разы. Пры гэтым тэмпы росту сярэдняй прапускной здольнасці канала толькі трохі вышэй дадзеных паказчыкаў. Калі ўлічваць расслаенне карыстальнікаў па хуткасцях доступу, то імкненне паменшыць колькасць карыстальнікаў, якія перавышаюць дапушчальны парог чакання на 1-5%, прымушае ўжываць ўсё больш складаныя і перадавыя тэхналогіі. Натуральна, што тэхналогіі гэтыя не абмяжоўваюцца сціскам тэкставых (HTML, CSS, JavaScript) файлаў на боку сервера. Як нескладана зразумець, асноўную частку знешніх аб'ектаў на старонцы складаюць малюнкі або мультымедыйныя файлы. І для іх таксама ёсць свае метады аптымізацыі. Асноўныя задачы аптымізацыі
Калі казаць коратка, то можна вылучыць 3 асноўных задачы кліенцкай аптымізацыі: Аптымізацыя памеру файлаў. Аптымізацыя затрымак пры загрузцы. Аптымізацыя ўзаемадзеяння з карыстальнікам.Кароткі агляд тэхналогій
Пры гэтым усе асноўныя метады можна разбіць на 6 груп (кожная з якіх дазваляе вырашыць адну з заяўленых задач). Памяншэнне памеру аб'ектаў. Тут фігуруюць сціск і метады аптымізацыі малюнкаў, больш падрабязна пра гэта можна прачытаць у другой чале. Асаблівасці кэшавання, якія здольныя кардынальна паменшыць колькасць запытаў пры паўторных наведваннях, раскрываюцца ў трэцяй чале. Аб'яднанне аб'ектаў. Асноўнымі тэхналогіямі з'яўляюцца зліццё тэкставых файлаў, прымяненне CSS Sprites або data: URI для малюнкаў. Гэтаму прысвечана чацвёртая частка кнігі. Паралельная загрузка аб'ектаў, якая ўплывае на эфектыўнае час чакання кожнага файла. У пятай чале акрамя гэтага прыведзены прыклады балансавання запытаў з боку кліенцкага прыкладання. Аптымізацыя CSS -производительности, што праяўляецца ў хуткасці з'яўлення першапачатковай карцінкі ў браўзэры карыстальніка і хуткасці яе далейшага змены. Аб CSS-прадукцыйнасці распавядае шостая кіраўнік. Аптымізацыя JavaScript. Ёсць досыць шмат праблемных месцаў у JavaScript, пра якія неабходна ведаць пры праектаванні складаных вэб-прыкладанняў. Пра ўсё гэта можна прачытаць у сёмы чале. Хочацца адзначыць, што, нягледзячы на ўсю складанасць закрананай тэмы, першапачатковага паскарэння загрузкі вэб-старонкі можна дамагчыся ў некалькі вельмі простых крокаў. Пры гэтым можна скараціць час з'яўлення вэб-старонкі ў некалькі (звычайна ў 2-3) раз. Усе рады ў кнізе упарадкаваны па павелічэнні складанасці ўкаранення і памяншэння магчымага выйгрышу пры загрузцы старонкі. Для простых вэб-праектаў можна абмежавацца толькі уключэннем кэшавання і архівавання (gzip або deflate). Больш складаным спатрэбіцца змяніць вёрстку, выкарыстоўваючы CSS Sprites або data: URI, і дадаць некалькі хастоў для загрузкі малюнкаў. Для высоконагруженных праектаў (некаторыя з іх прааналізаваныя ў канцы восьмы кіраўніка) трэба ўлічваць усе аспекты кліенцкай аптымізацыі з самага пачатку пры праектаванні і прымяняць іх паслядоўна для дасягнення найлепшага выніку.1.2. Псіхалагічныя аспекты прадукцыйнасці
Згодна з шматлікіх даследаваннях карыстацкае раздражненне моцна ўзрастае, калі хуткасць загрузкі старонкі перавышае 8-10 секунд без усякага апавяшчэння карыстальніка аб працэсе загрузкі. Апошнія працы ў гэтай галіне паказалі, што карыстальнікі з шырокапалосным доступам яшчэ менш памяркоўныя да затрымак пры загрузцы вэб-старонак у параўнанні з карыстальнікамі з больш вузкім каналам.
У праведзеным у 2007 годзе апытанні было ўстаноўлена, што 33% карыстальнікаў хуткаснага злучэння не хочуць чакаць пры загрузцы старонкі больш за 4 секунд, пры гэтым 43% карыстальнікаў не чакаюць больш за 6 секунд. У дадзеным выпадку маецца на ўвазе, што карыстальнік у большасці выпадкаў пакіне сайт, калі на працягу 5-10 секунд будзе бачыць замест яго белы экран у браўзэры.
Памяркоўнае час чакання
Пры даследаванні, праведзеным у 2004 годзе, было ўстаноўлена, што памяркоўнае час чакання для непрацуючых спасылак (без зваротнай сувязі) знаходзілася паміж 5 і 8 секундамі. З даданнем апавяшчэння карыстальніка аб працэсе загрузкі (зваротнай сувязі), напрыклад, індыкатара загрузкі, такі час чакання павялічылася да 38 секунд. Размеркаванне часу для паўторных спробаў зайсці на непрацуючыя спасылкі мела максімум у раёне 23 секунд (без наяўнасці якіх-небудзь індыкатараў, якія паказваюць, што старонка загружаецца ці ў дадзены момант недаступная).
Такім чынам, можна зрабіць выснову, што для 95% карыстальнікаў час чакання адказу ад непрацуючага сайта складзе не больш за 8 секунд. Калі ўлічыць імкненне карыстальніка наведаць сайт паўторна, то даследаванні прадэманстравалі вельмі малы (амаль роўнае нулю) колькасць карыстальнікаў, якія чакаюць больш за 10 секунд.
Эфекты павольнай хуткасці загрузкі
Нават малыя змены часу загрузкі могуць мець значныя наступствы. Так, для Google ( http://www.google.com/ ) Павелічэнне часу загрузкі для старонкі з 10 пошукавымі вынікамі на 0,4 секунды і на 0,9 секунд для старонкі з 30 вынікамі адбілася на памяншэнні трафіку і рэкламных прыбыткаў на 20% (у адпаведнасці з даследаваннямі, праведзенымі ў 2006 годзе). Калі галоўную старонку Google Maps ( http://maps.google.com/ ) Паменшылі ў аб'ёме з 100 Кб да 70-80 Кб, трафік павялічыўся на 10% на працягу першага тыдня і яшчэ на 25% у наступныя тры тыдні (па дадзеных 2006 года).
Тэставанне ў 2007 годзе для Amazon дало вельмі блізкія вынікі: кожныя 100 мс павелічэння часу загрузкі для Amazon.com змяншалі продажу на 1%. Эксперыменты Microsoft для Live Search ( http://www.live.com/ ) Паказалі, што пры запаволенні загрузкі старонак на 1 секунду колькасць скінутых пошукавых запытаў ўзрасла на 1% і лік клікаў па рэкламе зменшылася на 1,5%. Пры павелічэнні часу загрузкі старонкі з вынікамі яшчэ на 2 секунды колькасць скінутых пошукавых запытаў ўзрасла на 2,5% і лік клікаў па рэкламе зменшылася на 4,4%.
Як час адказу сайта ўплывае на карыстацкую псіхалогію
Карыстальнікі адчуваюць, што сайты, якія загружаюцца павольна, менш надзейныя і менш якасныя. У выпадку, калі ўтрымліваць час загрузкі ў межах «памяркоўнага», карыстальнікі будуць адчуваць значна менш незадаволенасці ад наведвання сайта, сярэдні лік праглядаў старонак ўзрасце, павялічыцца канверсія наведвальнікаў і знізіцца колькасць адмоў. Сайты, якія хутка загружаюцца, таксама здаюцца карыстальнікам больш цікавымі і прывабнымі.
«Памяркоўнасцю» час будзе моцна залежаць ад аўдыторыі, але яго можна досыць надзейна праверыць: для гэтага трэба значна (напрыклад, у 2-3 разы) павялічыць (або паменшыць) час затрымкі пры паказе старонкі і паглядзець на колькасць адмоваў (колькасць карыстальнікаў, якія закрылі старонку адразу пасля заходу на сайт) і на колькасць пастаянных наведвальнікаў. Калі пры моцным павелічэнні (або памяншэнні) затрымкі пры загрузцы сайта колькасць карыстальнікаў практычна не змянілася, значыць, старонка ўжо загружаецца у дапушчальным дыяпазоне. Калі ж колькасць карыстальнікаў зведала бачныя змены, то, такім чынам, з часам загрузкі сайта трэба нешта рабіць.
Карыстальнікі шырокапалоснага доступу чакаюць большай хуткасці загрузкі, пры гэтым карыстальнікам з менш хуткасным доступам даводзіцца чакаць значна даўжэй. Па меры таго як высакахуткасны доступ пранікае ў масы, расце таксама і памер старонкі. Карыстальнікі адчуваюць псіхалагічныя і фізіялагічныя праблемы пры ўзаемадзеянні з «павольнымі» вэб-старонкамі, адчуваюць раздражненне, калі не могуць завяршыць свае задачы, і натхненне пры працы з хуткімі сайтамі.
1.3. Стадыі загрузкі старонкі
Мал. 1. 2. Стадыі загрузкі старонкі У якасці асноўных праблемных месцаў пры загрузцы старонкі любога вэб-рэсурсу можна вылучыць чатыры ключавых моманту.
Предзагрузка - з'яўленне старонкі ў браўзэры карыстача. Пасля некаторага часу чакання загрузкі пры заходзе на вэб-рэсурс у карыстача ў браўзэры адлюстроўваецца намаляваная старонка. У гэты момант, верагодна, на старонцы адсутнічаюць малюнкі і, хутчэй за ўсё, не цалкам функцыянуе JavaScript-логіка.Інтэрактыўная загрузка - з'яўленне інтэрактыўнасці (і анімацыі) у загружанай вэб-старонкі. Звычайна ўся кліенцкая логіка ўзаемадзеяння даступная адразу пасля першапачатковай загрузкі старонкі (стадыя 1), аднак у некаторых выпадках (пра іх гаворка пойдзе крыху далей) падтрымка гэтай логікі можа (і павінна, на самай справе) трохі пазніцца па часе ад з'яўлення асноўнай карцінкі ў браўзэры карыстача.
Поўная загрузка старонкі. Старонка цалкам з'явілася ў браўзэры, на ёй прадстаўлена ўся заяўленая інфармацыя, і яна практычна гатовая да далейшых дзеянняў карыстальніка.
Пост-загрузка старонкі. На дадзенай стадыі цалкам загружаная старонка можа (у нябачным для карыстальніка рэжыме) ажыццяўляць загрузку і кэшаванне некаторых рэсурсаў або кампанентаў. Яны могуць спатрэбіцца карыстачу як пры пераходзе на іншыя старонкі дадзенага сайта, так і для адлюстравання якіх-небудзь анімацыйных эфектаў або дадання функцыяналу дзеля зручнасці выкарыстання.
Для большасці сайтаў на дадзены момант варта адрозніваць толькі предзагрузку (у якую па змаўчанні ўключаецца інтэрактыўная загрузка) і поўную загрузку старонкі. Пост-загрузка, да няшчасця, зараз выкарыстоўваецца вельмі мала.
расстаўляем прыярытэты
Аптымізацыя хуткасці загрузкі вэб-старонкі сканцэнтравана на двух ключавых аспектах: паскарэнне предзагрузки і паскарэнне асноўны загрузкі. Усе асноўныя метады сфакусаваныя менавіта на гэтым, таму што «загрузка» вэб-старонкі ўспрымаецца карыстальнікамі як нешта якое знаходзіцца пасярэдзіне гэтых двух стадый.
У ідэале загрузка старонкі для карыстальніка павінна заканчвацца адразу пасля предзагрузки, аднак дамагчыся гэтага вельмі складана, і апраўдана гэта далёка не ва ўсіх выпадках. Больш падрабязна пра метады экстрэмальнай аптымізацыі будзе расказана ў канцы чацвёртай кіраўніка.
вузкія месцы
Першая і другая стадыі загрузкі з'яўляюцца найбольш праблемнымі аспектамі пры аналізе прадукцыйнасці. Гэта цалкам зразумела: загрузка першапачатковага HTML-файла, роўна як і CSS- / JavaScript-файлаў ідзе ў адну плынь, - і на першае месца выходзіць памяншэнне колькасці запытаў пры загрузцы.
Як толькі вузкае месца пераадолена (у ідэале, у нас павінен быць адзін-адзіны файл, які атрымлівае карыстальнік) і ў браўзэры старонка адлюстравалася, мы можам пачаць запытваць з сервера ўсе астатнія рэсурсы. Самае галоўнае, што гэта можна рабіць з дапамогай дзясяткаў дадатковых злучэнняў (як гэтага дамагчыся, распавядаецца ў пятай чале), бо ў браўзэры ўжо адбылася падзея гатоўнасці дакумента да далейшых дзеянняў.
Мы можам наладзіць логіку кэшавання, паслядоўную загрузку JavaScript-модуляў або нават пост-загрузку стылявых правілаў. Усё гэта ўжо будзе слаба адбівацца на фактычнай хуткасці першапачатковай загрузкі: карыстальнік бачыць старонку ў браўзэры, можа з ёй ўзаемадзейнічаць (хай нават спачатку і не ў поўным аб'ёме), для яго яна ўжо загрузілася (праўда, толькі з псіхалагічнага, а не з тэхнічнага боку ).
Але ўсе гэтыя прыёмы могуць як паскорыць загрузку наступных для карыстальніка старонак, так і ўпарадкаваць саму пост-загрузку. Як дасягнуць гэтага эфекту і як размеркаваць файлы і кліенцкую логіку паміж стадыямі загрузкі старонкі, расказана ў чацвёртай чале.
1.4. Кліенцкая і серверная аптымізацыя: падабенства і адрозненні
Кліенцкая аптымізацыя аперуе двума асноўнымі прынцыпамі: менш дадзеных і менш злучэнняў. Але менавіта гэтыя прынцыпы дапамагаюць паменшыць нагрузку на сам сервер. Давайце паглядзім, як гэта адбываецца і як перанесці частку сервернай нагрузкі на кліенцкі браўзэр.
Кэшаванне ў аснову
Сервер можа кіраваць станам кэша кліенцкага браўзэра, па-першае, праз загаловак Cache-Control (і яго атрыбуты max-age, pre-check, post-check), які можа паказваць на прамежак часу, на працягу якога адпаведны файл варта захоўваць на дыску і ня запытваць з сервера. Рэкамендуецца для ўсіх статычных файлаў выстаўляць максімальны час жыцця кэша і фарсіраваць яго абнаўленне ў карыстальніка праз змяненне URL рэсурсу (з дапамогай RewriteRule альбо GET-параметру).
Па-другое, станам кліенцкага кэшу кіраваць праз загалоўкі ETag і Last-Modified, якія ставяць у адпаведнасць кожнаму файлу унікальны ідэнтыфікатар, зменлівы пры змене файла, - своеасаблівая лічбавы подпіс або хэш. Пры гэтым серверу трэба не перасылаць файл зноўку, а толькі адказаць статус-кодам 304 на запыт браўзэра, калі файл не змяніўся з моманту апошняга запыту. У выніку сам файл не перасылаецца, злучэнне (і сокет) вызваляецца хутчэй, і рэсурсы сервера таксама эканомяцца.
Больш падрабязна пра кэшаванні распавядаецца ў трэцяй чале.
Менш запытаў - лягчэй серверу
Выкарыстоўваючы аб'яднанне файлаў, мы не прымушаем сервер абменьвацца з браўзэрам загалоўкамі для перадачы, напрыклад, некалькіх табліц стыляў - значна больш эканамічным будзе іх аб'яднаць у адну. Пры гэтым браўзэр хутчэй атрымае усю неабходную інфармацыю і хутчэй вызваліць такі важны рэсурс, як злучэнне.
Нароўні з аб'яднаннем тэкставых файлаў не варта грэбаваць і аб'яднаннем малюнкаў. Калі ўлічваць, што сучасныя браўзэры могуць ўсталёўваць некалькі дзясяткаў адначасовых злучэнняў з серверам для атрымання статычных файлаў (і 80% з іх - гэта менавіта малюнкі), то эканомія ад выкарыстання CSS Sprites, Image Map або data: URI падыходу разлічваецца вельмі проста. У некаторых выпадках атрымоўваецца паменшыць лік злучэнняў браўзэра з серверам для загрузкі адной HTML-старонкі ў 8-10 разоў.
Аб'яднанне файлаў разглядаецца ў чацвёртай чале.
Архіваваць і кэшаваць на сэрвэры
Як паказалі праведзеныя даследаванні, gzip-сціск тэкставага файла "на ляту" ў 95-98% выпадкаў дазваляе скараціць час на перадачу файла браўзэру. Калі захоўваць Архівавана копіі файлаў на серверы (у памяці proxy-сервера або проста на дыску), то злучэнне ў агульным выпадку атрымоўваецца вызваліць у 3-4 разы хутчэй.
У выпадку высоконагруженных сервераў з дынамічнымі HTML-файламі gzip таксама можа быць прымяняецца. Тут варта арыентавацца на мінімальную ступень сціску, бо працэсарныя выдаткі пры гэтым растуць лінейна, а памер памяншаецца толькі лагарыфмічнай.
Аб сьціску распавядае наступная кіраўнік.
Хто ў каго на службе?
Пасля праведзенага агляду тэхналогій можа здацца, што кліенцкая аптымізацыя з'яўляецца толькі складнікам часткай сервернай. Аднак гэта не так: пры пабудове высокапрадукцыйных вэб-прыкладанняў павінен прысутнічаць і кліенцкі, і серверны падыход. У гэтым выпадку можна казаць пра перасякаліся галіне адказнасці, але ніяк не пра прэваліраваньня адной логікі над іншай.
Калі справа даходзіць да ўзаемадзеяння «кліент-сервер», трэба памятаць аб усіх аспектах аптымізацыі. І ў кліенцкай складнікам ёсць свая, вылучаная вобласць адказнасці. Яна знаходзіцца ў акне браўзэра - гэта вэб-старонка, якая загружаецца у карыстача і з якой ён ўзаемадзейнічае.
1.5. Прымяненне ў распрацоўцы прыкладанняў
Карыстальнікі звычайна не ведаюць, якія падыходы прымяняюцца пры распрацоўцы, як наладжаны сервер, якія кліенцкія і серверныя сродкі распрацоўкі выкарыстоўваюцца. Для іх толькі важна, наколькі сайт карысны, зручны і хуткі. Задача ж вэб-распрацоўнікаў заключаецца ў тым, каб не дастаўляць карыстальніку лішніх нязручнасцяў, радаваць яго і тым самым стымуляваць продажу, якія ідуць праз сайт, або колькасць рэкламных паказаў і клікаў па іх. Ніжэй распавядаецца, як можна арганізаваць стварэнне вэб-прыкладанні, арыентуючыся на самыя важныя аспекты кліенцкай аптымізацыі.Этап 1: Дастаўка інфармацыі і афармлення
На гэтым этапе распрацоўшчыкі павінны зрабіць усё магчымае, Каб не замарудзіцца хуткасць загрузкі старонкі. Фактычна ідзе гаворка абса паскарэнні Пяршай стадыі загрузкі. Найбольш важнымі метадамі тут з'яўляецца сціск (gzip) тэкставых файлаў І аб'яднанне файлаў стыляў (CSS). Для CSS- і JavaScript-файлаў магчыма ўжываць статычнае архіваванне (без неабходнасці архіваваць кожны раз гэтыя файлы "на ляту"; гэтаму прысвечана другая кіраўнік). Пры загрузцы старонкі браўзэр запытае ўсе CSS-файлы, абвешчаныя ў head старонкі, паслядоўна. Таму кожны файл дадае затрымку ў загрузцы, роўную часу запыту да сервера (нават калі выказаць здагадку, што усталёўванае злучэнне keep-alive і нам не трэба здзяйсняць усе TCP / IP-працэдуры, - у адваротным выпадку мы эканомім значна больш). Для файлаў скрыптоў рэкамендуецца прымяніць альбо таксама аб'яднанне, альбо наогул вынесці іх у пост-загрузку (падрабязней пра гэта расказана ў сёмы чале). Вынік першага этапу - гэта дастаўлены і аформлены HTML. І выдаткі на дастаўку JavaScript зведзены да мінімуму (на гэтым этапе ён толькі замінае, бо запавольвае адлюстраванне асноўнага змесціва старонкі). Час ад пачатку да завяршэння загрузкі такой старонкі пры ўключаным і выключаным JavaScript (пры вынясенні яго ў пост-загрузку) фактычна будзе аднолькавым. Гэта і будзе выйгрышам ў хуткасці загрузкі!Этап 2: Кэшаванне файлаў афармлення і паралельныя запыты
На дадзеным этапе распрацоўшчыкі павінны забяспечыць хуткую загрузку іншых старонак сайта (калі наведвальнік вырашыць туды перайсці). Гэты этап павінен праходзіць паралельна з першым. Настройка Кэшуйце загалоўкаў досыць трывіяльная. Некалькі складаней наладзіць працэс распрацоўкі для своечасовага скіду кэша. Усе гэтыя пытанні раскрываюцца ў трэцяй чале. Адно або некалькі дадатковых люстэркаў для выдачы статычных рэсурсаў лёгка наладжваюцца ў канфігурацыі, аднак укараніць гэта ў схему публікацыі змяненняў значна складаней. Звычайна гэта робяць ужо пасля распрацоўкі макетаў старонак. Лік дадатковых хастоў варта напрамую з ліку статычных файлаў (звычайна малюнкаў), таму трэба вызначыцца з імі на этапе аўтаматызацыі працэсу публікацыі. Аб паралельных запытах распавядаецца ў пятай чале. CSS Sprites досыць працаёмкія ў аўтаматычнай «злепванню», таму іх ўкараняюць звычайна на першым этапе (пры стварэнні макета старонак). Пры выкарыстанні метаду data: URI на першым этапе пра іх можна забыцца, таму што аўтаматызаванае рашэнне проста ў рэалізацыі і не патрабуе ад вярстальніка асобных тэхналагічных спазнанняў. Пра гэта можна прачытаць у чацвёртай чале.Этап 3: Жыццё пасля загрузкі старонкі
Мэтай дадзенага этапу з'яўляецца стварэнне розных апрацоўшчыкаў падзей, якія павінны ўзаемадзейнічаць з карыстальнікам. Гэта могуць быць і усплывальныя падказкі, і падгрузка дадзеных з сервера, і проста анімацыя. Усё гэта можна назваць «ажыўленнем» старонкі. Кажуць, што часам «грам бачнасці важней кілаграма сутнасці» - гэта як раз пра JavaScript. Бо менавіта на ім можна рэалізаваць механізмы, якія спрашчаюць дзеянні карыстальніка; можна зрабіць шмат розных візуальных эфектаў, якія падкрэсліваюць афармленне, зручнасць і карыснасць сайта (а фактычна - узмацніць і сфакусаваць усю працу, якую зрабілі распрацоўшчыкі на папярэдніх этапах). Да гэтага моманту мы павінны мець аформленую HTML-старонку, на якой усе спасылкі і формы абавязаны працаваць без JavaScript (як гэтага дамагчыся, як аддзяліць ўяўленне старонкі ад яе функцыянавання, распавядаецца ў сёмы чале ў раздзеле пра «ненадакучлівы» JavaScript). У нас павінны быць гатовыя серверныя інтэрфейсы для AJAX-запытаў; структура старонкі павінна быць такі, каб для аналагічных кавалкаў HTML-кода не даводзілася рэалізоўваць аналагічныя, але не аднолькавыя кавалкі JavaScript-кода. Хутчэй за ўсё, павінны быць створаныя шаблоны старонак, дзе відаць, як будзе выглядаць старонка пасля нейкага дзеяння карыстальніка (звычайна спецыяліст па зручнасці выкарыстання стварае макеты). Каб не памяншаць хуткасць дастаўкі кантэнту і афармлення, JavaScript-файлы (лепш за ўсё, вядома, адзін JavaScript-файл; некалькі файлаў павінны выкарыстоўвацца толькі пры вялікай складанасці кліенцкага інтэрфейсу) павінны быць падлучаныя перад закрыццём тэга body (а ў ідэале - вынесеныя менавіта ў пост -загрузку). Задача па забеспячэнні ўзаемадзеяння карыстальніка з інтэрфейсам сайта зводзіцца да выканання наступных дзеянняў:знайсці DOM-элементы, якія патрабуюць «ажыўлення» (далей - кампаненты);
вызначыць, што гэта за кампанент;
забяспечыць падключэнне неабходнага кода JavaScipt;
сачыць за чарговасцю падлучэння файлаў;
не дазваляць некалькіх загрузак аднаго файла.
Ўсё гэта наўпрост вынікае з канцэпцыі «ненадакучлівага» JavaScript, якая апісана ў сёмы чале. Пошук неабходных DOM-элементаў павінен нам даць спіс назваў JavaScript-кампанентаў. Назвы кампанентаў павінны адназначна адпавядаць назвах файлаў на сэрвэры, у якіх змяшчаецца код для іх. Таксама нам можа спатрэбіцца загрузіць некаторыя дадатковыя CSS-правілы для знойдзеных кампанентаў (у выпадку невялікай колькасці CSS-кода разумна будзе ўключыць яго ў асноўны файл) дзеля нейкіх візуальных эфектаў, якія можна прапусціць на першым этапе загрузкі. Напрыклад, усе эфекты па змене малюнка пры навядзенні мышы забяспечваюцца праз CSS-правілы і тэхніку CSS Sprites. Спіс назваў кампанент можна аб'яднаць у адзін запыт да сервера. У выніку на стадыі пост-загрузкі павінны ажыццяўляцца запыты да файлаў выгляду static.site.net/jas/componentName1.css;componentName2.css і static.site.net/jas/componentName1.js; c omponentName2.js. У дадзенага падыходу ёсць два недахопу: У тэчцы / jas / (якую мы, напрыклад, выкарыстоўваем для кэшавання найбольш частых варыянтаў падлучэння модуляў) праз некаторы час можа апынуцца вельмі шмат файлаў, што тэарэтычна можа паменшыць час доступу да іх на серверы. Часам на старонцы можа апынуцца вельмі шмат кампанент, прычым так шмат, што даўжыня імя запытанага аб'яднанага файла пераваліць за магчымасці файлавай сістэмы (напрыклад, 255 знакаў у Ext3) - у гэтым выпадку спатрэбіцца разбіць адзін запыт на некалькі паслядоўных.Этап 4: Папярэджваем дзеянні карыстальніка
Калі пасля наведвання галоўнай старонкі большасць карыстальнікаў трапляюць ўнутр сайта, то лягічна будзе пасля поўнай загрузкі галоўнай старонкі запытваць стылі і скрыпты, якія прымяняюцца на іншых старонках сайта. Для карыстальніка гэта выльецца ў невялікае павелічэнне трафіку (пры выкарыстанні сціску тэкставая інфармацыя складае 10-20% ад аб'ёму графікі), аднак ў цалкам прыкметнае паскарэнне загрузкі наступных старонак. Аналагічна можна разгледзець і предзагрузку некаторых найбольш часта выкарыстоўваюцца малюнкаў, якія адсутнічаюць на галоўнай старонцы, і дадатковых JavaScript-модуляў, якія прымяняюцца на бягучай старонцы для дадатковага функцыяналу і ня запытваюцца пры першай загрузцы старонкі (напрыклад, адказваюць за першапачаткова скрытыя блокі). Натуральна, што за балансаванне трэцяй i чацвёртай стадый адказвае ўжо JavaScript-распрацоўшчык і фронтенд-архітэктар - бо менавіта ў зоне адказнасці апошняга знаходзіцца хуткасць загрузкі старонкі.1. Што такое кліенцкая аптымізацыя?
Хто ў каго на службе?
