Пишу, по большей части, про историю, свою жизнь и немного про программирование.

У клиента дохлый канал?

В 1997 году, когда я впервые увидел веб через графический браузер (до этого у меня был опыт выхода в интернет через терминал на базе i80286 через текстовый браузер Lynx), у меня была выделенка, дело было в Казанском Государственном Университете и ещё очень долго я не знал что такое диалап и оплата за трафик.

Сейчас выделенки у большинства, но нередко встречается и такое, что клиент приходит на сайт через «дохлый канал» или с оплатой по трафику (например, через сотовый телефон).

Хорошо было бы об этом как-то узнать и не грузить клиенту лишние подробности в этом случае. Браузеры такое API не предоставляют (ещё бы, они и сами ничего не знают про канал), такую обобщённую информацию получить неоткуда. Но можно попытаться об этом догадаться. Эта запись — сборник моих сырых мыслей на эту тему.

Я вижу несколько путей.

  • можно замерить время за которое страницу удалось отдать клиенту целиком. У меня пока нет оформившихся мыслей о том как это делать и есть недостаток — когда мы узнали о том, что у клиента плохой канал, содержимое уже выдали, ничего поменять нельзя. Можно выдавать chunked-контент, как предлагал Сергей Чикуёнок, но первый кусок должен быть значительным
  • после загрузки страницы «пропинговать» хост. То есть обратиться через XHR на свой же сайт и замерить время ответа. Опять же, что делать с этими данными? Есть возможность в следующий раз показать более бедное содержимое, но следующий запрос может идти через другой канал. Возможное решение — сохранять IP-адрес запроса
  • смотреть с какого браузера клиент приходит, если это «Опера Мини», вероятнее всего, канал плохой или с оплатой
  • опять же «Опера», если включена функция «Опера Турбо» (определяется по IP-адресу клиента), клиент экономит трафик, значит канал с оплатой
  • проверить грузятся ли картинки, способов много, но данные получаем постфактум, после загрузки страницы. Логика та же — выключил картинки, экономит. Загрузку Flash контролировать смысла не имеет — многие выключают, чтобы не видеть рекламы
  • проверять не пришёл ли человек через канал сотового оператора (по IP-адресу). Безлимиток, которые бы не деградировали по скорости после какого-то лимита пока исчезающе мало, так что имеет смысл отдавать в этом случае «обеднённый» контент. Мобильные браузеры определять смысла не имеет — клиент может прийти через WiFi
  • в комментариях подсказали, что в «Андроидах» 2.2 и выше есть специальное
    API, чтобы определять способ подключения
  • ещё вариант из комментариев — определять модель телефона/планшета и по базе смотреть есть ли у него GSM/3G или WiFi
    Кто-нибудь ещё какие-то пути видит?
37 комментариев
bbambuk@gmail.com 2011

сделать наверху кнопку «у меня дохлый/дорогой канал» — пользователь жмяк, графика — пиу!
имхо, решать за пользователя какой контент отдавать — полный или обрезанный — зло. ненавижу когда мне, когда захожу с планшета на яндекс или на жж, пытаются без спроса подсунуть мобильную версию.

Олег Горбунов 2011

Комментарий для bbambuk@gmail.com:

Успел раньше меня, я тоже хотел об этом сказать.

SiMM (mr-simm.livejournal.com) 2011

имхо, решать за пользователя какой контент отдавать — полный или обрезанный — зло.

Зло, когда пользователь не имеет права выбора, если такое право есть, то при запоминании выбора пользователя ничего страшного в автоматическом определении — не вижу.

Евгений Степанищев (bolknote.ru) 2011

Комментарий для bbambuk@gmail.com:

сделать наверху кнопку «у меня дохлый/дорогой канал» — пользователь жмяк, графика — пиу!

Кнопка нужна, но за пользователя, конечно же, нужно решить изначально. Пользователь ленивый и ничего лишнего тыкать не будет :)

diaryea (diaryea.livejournal.com) 2011

Первый вариант: отдавать страницу в два захода, но в отличие от chunked transfer encoding в первом заходе выдавать полноценную страницу, после загрузки которой XHR за вторым куском. Поскольку это почти тот же chunked, то в порядке бреда можно развить идею до второго варианта.
Второй вариант: переложить решение загружать или не загружать очередной блок страницы на браузер.
В первом запросе браузеру возвращается список «частей» страницы и их «значимость» — чтобы как-то определять «лишний» или не лишний будет следующий кусок. Во втором и последующем запросах браузер «смотрит» насколько быстро загружается очередной кусок и нужно ли запрашивать следующий или над пользователем уже достаточно поглумились.

bealex (bealex.livejournal.com) 2011

