Как стать автором
Обновить

Комментарии 38

Проблема в том, что изначально все делают под ПК, а потом допиливают под мобильные. На это у многих нет средств.
Это да, но никто не мешает даже при начальной верстке закладывать основу для оптимальной работы под смартфоны. Media Queries, все такое.
Плюс, нужно вырабатывать привычку сразу оптимизировать сайт — жать картинки, стили, js, минимизировать обращения к серверу, настраивать кеширование и гзипирование. Если придерживаться простых правил, то даже изначально десктопный сайт будет шустро работать на мобильных, и опять же, потреблять меньше энергии.
Написал и задумался. «Потребление энергии» в контексте сайтов хоть и логично, по пока как-то звучит диковато. Надо привыкать :)
Вот начнёт Гугл ранжировать сайты ещё и по потреблению энергии, соазу все привыкнем :)
Кстати это вариант — зашел в гуглопоиск с мобильного устройства и сайты в выдаче выстроились еще учитывая и этот критерий.
Как раз таки если начать жать всё подряд, то потребление энергии скорее вырастет чем снизится. Так как энергия тратится в первую очередь при выполнении операций на CPU. Скорее всего несжатый bmp показать намного «зеленее», чем png-файл, а не сжатый gzip-ом CSS/HTML хоть и съедят больше трафика, но, возможно, будут быстрее обработаны.

Обращаю внимание, что я всюду пишу «наверное» и «возможно» — на данный момент нет каких-либо решений, которые бы гарантированно давали улучшение по энергопотреблению во всех браузерах и на всех платформах. Любые оптимизации будут очень специфичны для конкретного случая. Поэтому считаю, что материал статьи стоит воспринимать крайне скептически.
Если жать на стороне сервера, то CPU девайса это по-идее никак не затронет. По поводу bmp, кстати, тоже есть упоминание в статье
Как не затронет? Распаковать-то надо будет. И чем сложнее формат сжатых данных — тем больше потеряется времени CPU на распаковке.
Да, не учел этот момент, пардон.
Подозреваю тогда, что радиосигнал «распаковывать» из эфира гораздо сложнее и энергозатратнее, чем картинку из памяти.
Это в случае с мобильными устройствами так. А за все остальные кто поручится?

Дпугой момент — в статье выше сказано, что распаковка PNG оказывается затратнее распаковки GIF, т.е. не обязательно, что экономия по трафику будет достаточна для компенсации затрат на распаковку.

Итого: нас интересует минимизация величины [энергия на прием трафика + энергия на распаковку]. Первое зависит от способа подключения, второе — от эффективности обработки конкретного формата в конкретном браузере на конкретной платформе.
радиосигнал декодируется аппаратно, я полагаю. А вот про аппаратные png-кодеки мне не известно
Да, там специализированные DSP и процессор, но они очень сложные и жрут очень много энергии. Где- то видел замечательную табличку с количествами транзисторов, но не могу найти сейчас.
Аппаратное ускорение декодирования картинок в мобильных чипах есть, в принципе. Ускоренное декодирование jpeg — чуть ли не во всех современных.
Декодер может быть реализован в железе.
Замечательно. Но это будет уже другое железо. Под которое оптимальный набор характеристик сайта будет другим.
НЛО прилетело и опубликовало эту надпись здесь
[irony]Сколько же стоит оптимизация сайта под смартфоны, что вышеперечисленные компании никак не накопят на нее[/irony]
На это у многих нет средств

Apple, Wikipedia, Facebook… Нет средств, да?
Действительно, а зачем? Ведь у них всех есть официальные нативные приложения, которые и в использовании удобнее, и батарею не садят, и трафика жрут меньше.
Официальное приложение Apple под Android? Смеётесь?
Это все конечно очень хорошо, но все таки хочется вернуться к реальному миру и посмотреть на это все в совокупности, т. е. не являются ли многие из «оптимизаций» банальной экономией на спичках (например замена png -> jpeg), которая даже не сравнима с тем сколько энергии мы моем сохранить просто снизив яркость устройства, допустим, на 10% или которая теряется на фоне того, сколько съедает gsm модуль
Из их работы:
For example, by applying our guidelines to the Wikipedia mobile site we reduced its energy consumption from 35 Joules to 25 Joules, a saving of 29%.

Правда, я немного не понял, относительно чего эти джоули считаются
Вот, я тоже (правда я только быстренько прошелся по их работе). Хочется все таки узнать в точных цифрах, например: до наших гьюдлайнов что бы разрядит полностью акк надо открыть википедию допустим тысячу раз, с нашими 1290
То, что apple.com быстро разряжает андроид, неудивительно.
Тесты с iphone, на которых выиграет apple.com и проиграет google.com, проводились?)
the most “green” mobile site www.ya.ru :)
Веб-девелоперу на заметку: на загрузку JQuery затрачивается 5 Джоулей.
Зато сколько джоулей jQuery экономит самомý разработчику!!…

Нет уж, ребятки, я плевать хотел на ваши джоули — будет вам и jQuery, и даже Underscore в придачу.
Вот он — образ бунтаря, идущего против системы :)
watch out!
Что-то я не понял из отчета чем им PNG не угодил.
Может быть дело в прозрачности? Ее ведь, по идее, тоже нужно просчитывать при рендеринге.
Не вижу в тестах потребления энергии пустыми сайтами с а) белым фоном и б) черным фоном. От чего плясать? К чему стремиться. К 7 Джоулям на просмотр?
Вот такое вот неоднозначное и спорное исследование получилось :)
Хотя, есть вариант, что более тонкие нюансы они могут рассказывать за определенную плату, как это сейчас делают многие аналитические и статистическое компании.
Эти результаты должны сильно зависеть от браузера.

Интересно, у Opera Mini есть оптимизация не только по размеру трафика, но и по энергопотреблению на конечном стройстве… Субъективно android-телефон с этим браузером довольно долго работает.
Табличку бы с графиками чуть побольше. Трудно читать.
Пора уже считать вред, нанесенный людьми во время работы над сайтом.
Сколько углекислого газа в атмосферу выдохнули,
сколько пота излили,
сколько плюшек съели,
сколько карандашей сточили,
сколько нефти истратили на пластмассовые одноразовые стаканчики…

Что я еще упустил, давайте полный перечень вреда составим.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации