Достижение "легкости" веб-проекта, при насыщенном функционале
17 января 2009 в 23:19

Достижение "легкости" веб-проекта, при насыщенном функционале

Я уже говорил о проблеме различного уровня в Регионах России. Передо мной стоит задача, создать проект, целевая аудитория которого представители регионов России, где качество интернета не всегда приемлемо, если сравнивать с Московскими или Питерским, или другими городами-миллионниками страны. Хотел бы услышать от Вас совет, на что обратить внимание при создании такого ресурса для достижения максимального его облегчения при сохранении довольно серьезного функционала проекта. Я прекрасно понимаю, что минимум графики, качественная верстка, хороший хостинг…а еще?

171
Комментарии (27)
  • 17 января 2009 в 23:21 • #
    Евгений В. Молев

    кеширование тяжелых динамически формируемых страниц.

  • 17 января 2009 в 23:22 • #
    Евгений Евгененко

    а это поволит работать системам контекстной рекламы на страницах???

  • 17 января 2009 в 23:39 • #
    Евгений В. Молев

    думаю да. можно сделать ведь что угодно и как угодно...

    главное вовремя и грамотно поставить задачу.

  • 17 января 2009 в 23:40 • #
    Евгений Евгененко

    точно знаю, что Бегун не разрешает включать кеширование

  • 17 января 2009 в 23:41 • #
    Евгений В. Молев

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

  • 17 января 2009 в 23:48 • #
    Владимир Дубровский

    Нафиг флеш и минимум ява-скриптов

  • 18 января 2009 в 00:46 • #
    Sergey Kormilitsyn

    Абсолютно согласен и оптимизировать можно только под MS IE =)

  • 18 января 2009 в 00:59 • #
    Евгений Евгененко

    Почему, думаете в регионах только им пользуются, насчет подавляющего большинства согласен, но думаю что не более 60%

  • 18 января 2009 в 01:11 • #
    Sergey Kormilitsyn

    Ну как правило то, что простое без flash, с минимумом java и отлично смотрится и работает в IE, будет так же неплохо смотреться например в opera и лисе. А по поводу процента пользователей думаю несколько больше ;)

  • 27 февраля 2009 в 15:44 • #
    Андрей Никитин

    эти 60% большинство. поэтому если делать красивый функциональный проект готовьтесь отлаживать.

  • 18 января 2009 в 12:26 • #
    Евгений В. Молев

    ишак уходит с арены.. щас будет популярнее хром и огненый лис.

  • 18 января 2009 в 16:50 • #
    Владимир Дубровский

    Старую добрую Оперу - эффективный скачивающий и тут же отображаемый браузер - не забывайте.

  • 18 января 2009 в 16:59 • #
    Евгений В. Молев

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

  • 18 января 2009 в 01:48 • #
    Айрат Давлетшин

    1. легковесный Web-сервер заместо Apache - Nginx
    2. отдельный сервер/а для картинок, видео, музыки и прочей "статики" + их кэширование
    3. кластеры из серверов баз данных, вебсерверов, серверов статического контента
    4. "балансер", распределяющий нагрузку на разные сервера кластера
    и тд и тд и тд.....

  • 18 января 2009 в 12:27 • #
    Евгений В. Молев

    вот это сурьезно!

  • 28 января 2009 в 16:53 • #
    Сергей Шивалин

    и у нас получается
    4. эдак, если покупать, 50к$, если аренда, от 20к рублей

    в общем, серьезная заявка

  • 18 января 2009 в 08:32 • #
    Алексей Оглоблин

    Скриптовую "раздробленность" вообще нужно делать как можно меньше.

    Обратите внимание на вот такой нюанс.
    Строгое кадрирование графических изображений.
    А именно, значение в описателях width и height ДОЛЖНЫ СОВПАДАТЬ с размерами самих графических оригиналов изображений.

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

    Честно говоря, уже устал бороться и объяснять это везде и всюду. Люди просто ленятся адекватно указывать соответствующие значения в этих дескрипторах тегов графических элементов. Или просто - в папку графики бузуются оригиналы огромных размеров в пикселях (1000, 2000), а браузер затем мучается - их кадрирует.

    Словом, если картинка 200*100px (штандарт-"графобуквица" в начале статьи), то и оригинал в папке графики должен быть этих же размеров.

  • 18 января 2009 в 12:30 • #
    Евгений В. Молев

    мне кажется это само собой разумеется, и бороться не стоит)

  • 18 января 2009 в 16:47 • #
    Владимир Дубровский

    Если вы в перспективе дадите пользователю галерею - очень серьезное заявляние на ускорение графики :)

  • 18 января 2009 в 16:49 • #
    Евгений В. Молев

    про перспективы не понял..

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

  • 18 января 2009 в 16:53 • #
    Владимир Дубровский

    Сразу разработать нормальную галерею - в скрипте: загрузил, мастабировал - сохранил и отобразил.

  • 18 января 2009 в 16:58 • #
    Евгений В. Молев

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

  • 19 января 2009 в 00:29 • #
    Владимир Дубровский

    Давайте посотрудничаем ... есть проект.
    #

    Связку MODx - parser3 сможете проверить?

  • 19 января 2009 в 09:22 • #
    Евгений В. Молев

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

  • 18 января 2009 в 13:11 • #
    Илья Балбашов

    Smarty, к примеру, умеет делать выборочное кеширование частей контента страницы (создавая сохраненные откомпилированные блоки).
    Можно также установить динамические кешеры в RAM (для PHP, насколько помню, есть два известных).
    Также на новостных страницах и блогах можно "играть" хедером Vary.
    Само собой, в том же Apache есть стандартные модули управления кешированием (для графики, флеш, JS, итд).
    Совершенно согласен про требование указания размеров графики (я, например, их формировал динамически и затем кешировал).
    Насчет уменьшения применимости JS и DHTML не согласен. Проблема с быстродействием решается вынесением в отдельные кешируемые файлы javascript кода и CSS описаний. Кроме того, разумное применение DHTML+AJAX как раз может дать видимое увеличение быстродействия.
    Еще, по личному опыту, серьезно влияет на скорость работы движка сайта, как ни странно, оптимизация БД (как структуры, так и самих SQL запросов).

  • 27 января 2009 в 16:00 • #
    Валентин Иванов

    Обратите внимание на бюджет!
    Чем "тяжелее" бюджет тем "легче" веб-проект.
    Вот господа рассуждаете про открытые бесплатные системы,
    рекомендации даете... а может своим обсуждением огорчаем г.Евгененко.
    Может бюджет ого-го. Может обсудим Sun, Солярку и Oracle? Коммерческие решения поинтереснее. Да и зарекомедовали себя хорошо в Кении, Зимбабве и т.п. в смысле там тоже не очень хорошо с качеством интернета.
    Какой бюджет? Тайн выдавать не надо. Хоть как-то сорентируйте.
    Больше 10 000р или чуть больше 1млн.$ (США)

  • 2 марта 2009 в 03:01 • #
    Alexander Brovkin

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

  • Желаете ознакомиться с остальными комментариями или оставить свой? в сеть, чтобы получить полный доступ к функционалу Профессионалов.ru! Еще не участник сети?