Статический сайт на html VS Динамический сайт на CMS

1 23
tommy-gung
На сайте с 22.11.2006
Offline
295
#21

рассуждения уровня лендинг на одну страницу и, образно говоря, обновляемый блог

Здесь не могла быть ваша реклама
LD
На сайте с 28.05.2012
Offline
86
#22

Мы, когда то, еще в институте с одногруппниками, в волосатые годы, сделали себе большой спортивный портал. Без всяких CMS и т.д. Просто добавляли html файлы, писали в них текста.

Эх, понастальгировал.

Если серьезно.

+ статики - быстрее работает, нет лишних скриптов, запросов к базе и т.д.

+ динамики - одним словом "динамика", удобство работы с сайтом

Простая CMS для сложных решений - NespiCMS (http://www.nespicms.com) Создание сайтов любой сложности (http://www.ideyne.com) Портал для туристов (http://www.hotelguide.com.ua)
SeVlad
На сайте с 03.11.2008
Offline
1609
#23
Loki_Dex:
статики - быстрее работает, нет лишних скриптов, запросов к базе и т.д.

Я не сильно тебя расстрою, если открою "секрет" - БД как раз и были придуманы для того, чтобы снизить время получения данных (чит: ускорить сайт)? Ибо обращение к HDD (+др работа с файлами) - это самое медленное во всей системе на физ. уровне.

Делаю хорошие сайты хорошим людям. Предпочтение коммерческим направлениям. Связь со мной через http://wp.me/P3YHjQ-3.
Aisamiery
На сайте с 12.04.2015
Offline
302
#24
Loki_Dex:

Если серьезно.
+ статики - быстрее работает, нет лишних скриптов, запросов к базе и т.д.

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

И если серьезно, нет у статики никаких плюсов на 2017 год. Сервера стоят по 15 евро в месяц в 8 Гб оперативки, то есть 1 час работы программиста, вопрос, что дешевле сервер взять для цмс и посадить секретаря менять/добавлять/редактировать или программиста за 10-15$ в час?

---------- Добавлено 19.01.2017 в 12:11 ----------

SeVlad:
Я не сильно тебя расстрою, если открою "секрет" - БД как раз и были придуманы для того, чтобы снизить время получения данных (чит: ускорить сайт)? Ибо обращение к HDD (+др работа с файлами) - это самое медленное во всей системе на физ. уровне.

Я тоже тебе открою секрет, база данных тоже хранит информацию на HDD и тоже от туда её читает. Изначально БД делались не для "ускорить сайт", а для удобной, каталогизированной работы с однородной информацией (читай таблицами). Это становится действительно быстро когда дело касается по работе с информацией ( выборки, сортировки и так далее), но если исходить из вопроса прочитал с файла - показал, БД как бы ничем не быстрее. Это я говорю про реляционные БД конечно, те что висят в оперативки они читают (если работают конечно с ФС) с HDD только на старте, ну и периодами сбрасывают на диск.

Разработка проектов на Symfony, Laravel, 1C-Bitrix, UMI.CMS, OctoberCMS
SeVlad
На сайте с 03.11.2008
Offline
1609
#25
Aisamiery:
но если исходить из вопроса прочитал с файла - показал, БД как бы ничем не быстрее.

Это вообще вопрос неоднозначный. Может и быстрее, а может даже и медленнее. Тут задействовано слишком много различных факторов, что бы обобщать и махать шашкой.

Aisamiery:
Изначально БД делались не для "ускорить сайт",

Я написал для чего. Тебе не понятно что в скобках значит слово "читай:"? ОК, объясню. "Ускорить сайт" - это и образ и, собсно, конечная цель, если рассматривать "сайт" как одно из приложений для юзера.

И собсно я говорил о том, что процитированная фраза слишком далека от реальности :).

MIKLFIRM
На сайте с 13.02.2010
Offline
166
#26

Поделюсь опытом.

2 года назад перенес сайты некоторых компаний с Bitrix на html + css + include. это решение было принято для очень конкурентной ниши, чтобы увеличить конверсию путем тотального изменения сайта.

Плюсы:

