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

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

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

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

Apple, Wikipedia, Facebook… Нет средств, да?
0
Действительно, а зачем? Ведь у них всех есть официальные нативные приложения, которые и в использовании удобнее, и батарею не садят, и трафика жрут меньше.
+5
Это все конечно очень хорошо, но все таки хочется вернуться к реальному миру и посмотреть на это все в совокупности, т. е. не являются ли многие из «оптимизаций» банальной экономией на спичках (например замена png -> jpeg), которая даже не сравнима с тем сколько энергии мы моем сохранить просто снизив яркость устройства, допустим, на 10% или которая теряется на фоне того, сколько съедает gsm модуль
0
Из их работы:
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%.

Правда, я немного не понял, относительно чего эти джоули считаются
0
Вот, я тоже (правда я только быстренько прошелся по их работе). Хочется все таки узнать в точных цифрах, например: до наших гьюдлайнов что бы разрядит полностью акк надо открыть википедию допустим тысячу раз, с нашими 1290
+4
То, что apple.com быстро разряжает андроид, неудивительно.
Тесты с iphone, на которых выиграет apple.com и проиграет google.com, проводились?)
+4
Веб-девелоперу на заметку: на загрузку JQuery затрачивается 5 Джоулей.
+9
Зато сколько джоулей jQuery экономит самомý разработчику!!…

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

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

Что я еще упустил, давайте полный перечень вреда составим.
Only those users with full accounts are able to leave comments. , please.