- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Стили страницы и javascript-код вынесены во внешние файлы. Количество таких файлов - минимально возможное.
Последнее совсем непонятно. Почему?
Если сайт очень разветвленый и имеет достаточно много всяких заморочек в виде JS и CSS почему все стилевые таблицы и JS нужно в один файл вбабахивать? М.б. наоборот? Лучше, когда уникальные JS подгружаются (и кэшируются) по мере надобности?
не читал тему, читал только первые абзаца 2 статьи "12 признаков качественного сайта" и не понравилось, не согласен с критериями.
Стили страницы и javascript-код вынесены во внешние файлы. Количество таких файлов - минимально возможное.
Последнее совсем непонятно. Почему?
Если сайт очень разветвленый и имеет достаточно много всяких заморочек в виде JS и CSS почему все стилевые таблицы и JS нужно в один файл вбабахивать? М.б. наоборот? Лучше, когда уникальные JS подгружаются (и кэшируются) по мере надобности?
Был тут проект с богатым клиентом (имеется ввиду что сайт в браузере как нормальное приложение работает). Ясное дело ajax js по полной использовался. Файлов JS было на 1 мегабайт. Разбили все это хозяйство на красивые маленькие структурированные кусочки. Итого получилось 1000 файлов;-))
Вообщем первая страница грузилась полчаса:-). Покумекали, на этапе сборки слили 1000 файлов в один и его подключали из страницы. Страница стала грузится очень быстро (относительно конечно: получилось что нужно грузить один сжатый файл весом 100кило).
Но это крайний случай, а так конечно лучше дробить.
с богатым клиентом
- "толстый" клиент, ага.
грузить один сжатый файл
как грузить сжатый JS? подскажите.
Я всеми конечностями за дивы. W3 за них кричит, чтобы страницы смотрелись во всех устройствах, но ведь иногда не получается как хочется. Война браузеров не закончилась - у одних край бокса включает рамку у других нет - достали...
Да что вы все за DIV так агитируете. Я например, привых к table, ну и что - это плохо? Да W3 не рекомендует, ну и что я от этого потерял? Да ничего. В конечном итоге мерой всего является траф. А DIV, table - это все темы для разговоров тех, кому заняться в данный момент нечем.
А DIV, table - это все темы для разговоров тех, кому заняться в данный момент нечем...
...сказал shav, бурно защищая табличную верстку.
Есть преимущества у блочной верстки, есть! И все таки я разделяю мнение людей, которые говорят об умелом использовании обоих типов верстки в зависимости от поставленных задач. Другой вопрос, что до блочной верстки надо дорасти☝, а табличной верстке учат в книжках вроде "HTML шаг за шагом".
...сказал shav, бурно защищая табличную верстку.
Есть преимущества у блочной верстки, есть! И все таки я разделяю мнение людей, которые говорят об умелом использовании обоих типов верстки в зависимости от поставленных задач. Другой вопрос, что до блочной верстки надо дорасти☝, а табличной верстке учат в книжках вроде "HTML шаг за шагом".
Я не защищаю. Пусь люди верстают так как им нравиться, и не надо им указывать.
Представте в доказательство своих слов несколько преимуществ блочной верстки.
Сложности в верстке в DIVах не вижу никаких. Может раскажите в чем эту сложность видите Вы?
12 признаков качественного сайта
усе ..приплыли
оказывается хорошие сайты сейчас надо уже только по признакам находить - дооптимизировались :)
shav, никто никому не указывает, между прочим.
А если не видите никаких сложностей, то почему продолжаете делать таблицами?
Я не защищаю. Пусь люди верстают так как им нравиться, и не надо им указывать. Сложности в верстке в DIVах не вижу никаких. Может раскажите в чем эту сложность видите Вы?
Я бы тогда разделил блочную верстку на 2 категории: сделать и сделать качетсвенно (особенно когда речь идет о сайте с оригинальзым дизайном, а не о портале в 3 колонки). Так вот сделать сможет каждый, а вот сделать как следует и чтобы всегда и везде адекватно отображалось - очень немногие. Вот я, признаться, не могу, поэтому до сих использкю исключительно табличную верстку, сложно переключиться, когда времени на верстку - пол дня. А Вы либо относитель к категории "сделать" и лукавите, либо Вы очень опытный верстальщик и это вызывает только уважение и еще вызывает удивление, что Вы не пользуетесь своими способностями, а по старинке верстаете в таблицах.
Представте в доказательство своих слов несколько преимуществ блочной верстки.
Преимущества есть, есть они и у табличной вертски и не вижу смысла продолжать религиозные войны, на эту тему есть много других военных полигонов, не будем засорять топик. Скажу лишь одно: блочная верстка, как мне кажется, гораздо более гибкий и адаптивный интсрумент. Рискну провести параллель с разными подходами в программировании: процедурный подход и объектно-ориентированный. Процедурный подход проще и как правило с таким подходом быстрее решаются сиюминутные задачи, но когда речь идет о серьезном (крупном) проекте и "качественном сайте", то откажутся от приминения ООП только те, кто вчера прочитал книжку "PHP для чайников". Но ведь ни один пользователь не узнает какими методами разработки Вы пользуетесь. Может тогда и не заморачиваться с ООП ?! (вопрос риторический)