А какую именно проблему мы хотим этим решить? Увеличить скорость загрузки? Уменьшить трафик? Мне кажется, нужно оценивать именно то, что мы улучшаем, и этой метрикой пользоваться. Правда, как подсчет трафика тестить — тут да, вопрос.

diaryea (diaryea.livejournal.com) 2011

Под «полноценной страницей» в первом варианте я имею ввиду «кусок, в котором будет показываться что-то минимально нужное для пользователей с плохим коннектом и javascript». А под «вторым куском» — все остальные второстепенные для пользователя вещи.

Евгений Степанищев (bolknote.ru) 2011

Комментарий для bealex.livejournal.com:

А какую именно проблему мы хотим этим решить? Увеличить скорость загрузки? Уменьшить трафик?

Увеличить скорость загрузки главного контента, сэкономить клиенту деньги.

astur (kozlov.am) 2011

Кнопка нужна, но за пользователя, конечно же, нужно решить изначально. Пользователь ленивый и ничего лишнего тыкать не будет :)

Кнопка должна быть __в браузере__, и её нажатие (с залипанием) должно означать, что браузер в заголовке попросит компактную версию. Все остальные пути, имхо — костыли.

Евгений Степанищев (bolknote.ru) 2011

Комментарий для diaryea.livejournal.com:

Ага, загрузить главное, а потом подгрузить неглавное, если главное подгрузилось быстро. Что-то есть. Вопрос только не съест ли скорость рендеринга (достраивать-то через JS придётся) скорость загрузки. Но трафик сэкономится.

Евгений Степанищев (bolknote.ru) 2011

Комментарий для kozlov.am:

Кнопка должна быть в браузере, и её нажатие (с залипанием) должно означать, что браузер в заголовке попросит компактную версию. Все остальные пути, имхо — костыли.

Увы, все браузеры делают буржуины, а им это, наверное, и не надо. Такая кнопка (чисто условно) есть в «Опере» — это «Опера Турбо», если человек её нажал, значит он гарантированно экономит трафик.

SiMM (mr-simm.livejournal.com) 2011

Комментарий для Евгения Степанищева:

если человек её нажал, значит он гарантированно экономит трафик

Либо у него сайт открывается через прокси оперы заметно быстрее, чем обычным путём — и такое случается.

greli (greli.livejournal.com) 2011

У андроидов 2.2 и выше есть navigator.connection, который может принимать значения: UNKNOWN, ETHERNET, WIFI, CELL_2G, CELL_3G. http://www.mobilexweb.com/blog/android-froyo-html5-accelerometer-flash-player

Евгений Степанищев (bolknote.ru) 2011

Комментарий для mr-simm.livejournal.com:

Либо у него сайт открывается через прокси оперы заметно быстрее, чем обычным путём, и такое случается.

Если он согласен мириться с тем, что вся графика портится «Турбой» (там качество снижается для экономии), то ему можно показывать «обеднённый» контент.

Евгений Степанищев (bolknote.ru) 2011

Комментарий для greli.livejournal.com:

У андроидов 2.2 и выше есть navigator.connection, который может принимать значения: UNKNOWN, ETHERNET, WIFI, CELL_2G, CELL_3G.

О! Спасибо, это ценно.

Артём Сапегин (sapegin.ru) 2011

Комментарий для Евгения Степанищева:

«если человек её нажал, значит он гарантированно экономит трафик»

Или у него на работе суровые админы.

Евгений Степанищев (bolknote.ru) 2011

Комментарий для sapegin.ru:

Или у него на работе суровые админы.

Обходит firewall? Ну так он всё равно гарантированно получает ухудшенных контент (пережатые картинки), так что можно и лишнее сбросить.

А потом я же не предлагаю отказаться от кнопки «у меня плохой/нормальный канал».

boltai-shaltai 2011

Про Оперу Мини и Турбо — как единственный достаточный признак не канает. Скажем, я пользую О.Мини на всех соединениях, включая домашний/рабочий вайфай. Ибо грузится/рендерится быстрее и памяти жрёт сильно меньше, а телефон не слишком мощный. Хром ощутимо медленнее и глупее.

Из конструктивных мыслей пока пара глупостей.
Определять название и capabilities браузера, пытаясь понять тип устройства. Какие-то девайсы заведомо не имеют WIFI (старые мобильники) или, напротив, ходят только по WIFI и ETHERNET и не имеют gsm-модуля (большинство планшетов).
Ещё реферер может дать представление, с насколько навороченного ресурса пришёл посетитель. А если пришёл, например, с яндекса, то между yandex.ru и m.yandex.ru есть разница — тоже можно делать выводы.

Евгений Степанищев (bolknote.ru) 2011

Комментарий для boltai-shaltai:

телефон не слишком мощный.

Уже повод не давать эту телефону лишнего.

