Кстати, о преждевременной оптимизации

[swetlana]

Что-то в последнее время часто стали поминать на форуме данную тему.

И мне стало интересно мнение людей, которые высказываются в этом ключе.

Неужто действительно стремление выдать результат из возможно меньшего количества файлов, имеющих в сумме меньший вес — абсолютное зло?

Как пример:

http://palto-modello.ru/ — было, 33 файла общей массой 1.04Мб;

http://swetlanabayer.ru/work/palto/ — стало, 13 файлов общей массой 281кб.

В чём плюсы — понимаю. Даже с учётом того, что по нагруженности сайт не сможет конкурировать с гуглом или вконтактиком.

В чём минусы?

[psywalker]

Что-то в последнее время часто стали поминать на форуме данную тему.

И мне стало интересно мнение людей, которые высказываются в этом ключе.

Неужто действительно стремление выдать результат из возможно меньшего количества файлов, имеющих в сумме меньший вес — абсолютное зло?

Как пример:

http://palto-modello.ru/ — было, 33 файла общей массой 1.04Мб;

http://swetlanabayer.ru/work/palto/ — стало, 13 файлов общей массой 281кб.

В чём плюсы — понимаю. Даже с учётом того, что по нагруженности сайт не сможет конкурировать с гуглом или вконтактиком.

В чём минусы?

Т.е. ты спрашиваешь, в чём минус того, что ты уменьшила объем файлов и вес стал меньше?

И кстати о каких файлах идёт речь?

[Быколай]

Что-то в последнее время часто стали поминать на форуме данную тему.

И мне стало интересно мнение людей, которые высказываются в этом ключе.

Неужто действительно стремление выдать результат из возможно меньшего количества файлов, имеющих в сумме меньший вес — абсолютное зло?

Как пример:

http://palto-modello.ru/ — было, 33 файла общей массой 1.04Мб;

http://swetlanabayer.ru/work/palto/ — стало, 13 файлов общей массой 281кб.

В чём плюсы — понимаю. Даже с учётом того, что по нагруженности сайт не сможет конкурировать с гуглом или вконтактиком.

В чём минусы?

это не зло, а бобро. минус оптимизации только для провайдера лимитного интернета - меньше трафика у клиента

а вёрстка должна была измениться?

Edited April 1, 2011 by Быколай

[botyaslonim]

Однако, лицо у девушки стало заметно пережатым. Оно того стоило?

Что-то в последнее время часто стали поминать на форуме данную тему.

И мне стало интересно мнение людей, которые высказываются в этом ключе.

Неужто действительно стремление выдать результат из возможно меньшего количества файлов, имеющих в сумме меньший вес — абсолютное зло?

Как пример:

http://palto-modello.ru/ — было, 33 файла общей массой 1.04Мб;

http://swetlanabayer.ru/work/palto/ — стало, 13 файлов общей массой 281кб.

В чём плюсы — понимаю. Даже с учётом того, что по нагруженности сайт не сможет конкурировать с гуглом или вконтактиком.

В чём минусы?

[swetlana]

Однако, лицо у девушки стало заметно пережатым. Оно того стоило?

это уже второе замечание такого характера. Но я в упор не вижу хоть сколько-нибудь ощутимой разницы. У меня глаза не оттуда растут?

Кстати, в данном конкретном примере после перевёрстки объём уменьшается почти в два раза даже если самой большой картинке качество 100% поставить.

Поменять чтоль на картинку с меньшей степенью сжатия?

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

это не зло, а бобро. минус оптимизации только для провайдера лимитного интернета - меньше трафика у клиента

Вот мне почему-то тоже так кажется.

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

а вёрстка должна была измениться?

да, вёрстка должна была измениться. В этом основной смысл переделки. Уменьшение веса вообще в задачи не входило, как-то само собой так получилось.

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

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

Т.е. ты спрашиваешь, в чём минус того, что ты уменьшила объем файлов и вес стал меньше?

И кстати о каких файлах идёт речь?

да, именно это я и спрашиваю.

А речь обо всех файлах: html, css, картинки.

[Быколай]

какие товарищи утверждают что это плохо? чем аргументируют? первый раз слышу и, если честно, удивлён.

наоборот, это как бы прописные истины сайтоделательства - оптимизация всего и вся для доступности всем и всегда.

[swetlana]

какие товарищи утверждают что это плохо?…

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

Но было за последнее время как минимум раза два-три упоминание преждевременной оптимизации в качестве ошибки.

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

[s0rr0w]

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

Но было за последнее время как минимум раза два-три упоминание преждевременной оптимизации в качестве ошибки.

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

Слышал звон, да не знаю где он...

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

[Veseloff]

