Продолжаем следовать модному тренду

[wildhind]

Без понятия. С большинством расценки сравнивают маркетологи. Качество услуг тоже сравнивают они. Разработчики зачастую даже не знают общих бюджетов проектов.

[across]

А как клиенту в будущем редактировать контент, менять информацию на сайте?

слабо угадать с одного раза?

django?

[GrEb]

"Производство, продажа и аренда геодезических куполов"

наверное имеется ввиду не аренда, а сдача в аренду (лизинг

[buddah]

360 000

Это шутка или плюс-минус точная цифра?

10 кусков за хороший, но, по сути, простой сайт? Как говорят "у нас в Одессе" - шоб я так жил!

[wildhind]

А как клиенту в будущем редактировать контент, менять информацию на сайте?

слабо угадать с одного раза?

django?

Вот блин… не слабо оказалось

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

[Pasha]

Вот ещё заметил: у смайлика в преймуществах глаза чисто белые, а не прозрачные

[wildhind]

у смайлика в преймуществах глаза чисто белые, а не прозрачные

да, всё правильно

[across]

А как клиенту в будущем редактировать контент, менять информацию на сайте?

слабо угадать с одного раза?

django?

Вот блин… не слабо оказалось

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

гугл помог, вы где-то отписывались оказ-ся насчет какой-то ошибки )))

[wildhind]

гугл помог, вы где-то отписывались оказ-ся насчет какой-то ошибки )))

и точно! надо ж было так спалиться!

Ну да, ошибок там было навалом по ходу работы. В порядке эксперимента этот проект делался на новой временно незнакомой системе.

Ведь даже когда что-то знаешь хорошо, всё равно охота найти что-нибудь лучше.

[dersmoll]

А можно я еще вклинюсь.

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

Вес 2.4мб для главной страницы и 88 запросов к серверу? Если "следовать модному тренду", эта верстка в таком виде не выдержит никакой конкуреции - многие будут закрывать страницу еще до того, как она прогрузится.

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

#benefits .expand a {

background: url("/media/img/domes/benefits_eye.png") no-repeat scroll 0 0 transparent;

}

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

Куча неминимизарованного js, который следовало бы объединить в меньше файлов, пожать и опустить в самый низ кода.

С css та же ситуация. Плюс, в стилях есть такие штуки, как

footer.pagefoot table.footer_content td.followus aside.sociallinks div {

display: inline;

}

зачем вам такое усложнение и лишние зависимости? Лучшей практикой было бы написание чего-нибудь типа

.pagefoot .sociallinks div {

display: inline;

}

Такая избыточность встречается по всей таблице стилей

Например так

footer.pagefoot table.footer_content td.contactus

или так

header#pagehead.small div.content hgroup.logo h4

Если возвращаться к изображением, то небольшие изображения в верхнем ротаторе по 200-170кб - это тоже не дело. Максимум по 50 кб на них должно хватить.

Да и вообще, при желании страницу можно уменьшить до размера меньше 1мб, а скорость загрузки поднять раз в 5.

Edited May 1, 2012 by dersmoll

[wildhind]

dersmoll, спасибо, хороший пост.

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

Однако скажу, что спрайтами злоупотреблять не стоит. Наверняка, говоря про «кучу графических объектов», вы имели в виду к примеру огромный список причин выбрать геокупол и икноки к нему. Да, их можно объединить в спрайт. Только тогда вопрос: как этим управлять из админки? Уточню вопрос: как этим очевидно управлять из админки человеку, который разбирается в торговом и демонстрационном оборудовании, но не разбирается в css?

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

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

Насчёт css вы спрашиваете — зачем усложнение. Теперь прочитайте css полностью, не выхватывая из контекста отдельные строки, и вам станет понятно, что это не усложнение, а упрощение. Упрощение себе работы за счёт опять же нескольких байт, которые придётся загрузить посетителю сайта.

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

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

Какой вывод напрашивается?

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

[dersmoll]

Однако скажу, что спрайтами злоупотреблять не стоит. Наверняка, говоря про «кучу графических объектов», вы имели в виду к примеру огромный список причин выбрать геокупол и икноки к нему. Да, их можно объединить в спрайт. Только тогда вопрос: как этим управлять из админки? Уточню вопрос: как этим очевидно управлять из админки человеку, который разбирается в торговом и демонстрационном оборудовании, но не разбирается в css?

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

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

Насчёт css вы спрашиваете — зачем усложнение. Теперь прочитайте css полностью, не выхватывая из контекста отдельные строки, и вам станет понятно, что это не усложнение, а упрощение. Упрощение себе работы за счёт опять же нескольких байт, которые придётся загрузить посетителю сайта.

Всегда пожалуйста, однако, я так просто не отстану

Давайте, вернемся к спрайтам. Естественно, говоря о спрайте, я не имел в виду контентные картинки, это само собой. Я скорее имел в виду практически все элементы оформления и кнопки. К примеру - #about button.submit, #specs .button_order .note, #specs .button_order .send_order_inactive, социальные иконки в футере и значек емейла там же. Эти и другие иконки/кнопки вполне комфортно чувствовали бы себя в одном спрайте, параллельно снижая нагрузку на сервер. Туда же можно было бы добавить и лого, раз оно нигде не продублировано картинкой. На самом деле, это так себе решение, потому что при печати клиент и посетители не увидят, откуда же эта страница отпечана, кроме текстовой ссылки в углу. Я придерживаюсь мнения, что лучше дублировать фон логотипа картинкой, скрывая для скринов и показывая для принта. Сайт только выиграет в качестве. Ну, или как минимум продублировать текстом название и слоган под ним.

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

На счет утяжеления стилей, не могу понять, почему такой код

footer.pagefoot table.footer_content td.contactus

лучше такого

.pagefoot .footer_content .contactus

Это было бы полезно, если у вас нет доступа к хтмл и работа ведется только из css, ну а так - теги отлично видны и в html. А вдруг вам по какой-то причине понадобится заменить таблицу на дивы или список - тогда придется делать замену по целому блоку стилей. (вдруг у клиента алергия на таблицы, у меня такие попадались )) ).