Какие-то девайсы заведомо не имеют WIFI (старые мобильники) или, напротив, ходят только по WIFI и ETHERNET и не имеют gsm-модуля (большинство планшетов)

Да, можно. Тем более, что API для определения что за мобила пришла на страницу есть: http://api.yandex.ru/detector/doc/dg/concepts/detector-response.xml

то между yandex.ru и m.yandex.ru есть разница — тоже можно делать выводы.

Некоторые пользуются мобильной версии, потому что не знают, что можно переключиться на полную.

boltai-shaltai 2011

Уже повод не давать эту телефону лишнего.

Не-а, после проксирования Оперой даже тяжёлые страницы прям летают.

Некоторые пользуются мобильной версии, потому что не знают, что можно переключиться на полную.

Воистину так. Но тут смысл ещё в том, чтоб всю эвристику по вычислению возможностей устройства переложить на поисковики. По-хорошему, это морда Яндекса дожлна быть умной и не швырять VGA-андроид с хромом на мобильную версию (сейчас, похоже, не так). А мы могли бы этим пользоваться.

Евгений Степанищев (bolknote.ru) 2011

Комментарий для boltai-shaltai:

Не-а, после проксирования Оперой даже тяжёлые страницы прям летают.

Ну тогда Мини выкидываем, Турбу оставляем.

По-хорошему, это морда Яндекса дожлна быть умной и не швырять VGA-андроид с хромом на мобильную версию (сейчас, похоже, не так). А мы могли бы этим пользоваться.

Да мы уже можем пользоваться. Вот же: http://api.yandex.ru/detector/doc/dg/concepts/detector-response.xml

boltai-shaltai 2011

Комментарий для Евгения Степанищева:

Да мы уже можем пользоваться

Реферером попроще было б :-)

Евгений Степанищев (bolknote.ru) 2011

Комментарий для boltai-shaltai:

Реферером попроще было б :-)

Только часто ли переходят с «Яндекса»?

boltai-shaltai 2011

А я знаю? ) От проекта ж зависит. Не только Я., но и другие поисковики есть, а у них тоже мобильные версии.

это ж не достаточный признак — так, намёк, что не с быстрого и большого десктопа чувак пришёл, надо аккуратнее с ним.

Евгений Степанищев (bolknote.ru) 2011

Комментарий для boltai-shaltai:

Через API можно со 100% уверенностью сказать (ну или почти со 100%) мобильное устройство или нет.

0range (0range.ru) 2011

Комментарий для Евгения Степанищева:

Для мобильных браузеров всегда нужно делать оптимизированную мобильную версию и ссылку в самом вверху для перехода на версию для декстопов если через wifi сидят или через безлимитку быструю.

А для тех у кого медленный канал или помегабайтная тарификация резать контент очень глупо. За счет чего ты хочешь уменьшить скорость загрузки уже оптимизированного сайта, уменьшить качество картинок или обрезать фукционал или контент?

0range (0range.ru) 2011

Комментарий для Евгения Степанищева:

Вот тебе самый идиотский пример реализации фотогалереи:
фотка и кнопки туда сюда, при нажатии на которые подгружаются другие картинки, вместо того чтобы подгрузить сразу 10 картинок и посмотреть их, сидишь нажимаешь далее и ждешь по 20 секунд пока загрузится след фотография. Лишняя трата времени

Евгений Степанищев (bolknote.ru) 2011

Комментарий для 0range.ru:

А для тех у кого медленный канал или помегабайтная тарификация резать контент очень глупо. За счет чего ты хочешь уменьшить скорость загрузки уже оптимизированного сайта, уменьшить качество картинок или обрезать фукционал или контент?

Убрать некоторые блоки, уменьшить картинки, убрать «красивости», баннеры и так далее.

Вот тебе самый идиотский пример реализации фотогалереи

Не понимаю что ты пытаешься иллюстрировать. Ведь это твоя реализация чего-то, а не моя.

Тима Люмин 2011

Кнопка должна быть поддоменом типа i. или phone.
В случае определения каким-либо способом нужно предлагать перебросить.

0range (0range.ru) 2011

Комментарий для Евгения Степанищева:

Ну помегабайтную тарификацию ты никак не просечешь фактически, а скорость канала можно замерить, если можно замерить скорость загрузки favicon, так как он грузится обычно одни из первых.
Ну по уму у кого медленный инет или дорогой, обычно просто вырубают флеш, картинки, js и у них получается фактически урезанная версия, главное чтобы сайт был граммотно сверстан.

0range (0range.ru) 2011

Комментарий для Евгения Степанищева:

Если отключить флеш, картинки, js и сжать html css, то фактически получаем 5 — 10 килобайт в среднем, даже на жопорезе будет летать :)