Что я думаю обо всём этом. В принципе, ничего плохого в этом нет — качественный продукт это всегда хорошо. Например, есть сайт у которого 3 css файла подключаются, jquery, highslide, ещё что-нибудь — это всё отлично работает и загружается за секунду. Но это происходит до поры — когда количество просмотров начинает переваливать за 100к в сутки, то вот тут встаёт вопрос, что неплохо было бы js совместить в один файл, с css так же поступить, а ещё бы и серверный код оптимизировать. Каждая миллисекунда на счету. Почему оптимизация бывает преждевременной? Ну потому, что мало у кого количество посетителей переваливает хотя бы за 5к, так что тратить время на оптимизацию того, что можно и не оптимизировать — пустая трата времени. Оптимизация «веса» картинок — важная вещь на любом этапе, так как даже на ненагруженном сайте 2МБ информации будет грузиться долго. А вот оптимизация количества файлов и кода — это надо откладывать на потом.

[botyaslonim]

Мне видно.

Вообще, неплохо, конечно, что сайт быстрее грузится, но лишние 30-50 Кб погоды не сделают, а лицо будет спасено

это уже второе замечание такого характера. Но я в упор не вижу хоть сколько-нибудь ощутимой разницы. У меня глаза не оттуда растут?

Кстати, в данном конкретном примере после перевёрстки объём уменьшается почти в два раза даже если самой большой картинке качество 100% поставить.

Поменять чтоль на картинку с меньшей степенью сжатия?

[swetlana]

…тратить время на оптимизацию того, что можно и не оптимизировать — пустая трата времени.…

в общем и целом идея понятна.

Но мне почему-то кажется уместной аналогия про спортсмена, которому по этой идее незачем впустую тратить время на тренировки, а напрягаться нужно только на соревнованиях.

Или это значит, что всё-таки идею я поняла неправильно?

Edited April 2, 2011 by swetlana

[sigma77]

в общем и целом идея понятна.

Но мне почему-то кажется уместной аналогия про спортсмена, которому по этой идее незачем впустую тратить время на тренировки, а напрягаться нужно только на соревнованиях.

Или это значит, что всё-таки идею я поняла неправильно?

Как я поняла, если продолжать аналогию со спортсменом, то имеется ввиду, если ты собираешься заниматься спортом как любитель, то тебе не нужно заниматься тренировками по 8 и более часов в день, тратится на дорогущее профессиональное оборудование и трененров. Ты просто поддерживаешь себя в форме. По мере твоего роста и желания - полупрофессиональный спорт, соревнования на уровне района, города, области, страны, международный спорт - соответственно и растут твои требования к качеству и количеству тренировок и оборудования. Наверное, как то так. Хотя аналогия не совсем точная.

[swetlana]

Слышал звон, да не знаю где он...

Примерно так и есть.

А цель темы — всё-таки выяснить, откуда звон и что он означает.

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

Возможно.

А если не бороться, а изначально писать так, чтобы оптимизировать было уже не нужно?

Просто я вот чего не пойму:

неужели вы советуете на первом этапе работы например при размещении картинки не подбирать наиболее оптимальный формат и степень сжатия, а ставить неоптимизированные, а оптимизировать уже после завершения вёрстки?

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

А смысл?

[Veseloff]

А если не бороться, а изначально писать так, чтобы оптимизировать было уже не нужно?

Вот тут как получается. Допустим, разработка при помощи фреймворков, готовых CMS всегда ускоряет процесс собственно разработки, но будет медленнее, чем просто набор скриптов, написанных под задачу. У меня есть несколько проектов, которые работают и я надеюсь, что они когда-нибудь станут популярными, а, значит, они будут нагружать оборудование. Суть в том, что они все написаны за несколько дней, используя мой самописный «движок», который я использую обычно в работе и нормально работают. В среднем всё отрабатывается за 0,03 сек, что сейчас легко переносимо, а, если попрёт, то будет много. Для простоты расчётов допустим, что всего 10 проектов и каждый из них делался по 10 дней. Итого 100 дней. Чтобы каждый из проектов максимально оптимизировать потребуется ещё 300 дней, никак не меньше, то есть 30 на один проект. Маловероятно, что «выстрелят» все 10 — максимум 2. Итого надо будет потратить не 400 дней, а 160, что, конечно же лучше. Так же я работаю и с клиентами. Я сразу предупреждаю о скорости, цене разработки и о том, что есть предел по посещаемости. То есть, например, я говорю, что можно заплатить 1000, я всё сделаю за 10 дней, но сайт не выдержит больше 10 000 посетителей в сутки. Могу всё сделать за 4000 за 40 дней, надо будет ещё потратиться на оборудование, но будет спокойно держать 300 000. Так вот всегда говорят, что заплатят 1000, а потом, когда станет посетителей больше 10 000, так обратятся ещё раз. И всё правильно делают — почти никто не достигает лимита

[swetlana]

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

[Veseloff]

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

[s0rr0w]

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

Возможно.

А если не бороться, а изначально писать так, чтобы оптимизировать было уже не нужно?

