У клиента дохлый канал?
В 1997 году, когда я впервые увидел веб через графический браузер (до этого у меня был опыт выхода в интернет через терминал на базе i80286 через текстовый браузер Lynx), у меня была выделенка, дело было в Казанском Государственном Университете и ещё очень долго я не знал что такое диалап и оплата за трафик.
Сейчас выделенки у большинства, но нередко встречается и такое, что клиент приходит на сайт через «дохлый канал» или с оплатой по трафику (например, через сотовый телефон).
Хорошо было бы об этом как-то узнать и не грузить клиенту лишние подробности в этом случае. Браузеры такое API не предоставляют (ещё бы, они и сами ничего не знают про канал), такую обобщённую информацию получить неоткуда. Но можно попытаться об этом догадаться. Эта запись — сборник моих сырых мыслей на эту тему.
Я вижу несколько путей.
- можно замерить время за которое страницу удалось отдать клиенту целиком. У меня пока нет оформившихся мыслей о том как это делать и есть недостаток — когда мы узнали о том, что у клиента плохой канал, содержимое уже выдали, ничего поменять нельзя. Можно выдавать chunked-контент, как предлагал Сергей Чикуёнок, но первый кусок должен быть значительным
- после загрузки страницы «пропинговать» хост. То есть обратиться через XHR на свой же сайт и замерить время ответа. Опять же, что делать с этими данными? Есть возможность в следующий раз показать более бедное содержимое, но следующий запрос может идти через другой канал. Возможное решение — сохранять IP-адрес запроса
- смотреть с какого браузера клиент приходит, если это «Опера Мини», вероятнее всего, канал плохой или с оплатой
- опять же «Опера», если включена функция «Опера Турбо» (определяется по IP-адресу клиента), клиент экономит трафик, значит канал с оплатой
- проверить грузятся ли картинки, способов много, но данные получаем постфактум, после загрузки страницы. Логика та же — выключил картинки, экономит. Загрузку Flash контролировать смысла не имеет — многие выключают, чтобы не видеть рекламы
- проверять не пришёл ли человек через канал сотового оператора (по IP-адресу). Безлимиток, которые бы не деградировали по скорости после какого-то лимита пока исчезающе мало, так что имеет смысл отдавать в этом случае «обеднённый» контент. Мобильные браузеры определять смысла не имеет — клиент может прийти через WiFi
- в комментариях подсказали, что в «Андроидах» 2.2 и выше есть специальное
API, чтобы определять способ подключения - ещё вариант из комментариев — определять модель телефона/планшета и по базе смотреть есть ли у него GSM/3G или WiFi
Кто-нибудь ещё какие-то пути видит?
сделать наверху кнопку «у меня дохлый/дорогой канал» — пользователь жмяк, графика — пиу!
имхо, решать за пользователя какой контент отдавать — полный или обрезанный — зло. ненавижу когда мне, когда захожу с планшета на яндекс или на жж, пытаются без спроса подсунуть мобильную версию.
Комментарий для bbambuk@gmail.com:
Успел раньше меня, я тоже хотел об этом сказать.
Зло, когда пользователь не имеет права выбора, если такое право есть, то при запоминании выбора пользователя ничего страшного в автоматическом определении — не вижу.
Комментарий для bbambuk@gmail.com:
Кнопка нужна, но за пользователя, конечно же, нужно решить изначально. Пользователь ленивый и ничего лишнего тыкать не будет :)
Первый вариант: отдавать страницу в два захода, но в отличие от chunked transfer encoding в первом заходе выдавать полноценную страницу, после загрузки которой XHR за вторым куском. Поскольку это почти тот же chunked, то в порядке бреда можно развить идею до второго варианта.
Второй вариант: переложить решение загружать или не загружать очередной блок страницы на браузер.
В первом запросе браузеру возвращается список «частей» страницы и их «значимость» — чтобы как-то определять «лишний» или не лишний будет следующий кусок. Во втором и последующем запросах браузер «смотрит» насколько быстро загружается очередной кусок и нужно ли запрашивать следующий или над пользователем уже достаточно поглумились.
А какую именно проблему мы хотим этим решить? Увеличить скорость загрузки? Уменьшить трафик? Мне кажется, нужно оценивать именно то, что мы улучшаем, и этой метрикой пользоваться. Правда, как подсчет трафика тестить — тут да, вопрос.
Под «полноценной страницей» в первом варианте я имею ввиду «кусок, в котором будет показываться что-то минимально нужное для пользователей с плохим коннектом и javascript». А под «вторым куском» — все остальные второстепенные для пользователя вещи.
Комментарий для bealex.livejournal.com:
Увеличить скорость загрузки главного контента, сэкономить клиенту деньги.
Кнопка должна быть __в браузере__, и её нажатие (с залипанием) должно означать, что браузер в заголовке попросит компактную версию. Все остальные пути, имхо — костыли.
Комментарий для diaryea.livejournal.com:
Ага, загрузить главное, а потом подгрузить неглавное, если главное подгрузилось быстро. Что-то есть. Вопрос только не съест ли скорость рендеринга (достраивать-то через JS придётся) скорость загрузки. Но трафик сэкономится.
Комментарий для kozlov.am:
Увы, все браузеры делают буржуины, а им это, наверное, и не надо. Такая кнопка (чисто условно) есть в «Опере» — это «Опера Турбо», если человек её нажал, значит он гарантированно экономит трафик.
Комментарий для Евгения Степанищева:
Либо у него сайт открывается через прокси оперы заметно быстрее, чем обычным путём — и такое случается.
У андроидов 2.2 и выше есть navigator.connection, который может принимать значения: UNKNOWN, ETHERNET, WIFI, CELL_2G, CELL_3G. http://www.mobilexweb.com/blog/android-froyo-html5-accelerometer-flash-player
Комментарий для mr-simm.livejournal.com:
Если он согласен мириться с тем, что вся графика портится «Турбой» (там качество снижается для экономии), то ему можно показывать «обеднённый» контент.
Комментарий для greli.livejournal.com:
О! Спасибо, это ценно.
Комментарий для Евгения Степанищева:
«если человек её нажал, значит он гарантированно экономит трафик»
Или у него на работе суровые админы.
Комментарий для sapegin.ru:
Обходит firewall? Ну так он всё равно гарантированно получает ухудшенных контент (пережатые картинки), так что можно и лишнее сбросить.
А потом я же не предлагаю отказаться от кнопки «у меня плохой/нормальный канал».
Про Оперу Мини и Турбо — как единственный достаточный признак не канает. Скажем, я пользую О.Мини на всех соединениях, включая домашний/рабочий вайфай. Ибо грузится/рендерится быстрее и памяти жрёт сильно меньше, а телефон не слишком мощный. Хром ощутимо медленнее и глупее.
Из конструктивных мыслей пока пара глупостей.
Определять название и capabilities браузера, пытаясь понять тип устройства. Какие-то девайсы заведомо не имеют WIFI (старые мобильники) или, напротив, ходят только по WIFI и ETHERNET и не имеют gsm-модуля (большинство планшетов).
Ещё реферер может дать представление, с насколько навороченного ресурса пришёл посетитель. А если пришёл, например, с яндекса, то между yandex.ru и m.yandex.ru есть разница — тоже можно делать выводы.
Комментарий для boltai-shaltai:
Уже повод не давать эту телефону лишнего.
Да, можно. Тем более, что API для определения что за мобила пришла на страницу есть: http://api.yandex.ru/detector/doc/dg/concepts/detector-response.xml
Некоторые пользуются мобильной версии, потому что не знают, что можно переключиться на полную.
Не-а, после проксирования Оперой даже тяжёлые страницы прям летают.
Воистину так. Но тут смысл ещё в том, чтоб всю эвристику по вычислению возможностей устройства переложить на поисковики. По-хорошему, это морда Яндекса дожлна быть умной и не швырять VGA-андроид с хромом на мобильную версию (сейчас, похоже, не так). А мы могли бы этим пользоваться.
Комментарий для boltai-shaltai:
Ну тогда Мини выкидываем, Турбу оставляем.
Да мы уже можем пользоваться. Вот же: http://api.yandex.ru/detector/doc/dg/concepts/detector-response.xml
Комментарий для Евгения Степанищева:
Реферером попроще было б :-)
Комментарий для boltai-shaltai:
Только часто ли переходят с «Яндекса»?
А я знаю? ) От проекта ж зависит. Не только Я., но и другие поисковики есть, а у них тоже мобильные версии.
это ж не достаточный признак — так, намёк, что не с быстрого и большого десктопа чувак пришёл, надо аккуратнее с ним.
Комментарий для boltai-shaltai:
Через API можно со 100% уверенностью сказать (ну или почти со 100%) мобильное устройство или нет.
Комментарий для Евгения Степанищева:
Для мобильных браузеров всегда нужно делать оптимизированную мобильную версию и ссылку в самом вверху для перехода на версию для декстопов если через wifi сидят или через безлимитку быструю.
А для тех у кого медленный канал или помегабайтная тарификация резать контент очень глупо. За счет чего ты хочешь уменьшить скорость загрузки уже оптимизированного сайта, уменьшить качество картинок или обрезать фукционал или контент?
Комментарий для Евгения Степанищева:
Вот тебе самый идиотский пример реализации фотогалереи:
фотка и кнопки туда сюда, при нажатии на которые подгружаются другие картинки, вместо того чтобы подгрузить сразу 10 картинок и посмотреть их, сидишь нажимаешь далее и ждешь по 20 секунд пока загрузится след фотография. Лишняя трата времени
Комментарий для 0range.ru:
Убрать некоторые блоки, уменьшить картинки, убрать «красивости», баннеры и так далее.
Не понимаю что ты пытаешься иллюстрировать. Ведь это твоя реализация чего-то, а не моя.
Кнопка должна быть поддоменом типа i. или phone.
В случае определения каким-либо способом нужно предлагать перебросить.
Комментарий для Евгения Степанищева:
Ну помегабайтную тарификацию ты никак не просечешь фактически, а скорость канала можно замерить, если можно замерить скорость загрузки favicon, так как он грузится обычно одни из первых.
Ну по уму у кого медленный инет или дорогой, обычно просто вырубают флеш, картинки, js и у них получается фактически урезанная версия, главное чтобы сайт был граммотно сверстан.
Комментарий для Евгения Степанищева:
Если отключить флеш, картинки, js и сжать html css, то фактически получаем 5 — 10 килобайт в среднем, даже на жопорезе будет летать :)
Комментарий для 0range.ru:
Фактически, нет. Но можно попробовать догадаться, способы я перечислил.
Первым грузится HTML и именно в нём всё самое интересное.
Комментарий для Тима Люмин:
Что такое «i»? Букву «m» я понимаю — это «mobile».
Комментарий для Евгения Степанищева:
У меня просто некоторые размышления, они может быть покажутся глупыми, но вы уж не судите строго.
Если завязываться на вещи вроде провайдера, юзер-агента, реферера с моб версией и пр, получается, что всегда, когда пользователь приходит к нам с этими признаком (признаками), у нас для принятия решения на выходе будет всегда один и тот же не меняющийся результат, понятное дело, тут качающиеся торренты и 5 загружащихся сайтов в других табах не учтешь, и вроде как такая одинаковость результата будет вредить.
Если же пытаться измерять фактическую скорость, то результат от запроса к запросу будет всегда разным, и как будто бы более реальным. Но, например, может сильно соврать уже в другую сторону — именно в эту секунду в соседнем табе что-то грузилось (но потом-то перестало).
Лично я даже предположить не могу — что вреднее: постоянное значение, т. е. отсутствие информации о фактическом «ворклоаде» именно в данную секунду, или же наоборот — наличие такой информации еще вреднее.
По поводу измерения конечно тоже сложно — наверное нужно городить что-то невероятно сложное и «низкоуровневое»
Появилась мысль, если бы что-то такое можно было внедрить в сервер, сразу начать отправлять клиенту ответ (если такое возможно, я не особо сейчас представляю) отправить клиенту сначала несколько гигантских HTTP заголовков заполненных мусором, и замерять как уходят они, а потом если это по fastcgi, то параметром, или как дополнительный HTTP заголовок запроса X-Measured-Client-Speed :) передавать результат замера бекенду, и при получении ответа уже доотправлять все остальное. Но ведь код ответа-то к этому моменту уже должен быть отправлен… Тогда возможно сервер должен делать сначала какой-то «тестовый» запрос на бекенд, чтобы понять какой статус ответа отправлять, а потом уже отдавать мусорный заголовок, начинать замер, и далее делать к бекенду уже «полноценный» запрос снабженный доп. параметром.
А вообще, конечно да, для «рядовых» разработчиков было бы лучше если бы такую информацию сразу можно было получать от всех брозеров в параметрах запроса (ведь с какой-то точностью он бы мог замерять доступный по крайней мере ему канал).
Еще бредовая может быть идея, но если бы все крупные сайты (яндекс, гугл) делали такое измерение постфактум и складывали бы результат измерения + дату в куку.. )
Комментарий для Эдуард Б.:
Канал может быть и не симметричным (xDSL, например)
Чужую куку сайт прочитать не может. Так что эту информацию будут знать только те, кто делал замеры.
Ну да, разумеется, это может быть aDSL или что угодно, но я предположил, что вас в первую очередь интересует как раз таки «download», ну а скорость загрузки заголовков ответа от скорости загрузки тела ответа в общем случае, наверняка, не отличается.
Да, как-то не учел.
Еще подумал, что любые подобные способы измерений (chunked, заголовки, XHR) могут быть не эффективны, если клиентские прокси сервера будут сразу все забирать с большой скоростью, это наверное надо смотреть как они обычно работают. Но, наверное, чаще всего прокси находится «ближе» к клиенту, хотя и в этом случае прокси может скармливать это конечному клиенту применив «throttling».
Есть вполне доступные и оперативно пополняемые базы айпи мобильных операторов.
Впрочем, разделить по айпи адресам пользователей тарифов с помегабайтной оплатой и пользователей безлимитки нельзя.
Еще одно ограничение — эти диапазоны айпи, как правило, используются и телефонами, и модемами.