Евгений Степанищев (bolknote.ru) 2011

Комментарий для 0range.ru:

Ну помегабайтную тарификацию ты никак не просечешь фактически

Фактически, нет. Но можно попробовать догадаться, способы я перечислил.

скорость канала можно замерить, если можно замерить скорость загрузки favicon, так как он грузится обычно одни из первых

Первым грузится HTML и именно в нём всё самое интересное.

Евгений Степанищев (bolknote.ru) 2011

Комментарий для Тима Люмин:

Кнопка должна быть поддоменом типа i. или phone.

Что такое «i»? Букву «m» я понимаю — это «mobile».

Эдуард Б. 2011

Комментарий для Евгения Степанищева:

У меня просто некоторые размышления, они может быть покажутся глупыми, но вы уж не судите строго.

Если завязываться на вещи вроде провайдера, юзер-агента, реферера с моб версией и пр, получается, что всегда, когда пользователь приходит к нам с этими признаком (признаками), у нас для принятия решения на выходе будет всегда один и тот же не меняющийся результат, понятное дело, тут качающиеся торренты и 5 загружащихся сайтов в других табах не учтешь, и вроде как такая одинаковость результата будет вредить.

Если же пытаться измерять фактическую скорость, то результат от запроса к запросу будет всегда разным, и как будто бы более реальным. Но, например, может сильно соврать уже в другую сторону — именно в эту секунду в соседнем табе что-то грузилось (но потом-то перестало).
Лично я даже предположить не могу — что вреднее: постоянное значение, т. е. отсутствие информации о фактическом «ворклоаде» именно в данную секунду, или же наоборот — наличие такой информации еще вреднее.

По поводу измерения конечно тоже сложно — наверное нужно городить что-то невероятно сложное и «низкоуровневое»

Появилась мысль, если бы что-то такое можно было внедрить в сервер, сразу начать отправлять клиенту ответ (если такое возможно, я не особо сейчас представляю) отправить клиенту сначала несколько гигантских HTTP заголовков заполненных мусором, и замерять как уходят они, а потом если это по fastcgi, то параметром, или как дополнительный HTTP заголовок запроса X-Measured-Client-Speed :) передавать результат замера бекенду, и при получении ответа уже доотправлять все остальное. Но ведь код ответа-то к этому моменту уже должен быть отправлен… Тогда возможно сервер должен делать сначала какой-то «тестовый» запрос на бекенд, чтобы понять какой статус ответа отправлять, а потом уже отдавать мусорный заголовок, начинать замер, и далее делать к бекенду уже «полноценный» запрос снабженный доп. параметром.

А вообще, конечно да, для «рядовых» разработчиков было бы лучше если бы такую информацию сразу можно было получать от всех брозеров в параметрах запроса (ведь с какой-то точностью он бы мог замерять доступный по крайней мере ему канал).

Еще бредовая может быть идея, но если бы все крупные сайты (яндекс, гугл) делали такое измерение постфактум и складывали бы результат измерения + дату в куку.. )

Евгений Степанищев (bolknote.ru) 2011

Комментарий для Эдуард Б.:

отправить клиенту сначала несколько гигантских HTTP заголовков заполненных мусором, и замерять как уходят они

Канал может быть и не симметричным (xDSL, например)

Еще бредовая может быть идея, но если бы все крупные сайты (яндекс, гугл) делали такое измерение постфактум и складывали бы результат измерения + дату в куку.. )

Чужую куку сайт прочитать не может. Так что эту информацию будут знать только те, кто делал замеры.

Эдуард Б. 2011

отправить клиенту сначала несколько гигантских
HTTP заголовков заполненных мусором, и замерять как
уходят они

Канал может быть и не симметричным (xDSL, например)

Ну да, разумеется, это может быть aDSL или что угодно, но я предположил, что вас в первую очередь интересует как раз таки «download», ну а скорость загрузки заголовков ответа от скорости загрузки тела ответа в общем случае, наверняка, не отличается.

Чужую куку сайт прочитать не может

Да, как-то не учел.

Еще подумал, что любые подобные способы измерений (chunked, заголовки, XHR) могут быть не эффективны, если клиентские прокси сервера будут сразу все забирать с большой скоростью, это наверное надо смотреть как они обычно работают. Но, наверное, чаще всего прокси находится «ближе» к клиенту, хотя и в этом случае прокси может скармливать это конечному клиенту применив «throttling».

bespokoistvo 2011

Есть вполне доступные и оперативно пополняемые базы айпи мобильных операторов.
Впрочем, разделить по айпи адресам пользователей тарифов с помегабайтной оплатой и пользователей безлимитки нельзя.
Еще одно ограничение — эти диапазоны айпи, как правило, используются и телефонами, и модемами.