1. Полная свобода действий над сайтами, нет никаких проблем для внедряемых изменений.

2. Скорость загрузки - просто в разы увеличилась.

3. Стоимость доработки сайта - в разы меньше.

4. Каждая страница - может быть уникальной, никакими шаблонами не ограничиваемся.

Минусы:

1. Скорость внедрения фишечек.

2. Скорость внесения контента. (В каждой компании есть контент-менеджер, но копаться в коде - гораздо медленнее чем забивать все в формы).

3. За пару лет я не смогу уже назвать эти сайты на PHP + HTML + CSS - фактически столько фишек докрутили и повнедряли для автоматизации некоторых процессов, что теперь считай получили собственную CMS.

PS: Буду ли дальше действовать в такой идеологии.

Да, буду. Использовать CMS там, где нет в этом необходимости - вызывает только дополнительные проблемы.

Жизнь в стиле IT (http://www.mikl.su) Мои отзывы (http://about-hosting.ru/) о хостингах.
Aisamiery
На сайте с 12.04.2015
Offline
302
#27
MIKLFIRM:
Поделюсь опытом.
2 года назад перенес сайты некоторых компаний с Bitrix на html + css + include. это решение было принято для очень конкурентной ниши, чтобы увеличить конверсию путем тотального изменения сайта.

Я конечно не сноб, но это исключительно ваш опыт, а кто то делает наоборот, переносит на CMS чтобы можно было нормально работать с сайтом.

MIKLFIRM:

Плюсы:
1. Полная свобода действий над сайтами, нет никаких проблем для внедряемых изменений.
2. Скорость загрузки - просто в разы увеличилась.
3. Стоимость доработки сайта - в разы меньше.
4. Каждая страница - может быть уникальной, никакими шаблонами не ограничиваемся.

Все ваши плюсы упираются в незнание конкретных CMS

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

2. У всех CMS есть кэшировани, которое включается по кнопке и делает сайт статичным, сохраняя вывод в файл, на крайняк можно конфиг у прокси сервера подправить.

3. Я бы сильно поспорил с этим пунктом. Он будет истинным только в том случае, если архитектор и программисты в этом проекте оч крутые ребята, а это очень очень дорого, и я так понимаю там сейчас лапша код, сильная связность с конкретной БД с паролем в каждом файле и прочие "прелести" жизни.

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

MIKLFIRM:

Минусы:
1. Скорость внедрения фишечек.
2. Скорость внесения контента. (В каждой компании есть контент-менеджер, но копаться в коде - гораздо медленнее чем забивать все в формы).
3. За пару лет я не смогу уже назвать эти сайты на PHP + HTML + CSS - фактически столько фишек докрутили и повнедряли для автоматизации некоторых процессов, что теперь считай получили собственную CMS.

Глобальный минус тут только 1 из которого вытекает много много маленьких - это

MIKLFIRM:

считай получили собственную CMS

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

PS. Вывод "перенес сайты некоторых компаний с Bitrix на nonameCMS" и получил плюсы. А все уперлось, что битрикс не знаем, а nonameCMS знаем как свои 5 пальцев, по этому есть и плюсы.

PPS. Загрузка битрикса главной страницы одной мебельной компании:

Первый хит:

Последующие:

Статика то может и быстрее, но оно надо ли?

S
На сайте с 13.10.2014
Offline
171
#28

MIKLFIRM, Ну так вы и фактически написали свой велосипед, но назвали его "устройство самобеглое с двумя колесами"

Означает-ли это то, что вы перешли с коробочной CMS на собственную? -- Да. означает.

Означает-ли это то, что вы перешли с CMS на статику - нет. не означает.

зы.

Может помните, был раньше такой сайт, сотовик. Он и сейчас есть, но как-то особо не гремит в интернетах. Так вот. Там пошли таким путем.

у них был бэкоффис самопильный, в который менеджеры добавляли контент, статьи и т.д. а потом всё это в компилированном виде заливалось на фронтэнд в виде голых HTML-ек. И надо сказать, во времена, когда сервера стоили как автомобиль, а народ уже начал валить, это очень здорово помогло снизить время загрузки.

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

1 23

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