Задаволены
- 01. Цана запаволення
- 02. Сеткі дастаўкі кантэнту
- 03. Далейшыя прыёмы
- 04. Меркаванні па папярэдняй атрыманні і папярэдняй рэндэрынгу
- 05. Загрузка змесціва Ajax
- Спадабалася гэта? Прачытайце гэтыя!
- Неабходныя веды: Прамежкавы CSS і JavaScript, базавы HTML5
- Патрабуецца: Сайт для паскарэння
- Час праекта: Вельмі залежыць ад вэб-сайта
Гэты артыкул упершыню з'явіўся ў нумары 231 часопіса .net
Хуткасць павінна быць важнай для кожнага сайта. Агульнавядомы факт, што Google выкарыстоўвае хуткасць сайта ў якасці паказчыка рэйтынгу для вынікаў пошуку. Гэта гаворыць нам пра тое, што наведвальнікі аддаюць перавагу хуткім вэб-сайтам - не дзіўна!
Якаб Нільсэн пісаў у 1993 г. пра тры межы часу водгуку; нягледзячы на тое, што даследаванні старыя паводле Інтэрнэт-стандартаў, за апошнія 19 гадоў наша псіхалогія асабліва не змянілася. Ён заяўляе, што калі сістэма адкажа менш чым за 0,1 секунды, яна будзе ўспрымацца імгненна, у той час як адказы, якія перавышаюць адну секунду, дазваляюць карыстальніцкаму патоку думак заставацца бесперабойным. Нагрузка вэб-старонкі за 0,1 секунды, верагодна, немагчыма; каля 0,34 секунды ўяўляе сабой лепшы час загрузкі Google UK, таму гэта служыць больш рэалістычным (хаця і амбіцыйным) эталонам. Загрузка старонкі дзесьці ад 0,34 да 1 секунды дасягальная і важная.
01. Цана запаволення
Такія мэты маюць рэальны ўплыў на ваш сайт і бізнес. Марыса Майер ад Google распавяла ў 2006 годзе пра эксперымент, у якім колькасць вынікаў, якія вяртае пошукавая машына, была павялічана да 30. Гэта замарудзіла час загрузкі старонкі прыблізна на 500 мс, і гэтаму прыпісана 20-адсоткавае падзенне наведвальнасці. Тым часам Amazon штучна затрымліваў загрузку старонкі з крокам у 100 мс і выявіў, што "нават вельмі невялікія затрымкі прывядуць да істотнага і дарагога падзення даходаў".
Іншыя неспрыяльныя асацыяцыі, звязаныя з павольнымі вэб-сайтамі, ўключаюць зніжэнне даверу, ніжэйшае ўспрыманне якасці і разгляд сайта як менш цікавага і прывабнага. Павелічэнне расчаравання карыстальнікаў і павышэнне артэрыяльнага ціску - гэта яшчэ два наступствы, якія мы, напэўна, адчувалі ў пэўны момант! Але як мы можам пераканацца, што нашы вэб-сайты загружаюцца досыць хутка, каб пазбегнуць гэтых праблем?
Адна з першых рэчаў, на якую трэба звярнуць увагу, - гэта памер HTML-кода. Гэта, верагодна, адна з самых недагледжаных абласцей, магчыма, таму, што людзі мяркуюць, што гэта ўжо не так актуальна для сучасных шырокапалосных злучэнняў. Некаторыя сістэмы кіравання кантэнтам досыць ліберальныя, паколькі яны атрымліваюць вялікую колькасць - адна з прычын, чаму можа быць лепш самастойна ствараць свае сайты.
У якасці арыентыру вы павінны лёгка змясціць большасць старонак у 50 КБ HTML-кода, і калі вам менш за 20 КБ, у вас усё атрымліваецца вельмі добра. Відавочна, што ёсць выключэнні, але гэта даволі добрае эмпірычнае правіла.
Таксама важна мець на ўвазе, што зараз людзі часцей праглядаюць поўныя вэб-сайты на мабільных прыладах. Адрозненні ў хуткасці паміж сайтамі, якія праглядаюцца з мабільнага тэлефона, часцей становяцца больш прыкметнымі, таму што хуткасць перадачы ў іх больш нізкая, чым правадныя злучэння. Два канкуруючыя вэб-сайты з розніцай памеру ў 100 Кб на старонцы могуць азначаць больш чым адну секунду розніцы ў часе загрузкі ў некаторых павольных мабільных сетках - гэта далёка ў вобласць "перапыненага патоку думак", указаную Якабам Нільсенам. Трымерны, больш хуткі вэб-сайт будзе значна менш расчаравальным для прагляду, даючы відавочную канкурэнтную перавагу ў параўнанні з больш тлустымі вэб-сайтамі і ідучы доўгі шлях да заахвочвання паўторных наведванняў.
Адной з важных асаблівасцей большасці вэб-сервераў з'яўляецца магчымасць абслугоўвання HTML у сціснутым фармаце. Паколькі HTML па сваёй прыродзе змяшчае шмат паўтаральных дадзеных, гэта робіць яго ідэальным кандыдатам на сціск. Напрыклад, 18,1 КБ HTML адной хатняй старонкі памяншаецца да 6,3 КБ пры падачы ў сціснутым фармаце. Гэта эканомія на 65 адсоткаў! Алгарытмы сціскання павялічваюць эфектыўнасць, чым большы аб'ём тэксту ім даводзіцца працаваць, таму пры большых HTML-старонках вы ўбачыце большую эканомію. Старонка ў 138,1 тысячы на папулярным форуме памяншаецца да 25,7 тысячы пры сцісканні, што дазваляе зэканоміць больш за 80 адсоткаў, што можа значна палепшыць агульны час перадачы рэсурсаў.
Фактычна няма негатываў у абслугоўванні HTML у такой форме; Кожны павінен уключыць яго для ўсяго свайго зместу HTML. Некаторыя вэб-серверы маюць розныя налады для сціскання статычнага і дынамічна стваранага змесціва, таму варта пераканацца, што вы служыце для сціснутага змесціва для абодвух, калі гэта магчыма.
02. Сеткі дастаўкі кантэнту
Сеткі дастаўкі кантэнту (вядомыя як CDN) таксама могуць значна палепшыць час загрузкі вашага сайта. CDN - гэта сукупнасць сервераў, распаўсюджаных па ўсім свеце, на якіх захоўваюцца копіі вашага змесціва. Калі карыстальнік запытвае малюнак з вашага вэб-сайта, які размешчаны на CDN, сервер у CDN, геаграфічна бліжэйшы да карыстальніка, будзе выкарыстоўвацца для абслугоўвання малюнка.
Даступна шмат паслуг CDN. Некаторыя з іх вельмі дарагія, але заяўляюць, што яны прапануюць лепшую прадукцыйнасць, чым больш танныя CDN. Бясплатныя паслугі CDN таксама пачалі з'яўляцца, і, магчыма, варта паэксперыментаваць, каб даведацца, ці могуць яны палепшыць прадукцыйнасць вашага сайта.
Адзін важны момант пры выкарыстанні CDN - пераканацца, што вы правільна яго ўсталявалі, каб не страціць значэнне SEO. Магчыма, вы атрымліваеце шмат трафіку ад малюнкаў, размешчаных у вашым дамене, у залежнасці ад характару вашага сайта, і, перамясціўшы іх на знешні дамен, гэта можа негатыўна паўплываць на ваш трафік. Паслуга Amazon S3 дазваляе накіроўваць субдамен на яго CDN, што з'яўляецца вельмі пераважнай функцыяй у CDN.
Абслугоўванне змесціва ў іншым дамене (напрыклад, CDN) або паддамене вашага ўласнага дамена, якое не ўсталёўвае файлы cookie, мае яшчэ адно галоўнае перавага. Калі файл cookie усталяваны ў дамене, аглядальнік адпраўляе дадзеныя cookie з кожным запытам на кожны рэсурс у гэтым самым дамене. Часцей за ўсё дадзеныя cookie не патрабуюцца для статычнага змесціва, такога як выявы, CSS-файлы ці файлы JavaScript. Частата загрузкі вэб-карыстальнікаў часта значна меншая, чым даступная хуткасць загрузкі, што ў некаторых выпадках можа прывесці да значнага запаволення часу загрузкі старонкі. Выкарыстоўваючы іншае даменнае імя для абслугоўвання вашага статычнага змесціва, браўзэры не будуць адпраўляць гэтыя непатрэбныя дадзеныя печыва, паколькі яны маюць строгую палітыку міждаменнага выкарыстання. Гэта можа значна паскорыць час запыту для кожнага рэсурсу.
Файлы cookie на вэб-сайтах таксама могуць займаць большую частку запыту HTTP; 1500 байтаў складае каля найбольш часта выкарыстоўванага ліміту аднаго пакета для вялікіх сетак, таму, калі вы можаце захаваць свае HTTP-запыты пад гэтым лімітам, увесь HTTP-запыт павінен быць адпраўлены адным пакетам. Гэта можа прапанаваць паляпшэнне часу загрузкі старонкі. Google рэкамендуе, каб вашы файлы cookie мелі памер менш за 400 байт - гэта значна спрыяе захаванню HTTP-запытаў вашых вэб-сайтаў у межах аднаго пакета / 1500 байтаў.
03. Далейшыя прыёмы
Ёсць і іншыя, больш простыя ў рэалізацыі метады, якія могуць прынесці вялікую карысць хуткасці вашага сайта. Адным з іх з'яўляецца размяшчэнне файлаў JavaScript у канцы вашага HTML-дакумента, непасрэдна перад закрыццём тэга цела, таму што аглядальнікі маюць абмежаванні на колькасць рэсурсаў, якія яны могуць загружаць паралельна з аднаго хоста.
Арыгінальная спецыфікацыя HTTP 1.1, напісаная ў 1999 г., рэкамендуе браўзэрам загружаць толькі два рэсурсы паралельна з кожнага імя хаста. Але сучасныя браўзэры па змаўчанні маюць абмежаванне каля шасці. Калі ваша вэб-старонка мае больш за шэсць знешніх рэсурсаў (напрыклад, выявы / файлы JavaScript / CSS), яна можа прапанаваць вам палепшаную прадукцыйнасць для абслугоўвання іх з некалькіх даменаў (напрыклад, паддамена вашага галоўнага даменнага імя альбо CDN) для забеспячэння аглядальніка не дасягнуў максімальнага ліміту на паралельныя загрузкі.
Замест таго, каб разбіваць некалькі запытаў на розныя дамены, вы можаце разгледзець магчымасць іх аб'яднання. Кожны HTTP-запыт звязаны з накладнымі выдаткамі. Дзясяткі малюнкаў, такіх як абразкі на вашым вэб-сайце, якія служаць асобнымі рэсурсамі, ствараюць шмат марнатраўных выдаткаў і прыводзяць да запаволення вашага веб-сайта, часта значнага. Аб'яднаўшы выявы ў адзін малюнак, вядомы як "ліст спрайтаў", вы можаце паменшыць колькасць патрэбных запытаў. Для адлюстравання выявы вы вызначаеце яго ў CSS, усталяваўшы шырыню і вышыню элемента ў адпаведнасці з выявай, якую вы хочаце адлюстраваць, а затым усталяваўшы фон на ліст спрайтаў. З дапамогай фон-пазіцыя уласцівасць мы можам перамясціць фонавы ліст спрайтаў у становішча, каб ён з'явіўся на вашым вэб-сайце ў выглядзе меркаванага малюнка.
Лісты спрайтаў таксама прапануюць іншыя перавагі. Калі вы выкарыстоўваеце выявы навядзення мышы, захоўванне іх на адным і тым жа лісце спрайтаў азначае, што пры запуску навядзення мышы затрымкі няма, таму што выява навядзення мышы ўжо загружана ў ліст спрайтаў! Гэта можа значна палепшыць успрыманы карыстальнікам час загрузкі і стварыць нашмат больш спагадны веб-сайт.
Указанне памераў любых іншых малюнкаў у img /> тэгі таксама з'яўляецца важным фактарам павелічэння часу ўспрымання загружанай старонкі. Распрацоўшчыкі звычайна не вызначаюць шырыню і вышыню для выяваў на старонках. Гэта можа прывесці да павелічэння памеру старонкі пры скачванні (часткова) кожнага малюнка, што прымушае рэчы адчуваць сябе млява. Калі ўстаноўлены відавочныя памеры, браўзэр можа пакідаць месца для выявы па меры загрузкі, спыняючы змяненне памеру старонкі і часам значна паляпшаючы час успрымання карыстальнікам загрузкі.
Дык што мы яшчэ можам зрабіць, каб палепшыць гэта? Папярэдняя загрузка - адна з такіх функцый, даступная ў HTML5. Папярэдняя загрузка дазваляе загружаць старонкі і рэсурсы да таго, як карыстальнік іх сапраўды запытвае. У цяперашні час яго падтрымка абмежаваная Firefox і Chrome (з альтэрнатыўным сінтаксісам). Аднак яго прастата ўкаранення і карыснасць для паляпшэння ўспрыманага часу загрузкі вашай вэб-старонкі настолькі вялікая, што яе варта разгледзець.
! —Папярэдняя загрузка Firefox ->
спасылка rel = "prefetch" href = "http://www.example.com/page2.html">
! —Chrome Prerender ->
спасылка rel = "prerender" href = "http://www.example.com/page2.html">
! —Адна ў адзін радок ->
спасылка rel = "prefetch prerender" href = "http://www.example.com/page2.html">
Паміж паводзінамі паміж папярэдняй загрузкай і папярэдняй апрацоўкай існуе розніца ў паводзінах. Mozilla папярэдняя загрузка загрузіць рэсурс найвышэйшага ўзроўню для дадзенага URL-адраса, звычайна саму HTML-старонку, і на гэтым загрузка спыняецца. Google папярэдняя апрацоўка таксама загружае даччыныя рэсурсы, і па словах Google "робіць усю працу, неабходную для паказу старонкі карыстальніку, фактычна не паказваючы яе, пакуль карыстальнік не націсне".
04. Меркаванні па папярэдняй атрыманні і папярэдняй рэндэрынгу
Але выкарыстанне гэтай функцыі таксама мае важныя меркаванні. Калі вы папярэдне адрэндэрыруеце / папярэдне забярэце занадта шмат рэсурсаў альбо старонак, можа пацярпець увесь карыстацкі досвед прагляду; калі ў вас ёсць якія-небудзь статыстычныя дадзеныя на серверы, яны могуць стаць моцна скажонымі. Калі карыстальнік не націскае загадзя загружаны рэсурс і выходзіць з вашага сайта, трэкер статыстыкі можа ўлічыць наведванне як два прагляды старонкі, а не як сапраўдны. Гэта можа ўвесці ў зман для важных паказчыкаў, такіх як паказчык адмоваў.
Chrome папярэдняя апрацоўка ёсць яшчэ адно папярэджанне, пра якое павінны ведаць распрацоўшчыкі: папярэдне адлюстраваная старонка будзе выконваць JavaScript. Папярэдняя апрацоўка загружае старонку практычна сапраўды гэтак жа, як калі б карыстальнік націснуў на спасылку. Chrome не адпраўляе ніякіх спецыяльных загалоўкаў HTTP з папярэдняй апрацоўкай; аднак API бачнасці старонкі дазваляе вам адрозніць, ці папярэдне адлюстроўваецца старонка. Гэта зноў важна для любых іншых сцэнарыяў, якія вы выкарыстоўваеце, напрыклад, для рэкламных сцэнарыяў і трэкераў статыстыкі (Google Analytics ужо выкарыстоўвае API бачнасці старонак, таму вам не трэба пра гэта турбавацца). Няправільная апрацоўка гэтых актываў з дапамогай API бачнасці старонкі зноў прымушае рызыкаваць сказіць важныя паказчыкі.
Выкарыстанне папярэдняя загрузка і папярэдняя апрацоўка на пагінаваны змест, верагодна, бяспечная і карысная рэалізацыя - напрыклад, на вэб-старонцы падручнікаў, якая падзелена на некалькі раздзелаў. Асабліва па змесце, напрыклад, падручніках, напэўна, важна ўтрымліваць межы "бесперапыннага патоку думак" Нільсена.
Google Analytics таксама можа даць каштоўныя падказкі адносна таго, якія старонкі вы можаце захацець папярэдне адлюстраваць / папярэдне атрымаць. Выкарыстоўваючы аналіз на старонцы, вы можаце вызначыць, па якой спасылцы на вашай хатняй старонцы хутчэй за ўсё націснуць. У некаторых выпадках з дакладна вызначанымі заклікамі да дзеяння гэты працэнт можа быць надзвычай высокім - што робіць яго выдатным кандыдатам для папярэдняй загрузкі.
Папярэдняя атрыманне і папярэдняя рэндэрынг працуюць у міждаменных умовах - незвычайна ліберальная пазіцыя для аглядальнікаў, якія звычайна вельмі строга ставяцца да міждаменнага доступу.Аднак гэта, верагодна, працуе на карысць Google і Mozilla, таму што яны могуць стварыць для сваіх карыстальнікаў больш хуткі вопыт прагляду некалькімі спосабамі, прапаноўваючы значную канкурэнтную перавагу перад іншымі аглядальнікамі, якія пакуль не падтрымліваюць такія функцыі.
Папярэдняя атрыманне і асабліва папярэдняя рэндэрынг - гэта магутныя інструменты, якія могуць істотна палепшыць час успрымання загрузкі вэб-старонак. Але важна разумець, як яны працуюць, каб вопыт прагляду вашага карыстальніка не паўплываў непасрэдна і адмоўна.
05. Загрузка змесціва Ajax
Іншы спосаб палепшыць час загрузкі - выкарыстоўваць Ajax для загрузкі змесціва, у адрозненне ад загрузкі ўсёй старонкі зноў - больш эфектыўна, таму што гэта толькі загрузка змяненняў, а не шаблонны шаблон вакол кожнага змесціва.
Праблема вялікай загрузкі Ajax у тым, што гэта можа выглядаць ненатуральна. Пры няправільным выкананні кнопкі "Назад" і "Уперад" не будуць працаваць так, як чакае карыстальнік, і выкананне такіх дзеянняў, як закладкі старонак альбо абнаўленне старонкі, таксама паводзіць сябе нечакана. Пры распрацоўцы вэб-сайтаў пажадана не ўмешвацца ў такія паводзіны нізкага ўзроўню, як гэта - гэта вельмі бянтэжыць і непрыязна ставіцца да карыстальнікаў. Яскравым прыкладам гэтага могуць стаць намаганні некаторых веб-сайтаў па адключэнні правай кнопкі мышы на іх вэб-старонках як марная спроба прадухіліць парушэнне аўтарскіх правоў. Нягледзячы на тое, што рэалізацыя Ajax не ўплывае на працу браўзэра з тым самым намерам адключыць правую клавішу мышы, эфекты падобныя.
HTML5 дапамагае вырашаць гэтыя праблемы з дапамогай API гісторыі. Ён добра падтрымліваецца ў аглядальніках (акрамя Internet Explorer, хоць плануецца падтрымліваць у IE10). Працуючы з API гісторыі HTML5, мы можам загружаць змест у Ajax, адначасова мадэлюючы "звычайны" вопыт прагляду для карыстальнікаў. Пры правільным выкарыстанні кнопкі "Назад", "Наперад" і "Абнавіць" працуюць належным чынам. URL-адрас адраснага радка таксама можна абнавіць, гэта значыць, што закладкі цяпер зноў працуюць належным чынам. Пры правільнай рэалізацыі вы можаце пазбавіцца ад шматразовай загрузкі рэсурсаў, а таксама вытанчаныя спіны для браўзэраў з адключаным JavaScript.
Аднак ёсць вялікі мінус: у залежнасці ад складанасці і функцыі сайта, які вы спрабуеце стварыць, рэалізацыя загрузкі змесціва Ajax з дапамогай API гісторыі такім чынам, каб карыстальнік быў нябачны для карыстальніка, складаная. Калі на сайце таксама выкарыстоўваюцца сцэнарыі на баку сервера, вы таксама можаце двойчы пісаць рэчы: адзін раз у JavaScript і зноў на серверы, што можа прывесці да праблем і неадпаведнасцей. Удасканаленне можа быць цяжкім і працаёмкім, але калі гэта працуе па прызначэнні, вы можаце значна паменшыць рэальны і ўспрыняты час загрузкі для карыстальніка.
Пры спробе палепшыць хуткасць вашага сайта вы можаце сутыкнуцца з некаторымі невырашальнымі праблемамі. Як ужо згадвалася ў пачатку гэтага артыкула, не сакрэт, што Google выкарыстоўвае хуткасць старонкі ў якасці паказчыка ранжыравання. Гэта павінна стаць істотнай матывацыяй для паляпшэння хуткасці вашага сайта. Аднак вы можаце заўважыць, што пры выкарыстанні такіх рэсурсаў, як справаздачы пра хуткасць старонак Google Webmaster Tools, яны будуць паведамляць больш павольна, чым вы чакалі.
Прычынай могуць быць староннія сцэнарыі, такія як кнопкі "Падабаецца" на Facebook альбо кнопкі "Tweet". Час чакання можа складаць сотні мілісекунд, што можа значна пацягнуць час загрузкі ўсяго вашага сайта. Але гэта не аргумент для выдалення гэтых сцэнарыяў - напэўна, больш важна мець на сваім сайце кнопкі сацыяльных сетак. Гэтыя кнопкі звычайна займаюць адносна невялікія прасторы на вашай старонцы, таму не будуць істотна ўплываць на ўспрыняты час загрузкі наведвальніка - менавіта гэтага мы павінны ў першую чаргу ўлічваць пры аптымізацыі хуткасці.
Том Гулен - заснавальнік Scirra Ltd, стартапа, які стварае інструменты для стварэння гульняў: www.scirra.com/
Спадабалася гэта? Прачытайце гэтыя!
- Як стварыць прыкладанне
- Бясплатнае праграмнае забеспячэнне для графічнага дызайну, даступнае вам зараз!
- Загрузіце лепшыя бясплатныя шрыфты
- 101 падручнік па CSS і Javascript
