Да ли текстуални прегледници смањују мрежни промет?
Нема сумње да су данашње веб странице пуне богатог садржаја и да користе више пропусног опсега како би се у потпуности учитале, али да ли би се користио текстуални претраживач умјесто графичког корисничког интерфејса који би направио значајну разлику у смањењу мрежног промета? Данашњи пост СуперУсер К&А има одговоре на занимљиво питање читатеља.
Данашња сесија питања и одговора долази нам захваљујући СуперУсер-у - подјела Стацк Екцханге-а, груписане од стране заједнице веб-локација за питања и одговоре.
Линк Бровсер сцреенсхот цоуртеси оф Википедиа.
Питање
Читач суперкорисника Паулб жели да зна да ли текстуални прегледачи заправо могу да смање мрежни саобраћај:
Да ли текстуални прегледачи као што су Линк, Линкс и ЕЛинкс троше мање пропусног опсега од претраживача заснованих на корисничком интерфејсу као што су Фирефок, Цхроме и Интернет Екплорер?
Претпостављам да нема смањења промета. Разлог за то је да мислим да текстуални претраживач преузима читаву страницу онако како је нуди сервер. Свако поједностављење или смањење виџета страница се врши локално.
Можда је дошло до смањења промета јер већина текстуалних претраживача неће извршити скрипте страница или фласх датотеке, што може проузроковати већи промет.
Може ли текстуални прегледници направити значајну разлику у смањењу мрежног саобраћаја?
Одговор
Доприносник СуперУсер-а гроностај има одговор за нас:
Веб сервер не шаље цео сајт, већ документе које претраживачи захтевају. На пример, када приступите гоогле.цом, претраживач упита веб сервер за документ гоогле.цом. Веб сервер обрађује захтев и шаље назад неки ХТМЛ код.
Затим прегледач проверава шта је веб сервер послао. У овом случају, то је ХТМЛ веб страница, тако да анализира документ и тражи референциране скрипте, стилске табеле, слике, фонтове, итд..
У овој фази прегледач је завршио са преузимањем оригиналног документа, али још увек није учитао наведене документе. Може изабрати да то учини или да их прескочи. Редовни претраживачи покушаће да преузму све референтне документе за најбоље искуство гледања. Ако имате блокатора огласа (као Адблоцк Плус) или додатак за приватност (као Гхостери или НоСцрипт), онда може блокирати и неке ресурсе.
Затим претраживач преузима референтне документе једну по једну, сваки пут тражећи веб сервер експлицитно за један ресурс. У нашем Гоогле примјеру, прегледник ће пронаћи сљедеће референце (само да наведем неколико њих):
- хттпс://ввв.гоогле.цом/имагес/српр/лого11в.пнг (Гоогле Лого)
- хттпс://ввв.гоогле.цом/тектинпутассистант/тиа.пнг (икона тастатуре)
- хттпс://ссл.гстатиц.цом/гб/имагес/и1_3д265689.пнг (Неке комбиноване слике, трик којим се смањује број захтева за прегледач.)
Стварне датотеке могу бити различите за различите кориснике јер се прегледници и сесије могу мијењати током времена. Текстуални претраживачи не преузимају слике, Фласх датотеке, ХТМЛ5 видео, итд., Тако да преузимају мање података.
@НатханОсман је добар коментар у коментарима. Понекад се мале слике директно уграђују у ХТМЛ документе иу тим случајевима их није могуће избећи. Ово је још један трик којим се смањује број захтева. Они су, међутим, веома мали, иначе је оптерећење кодирања бинарне датотеке у басе64 превелико. Постоји неколико таквих слика на гоогле.цом (басе64 кодирана величина / декодирана величина):
- 19 × 11 пиксела Икона тастатуре (106 бајтова / 76 бајтова)
- Иконица микрофона 28 × 38 пиксела (334 бајтова / 248 бајтова)
- 1 × 1 пиксел Транспарент ГИФ (62 бајта / 43 бајта) Појављује се на картици Гоогле Тоолс за ресурсе о алаткама за уређаје, али је нисам могао наћи у изворном коду (вероватно касније доданој помоћу ЈаваСцрипт-а).
- 1 × 1 пиксел Оштећени ГИФ фајл који се појављује два пута. Његова сврха је за мене мистерија.
Имате ли нешто да додате објашњењу? Звучи у коментарима. Желите ли прочитати више одговора од других технолошки паметних Стацк Екцханге корисника? Погледајте цео дискусију овде.