Оптимизировать можно всегда. Когда я собирал один довольно таки объемный проект, я часто возвращался к старому коду. Сделал А, Б, В, а для того, чтобы сделать Г, нужно было вернуться и переделать А и Б. А для Д приходилось менять Г и В. Вот смысл оптимизировать при создании, если это может быть выкинуто еще до окончании проекта?

Просто я вот чего не пойму:

неужели вы советуете на первом этапе работы например при размещении картинки не подбирать наиболее оптимальный формат и степень сжатия, а ставить неоптимизированные, а оптимизировать уже после завершения вёрстки?

Я говорю, что нужно оптимизацию картинок делать на момент начальной сборки всего один раз.

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

Если удобно разрабатывать так, то почему бы и да?

А смысл?

Пока проектики маааахонькие, то смысла нет. Но как только понадобится сделать что-то более объемное, то тут может процесс разработки перевернуться с ног на голову.

И инструменты и способы могут быть совершенно иными.

[SelenIT]

Если поводом была моя ремарка здесь, то постараюсь внести ясность: речь шла исключительно о CSS-файлах, размер которых - с оптимизацией или без - как правило, составляет сущий децл в сравнении с содержанием современных страниц (всякими там видимороликами и т.п., чем нас так радует, в числе прочего, новый живой ХТМЛ), а с учетом кеширования миллисекунды выигрыша и вовсе будут заметны один раз при первой загрузке. И такие практики оптимизации, как, например, группировка свойств по значениям, а не элементам (когда в одном месте оказываются сгруппированы селекторы заголовка, активной ссылки в футере и подписи фотки только потому, что у них обший светло-оранжевый фон, зато правила, относящиеся к самому заголовку, приходится с лупой выискивать по всему файлу) на этапе разработки очень быстро начинают плодить путаницу и превращают работу в черт-те что. И да, лично я не вижу катастрофы в том, чтоб на странице с хитрым JQ-плагином CSS-ник, относящийся к этому плагину, подключался отдельно, а не пихался бездумно в основной (особенно если такая страница на всём сайте одна из тысячи). Важнее, действительно, оптимизировать картинки, особенно большие. Хотя, опять-таки, лично я нередко вначале делаю верстку на отдельных картинках, и лишь ближе к концу, когда мне уже абсолютно ясно, сколько картинок получается всего, каковы их окончательные размеры, как они группируются и т.п. - только тогда объединяю их в спрайты (а то, если с самого начала делать спрайтами, бывает, что какая-нибудь одна зараза выбивается на четыре-пять пикселей и вынуждает менять расстояние между кусками и, соответственно, переправлять все уже проставленные в CSS-нике background-position'ы...).

Стремление к уменьшению нагрузки (по объему и числу запросов) я считаю в высшей степени похвальным, но оно не должно превращаться в навязчивость. По-моему, программистский подход "сперва сделай, чтоб работало, потом подправь, чтоб работало красиво, потом доработай напильником, чтоб работало быстро" достаточно универсален и здесь тоже применим. Конечно, с ростом профессионализма сначала первые два шага, а потом и третий с ними, постепенно сливаются в один. Но всё-таки, в аналогии со спортсменом - не умаляя роли ежедневных тренировок, лично я не вижу особого смысла отрабатывать особенные финты, нырки и кувырки, идя в гастроном за батоном или догоняя автобус на улице...

Впрочем, спорить с профессионалами не берусь - я-то пока и на продвинутого любителя не тяну...

это уже второе замечание такого характера. Но я в упор не вижу хоть сколько-нибудь ощутимой разницы. У меня глаза не оттуда растут?

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

[swetlana]

Если поводом была моя ремарка здесь…

да, кстати, это было одно из тех высказываний, после которых захотелось прояснить ситуацию.

Но всё изложенное ниже — это ведь самые естественные с точки зрения здравого смысла соображения.

Значит, получается, я зря о чём-то беспокоюсь?

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

ну объяснение-то этому наверняка есть вполне здравое, и наверняка его без проблем сможет дать хороший дизайнер.

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

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

[s0rr0w]

ну объяснение-то этому наверняка есть вполне здравое, и наверняка его без проблем сможет дать хороший дизайнер.

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

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

Цветовой охват TN+Film матриц намного меньше чем у IPS-панелей, которые используются дизайнерами. Офисные мониторы очень плохо показывают цвета интенсивностью 0-20% и 80-100%. Поэтому с пастелью нужно быть осторожным.

Да и вообще, контрасты рулят. Если ваш сайт хорошо смотрится в ЧБ-варианте, то он будет хорошо смотреться на любом мониторе.

[botyaslonim]

Ради прикола поинтересовался, как дело обстоит на серьёзных сайтах.

jQuery.com:

35 запросов, никаких спрайтов, никаких объединений скриптов

Freelance.com

57 запросов, никаких спрайтов, никаких объединений скриптов

Alexa.com

74 запроса, 1 спрайт, никаких объединений скриптов