- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Что делать, если ваша email-рассылка попала в спам
10 распространенных причин и решений
Екатерина Ткаченко
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
рассуждения уровня лендинг на одну страницу и, образно говоря, обновляемый блог
Мы, когда то, еще в институте с одногруппниками, в волосатые годы, сделали себе большой спортивный портал. Без всяких CMS и т.д. Просто добавляли html файлы, писали в них текста.
Эх, понастальгировал.
Если серьезно.
+ статики - быстрее работает, нет лишних скриптов, запросов к базе и т.д.
+ динамики - одним словом "динамика", удобство работы с сайтом
статики - быстрее работает, нет лишних скриптов, запросов к базе и т.д.
Я не сильно тебя расстрою, если открою "секрет" - БД как раз и были придуманы для того, чтобы снизить время получения данных (чит: ускорить сайт)? Ибо обращение к HDD (+др работа с файлами) - это самое медленное во всей системе на физ. уровне.
Если серьезно.
+ статики - быстрее работает, нет лишних скриптов, запросов к базе и т.д.
Откуда вы (люди) выкапываете этот аргумент все время, любую динамику можно превратить в статику (автоматически) которая будет работать по скорости ровно так же, за то обратное сделать проблематично.
И если серьезно, нет у статики никаких плюсов на 2017 год. Сервера стоят по 15 евро в месяц в 8 Гб оперативки, то есть 1 час работы программиста, вопрос, что дешевле сервер взять для цмс и посадить секретаря менять/добавлять/редактировать или программиста за 10-15$ в час?
---------- Добавлено 19.01.2017 в 12:11 ----------
Я не сильно тебя расстрою, если открою "секрет" - БД как раз и были придуманы для того, чтобы снизить время получения данных (чит: ускорить сайт)? Ибо обращение к HDD (+др работа с файлами) - это самое медленное во всей системе на физ. уровне.
Я тоже тебе открою секрет, база данных тоже хранит информацию на HDD и тоже от туда её читает. Изначально БД делались не для "ускорить сайт", а для удобной, каталогизированной работы с однородной информацией (читай таблицами). Это становится действительно быстро когда дело касается по работе с информацией ( выборки, сортировки и так далее), но если исходить из вопроса прочитал с файла - показал, БД как бы ничем не быстрее. Это я говорю про реляционные БД конечно, те что висят в оперативки они читают (если работают конечно с ФС) с HDD только на старте, ну и периодами сбрасывают на диск.
но если исходить из вопроса прочитал с файла - показал, БД как бы ничем не быстрее.
Это вообще вопрос неоднозначный. Может и быстрее, а может даже и медленнее. Тут задействовано слишком много различных факторов, что бы обобщать и махать шашкой.
Изначально БД делались не для "ускорить сайт",
Я написал для чего. Тебе не понятно что в скобках значит слово "читай:"? ОК, объясню. "Ускорить сайт" - это и образ и, собсно, конечная цель, если рассматривать "сайт" как одно из приложений для юзера.
И собсно я говорил о том, что процитированная фраза слишком далека от реальности :).
Поделюсь опытом.
2 года назад перенес сайты некоторых компаний с Bitrix на html + css + include. это решение было принято для очень конкурентной ниши, чтобы увеличить конверсию путем тотального изменения сайта.
Плюсы:
1. Полная свобода действий над сайтами, нет никаких проблем для внедряемых изменений.
2. Скорость загрузки - просто в разы увеличилась.
3. Стоимость доработки сайта - в разы меньше.
4. Каждая страница - может быть уникальной, никакими шаблонами не ограничиваемся.
Минусы:
1. Скорость внедрения фишечек.
2. Скорость внесения контента. (В каждой компании есть контент-менеджер, но копаться в коде - гораздо медленнее чем забивать все в формы).
3. За пару лет я не смогу уже назвать эти сайты на PHP + HTML + CSS - фактически столько фишек докрутили и повнедряли для автоматизации некоторых процессов, что теперь считай получили собственную CMS.
PS: Буду ли дальше действовать в такой идеологии.
Да, буду. Использовать CMS там, где нет в этом необходимости - вызывает только дополнительные проблемы.
Поделюсь опытом.
2 года назад перенес сайты некоторых компаний с Bitrix на html + css + include. это решение было принято для очень конкурентной ниши, чтобы увеличить конверсию путем тотального изменения сайта.
Я конечно не сноб, но это исключительно ваш опыт, а кто то делает наоборот, переносит на CMS чтобы можно было нормально работать с сайтом.
Плюсы:
1. Полная свобода действий над сайтами, нет никаких проблем для внедряемых изменений.
2. Скорость загрузки - просто в разы увеличилась.
3. Стоимость доработки сайта - в разы меньше.
4. Каждая страница - может быть уникальной, никакими шаблонами не ограничиваемся.
Все ваши плюсы упираются в незнание конкретных CMS
1. Не знаю не одну CMS у которой есть проблемы для внедряемых изменений.
2. У всех CMS есть кэшировани, которое включается по кнопке и делает сайт статичным, сохраняя вывод в файл, на крайняк можно конфиг у прокси сервера подправить.
3. Я бы сильно поспорил с этим пунктом. Он будет истинным только в том случае, если архитектор и программисты в этом проекте оч крутые ребята, а это очень очень дорого, и я так понимаю там сейчас лапша код, сильная связность с конкретной БД с паролем в каждом файле и прочие "прелести" жизни.
4. Не знаю CMS которая ограничивает фронтедом, а вами приведенная CMS шаблоны может настраивать даже на параметры в урле, а про страницы то вообще молчу.
Минусы:
1. Скорость внедрения фишечек.
2. Скорость внесения контента. (В каждой компании есть контент-менеджер, но копаться в коде - гораздо медленнее чем забивать все в формы).
3. За пару лет я не смогу уже назвать эти сайты на PHP + HTML + CSS - фактически столько фишек докрутили и повнедряли для автоматизации некоторых процессов, что теперь считай получили собственную CMS.
Глобальный минус тут только 1 из которого вытекает много много маленьких - это
считай получили собственную CMS
То есть по факту вы переделали с одной CMS на другую, потому что первую вы собственно не знали. Но получили CMS которую кроме вас теперь никто не знает, ничего под ней не пишет (считайте все писать самим) и где тут плюсы вообще непонятно если честно. Лучше выучить что нибудь популярное, хорошо протестированное и поддерживаемое сообществом, чем пилить свои костыли особенно если не хватает квалификации, а её в чем то но не хватает.
PS. Вывод "перенес сайты некоторых компаний с Bitrix на nonameCMS" и получил плюсы. А все уперлось, что битрикс не знаем, а nonameCMS знаем как свои 5 пальцев, по этому есть и плюсы.
PPS. Загрузка битрикса главной страницы одной мебельной компании:
Первый хит:
Последующие:
Статика то может и быстрее, но оно надо ли?
MIKLFIRM, Ну так вы и фактически написали свой велосипед, но назвали его "устройство самобеглое с двумя колесами"
Означает-ли это то, что вы перешли с коробочной CMS на собственную? -- Да. означает.
Означает-ли это то, что вы перешли с CMS на статику - нет. не означает.
зы.
Может помните, был раньше такой сайт, сотовик. Он и сейчас есть, но как-то особо не гремит в интернетах. Так вот. Там пошли таким путем.
у них был бэкоффис самопильный, в который менеджеры добавляли контент, статьи и т.д. а потом всё это в компилированном виде заливалось на фронтэнд в виде голых HTML-ек. И надо сказать, во времена, когда сервера стоили как автомобиль, а народ уже начал валить, это очень здорово помогло снизить время загрузки.
да и сейчас во многих цмс-инах есть подобные алгоритмы кэширования. То-есть на юрл генерится статика, а потом по запросу она отдается