Комментарии 43
Не могу понять — вроде автор пишет про статик решение, но использует php. Понять «степень статичности» не даёт отсутсвие кода. Потом идёт сравнение непонятно чего непонятно с чем, причём видно что контент сравнимых сайтов разный (почему мы их тогда сравниваем?). Я не супер веб-мастер, но что-то мне подсказывает что скорость загрузки страниц будет в первую очередь зависеть от количества медиа-контента, закешированных элементов и оптимизированных запросов к бд, а не выбора статик/не статик
Доброго времени суток, это система управления контентом html страниц для статических проектов. Под капом PHP. В ближайшее время подготовлю более детальный обзор проекта. Дорабатываю еще несколько функций и проект должен увидеть свет. Касательно статики — здесь не могу сказать, что согласен, работа сайта на чистом HTML (без сборки какой-либо CMS либо любым другим решением) по-умолчанию быстрее. Сборщики статических сайтов, возможно, именно поэтому нашли своё применение. Да, конечно, работая с WP или же с решением более продвинутым имеет смысл работать с редисом, кешировать, подключать CDN и.т.п., но у нас много проектов, где статика — более экономное и продуктивное решение в обслуживании.
подготовлю более детальный обзор проекта
Т.е. это мы сейчас «тизер» статьи прочитали?)
Если проект статический значит там уже не должно быть никакого php.
Статический сайт — это сайт, который состоит из неизменяемых веб-страниц. Исходный код таких страниц состоит только из HTML и возможно ещё CSS и JavaScript (Wikipedia).
А тип с PHP нельзя?
Подобные решения можно делать на любом серверном языке программирования. В данном случае рассаматривается ситуация практического характера: у нас 50 доменов, на которых статические проекты (где-то билды от сбрщиков статических сайтов, где-то парсинг веб-архива), ценник переноса всего добра достаточно высок + время. Есть копирайтеры и сеошники, им нужна возможность менеджерить проект. К примеру, типичная задача: автоматически заменить тайтлы в каждом html. Проекты работают под Nginx вида: testdomain.com/history/world-history/index.html — и такого добра полно. При помощи моей админки каждый может в корень добавить один файлик, запустить его в браузере по ссылке и начать использовать инструменты. Также безболезненно удалить и порядок.
Очень-очень зря сравниваем друпалы с вордпресами и статичный сайт.
Собственно друпал и вордпрес для статичного сайта визитки использовать глупо — они генерят 100500 запросов в БД для одной страницы проверяя какой блок как и в каком месте выводить. Но ровно эта же их особенность дает возможность делать на них и каталог статей, и базу знаний, и магазин, простихоспади, и что угодно еще аж до соцсети — там где нужна динамика иногда имеет смысл применять такие CMS.
Вы сделали что-то для статичного сайта визитки. С точки зрения полезности упражнения — несомненно здорово. Велосипед? Однозначно да. Сравнивать стоит с гатсби, джекил, хуго. С другой стороны — ваше решение на пхп может быть тоже очень интересно с т.зр. управления, т.к. все что перечислил я требуют обычно чуть больше чем «залить по ftp в папку».
Собственно друпал и вордпрес для статичного сайта визитки использовать глупо — они генерят 100500 запросов в БД для одной страницы проверяя какой блок как и в каком месте выводить. Но ровно эта же их особенность дает возможность делать на них и каталог статей, и базу знаний, и магазин, простихоспади, и что угодно еще аж до соцсети — там где нужна динамика иногда имеет смысл применять такие CMS.
Вы сделали что-то для статичного сайта визитки. С точки зрения полезности упражнения — несомненно здорово. Велосипед? Однозначно да. Сравнивать стоит с гатсби, джекил, хуго. С другой стороны — ваше решение на пхп может быть тоже очень интересно с т.зр. управления, т.к. все что перечислил я требуют обычно чуть больше чем «залить по ftp в папку».
В нашем случае, главная проблема была в том, что доступ к редактированию должны иметь специалисты из различных сфер (к примеру, копирайтеры). Полагаю, что с ключевым проблемой таким путём решения я справился. Хуго обдумывал в качестве варианта, но API + указанный выше элемент задачи заставили пойти этой дорогой.
хотя WP, сбавляя в динамике появления новых сайтов
WP за 1 месяц (июнь, кажется) набрал больше 1% рынка (сайтов из первого миллиона Alexa). И динамика не сбавляет ход. Этот 1% — это половина рынка Друпала.
Я не к тому, что ВП топчик, а просто что эта фраза — очередное субъективное желание, выдаваемое за факт, без какого-либо изучения рынка, вообще.
Согласен, здесь я пустился в персональную эмпирику. Работая с OctoberCMS и подобными решениями, попал в «мыльный пузырь» этих сообществ. Но должен заметить, что, к примеру, OctoberCMS активно набирает популярность и как проводить исследования на этом поле не совсем ясно, поскольку сложно определить по внешним признакам CMS такого рода. Сейчас в наших проектах мы также переходим на другие решения, где был Wordpress, местами полностью избавляемся от сборки html через PHP (к примеру, у нас есть относительно «мёртвые сайты-блоги», проще спарсить все страницы и залить обычный HTML). Сори, если перешёл на тему своих баранов, но да, в моменте с вп я не был объективен, будем проверять данные лучше. Спасибо за обратную связь.
Ваше решение не является CMS, зачем тогда сравнивать с CMS/CMF?
Content Management System — у вас, судя по тексту, нет ни менеджмента, ни системы. У вас просто скрипт вывода готовых HTML файлов из текущей папки на основании ГЕТ параметров. В лучшем случае это "компоновщик", что ли.
Это не плохо и не хорошо — это данность. И это может работать для вас и ваших клиентов. Но называть это CMS — явно опрометчиво.
Понятное дело, что ваше решение быстрее — так как оно умеет меньше 1% того, что умеет ВП, или Друпал, или Джумла.
ЗЫ И из всех указанных хабов валиден только один — PHP. К остальным ваше решение не имеет отношения.
ЗЫ2 Вы же знаете, что не SQL-инъекциями едиными живут "хакеры"? И что с базой тоже можно легко писать код, который им не подвержен? И сайты можно взламывать по ГЕТ параметрам, без использования базы, заливая шелы?
Благодарен за объективные замечания касательно контекста. В ближайшее время подготовлю более детальный обзор решения. Управление контентом присутствует в виде работы с html файлами в папке, где добавляем файл. Касательно GET — да, согласен. В данном случае, файл админ. панели может иметь любое название, помимо этого без авторизации любого типа запросы не пройдут через роутер. Content Management System — не вижу несоответствий терминологии, хотя и согласен с Вами в контексте того, что до популярных решений моему далековато.
Тебе шашечки или ехать?Мне очень нравится сравнение двух страниц, одна из которых работает и в самом деле позволяет что-то сделать с телефона, а вторая даже на скриншоте в него не умещается и предположу что поработать в принципе не позволит, зато быстрая.
С удовольствием прочитал, ознакомился с Вами опытом, спасибо!
Добавлю, актуальности теме прибавляет ещё и вопрос нагрузки на сервер/хостинг.
С большой посещаемостью, да с некоторыми монстрами-CMS (не всеми!) — большая и нагрузка от повсеместной динамики. Иногда очень большая.
Добавлю, актуальности теме прибавляет ещё и вопрос нагрузки на сервер/хостинг.
С большой посещаемостью, да с некоторыми монстрами-CMS (не всеми!) — большая и нагрузка от повсеместной динамики. Иногда очень большая.
А что мешает кешировать любой сайт на любой цмс в статику?
Главная ниша использования — воскрешенные сайты с вебархива, небольшие проекты. Еще один вариант, который сейчас активно используем, даём копирайтерам на проектах, собранных статическими генераторами сайтов
Ну не, это ж надо разбираться, настраивать!
Ну еще м.б. какой-то пограничный кейс для хостингов для которых даже кратковременный скачок по ресурсам неприемлем. Т.к. инвалидация кеша-таки будет происходить, когда-то надо будет дергать бекенд и прочая (даже если время жизни бесконечное). Я понимаю что все скажут «это что за хостинг такой, веб сервер на умных часах что ли?», но я пытаюсь хоть как-то оправдать автора)
Ну еще м.б. какой-то пограничный кейс для хостингов для которых даже кратковременный скачок по ресурсам неприемлем. Т.к. инвалидация кеша-таки будет происходить, когда-то надо будет дергать бекенд и прочая (даже если время жизни бесконечное). Я понимаю что все скажут «это что за хостинг такой, веб сервер на умных часах что ли?», но я пытаюсь хоть как-то оправдать автора)
Валидацию кеша любите делать?
Этот подход от damnerd мне нравится больше. Как-то он современнее и понятнее. Пых занял нишу, я бы его не тянул в новые места только из-за того что пых родной.
Может быть посмотрел бы еше HUGO, Netlify CMS
habr.com/ru/company/e-Legion/blog/440134
Может быть посмотрел бы еше HUGO, Netlify CMS
habr.com/ru/company/e-Legion/blog/440134
На скриншоте производительность вёрстки, а не сервера. Что выдаст ab -n 1000 -c 50 сайт в пересчёте в графу RPS?
А ещё там сайт на сервере сравнивается с локальным сайтом :) URL на обоих скриншотах можно увидеть, если быть внимательным.
megastudio я серьёзно, не место на хабре контенту, который может обучить ложным предпосылкам. Потом появляются«веб-мастера», которые измеряют время отдачи контента битриксом через Pagespeed/Lisghthouse.
Уберите пожалуйста, сделайте нормальное измерение TTFB (например, через Chrome DevTools или 50-й перцентиль у ab) и/или максимальный RPS (например, через ab или wrk). Либо так, либо никак.
На StackOverflow принято минусовать контент, который ложный или ошибочный, тут не хочется (посыл статьи всё равно имеет место быть).
Уберите пожалуйста, сделайте нормальное измерение TTFB (например, через Chrome DevTools или 50-й перцентиль у ab) и/или максимальный RPS (например, через ab или wrk). Либо так, либо никак.
На StackOverflow принято минусовать контент, который ложный или ошибочный, тут не хочется (посыл статьи всё равно имеет место быть).
Pagespeed, как бы показывает статику за месяц у пользователей!!!
«сделайте нормальное измерение TTFB»
Кеш страниц может выплюнуть страницу моментально, ну и что с того ??? Если у вас там будет 20-30 скриптов с разных хостов и стелей на 1мб, про картинки не пожатые я молчу.
Пользователю все равно почему он не увидит страницу или из-за того что сервер долго готовил выдачу, или потому что там адовый треш со шрифтами.
Уж что-то а уменьшить время TTFB как правило одна из простых задач. Но многим тупо наплевать, они готовы и дальше сидеть на медленном хостинге. Разница бывает порой в 800-1200мс только от смены хостинга.
Ну и WP сам по себе если память не изменяет съедает 10-20мс. Так что сайты на WP может грузиться быстро, тут больше вопрос наверно к теме и плагинам.
Достаточно загуглить «google speed 100/100 WP», и после чего автора закидать помидорами.
«сделайте нормальное измерение TTFB»
Кеш страниц может выплюнуть страницу моментально, ну и что с того ??? Если у вас там будет 20-30 скриптов с разных хостов и стелей на 1мб, про картинки не пожатые я молчу.
Пользователю все равно почему он не увидит страницу или из-за того что сервер долго готовил выдачу, или потому что там адовый треш со шрифтами.
Уж что-то а уменьшить время TTFB как правило одна из простых задач. Но многим тупо наплевать, они готовы и дальше сидеть на медленном хостинге. Разница бывает порой в 800-1200мс только от смены хостинга.
Ну и WP сам по себе если память не изменяет съедает 10-20мс. Так что сайты на WP может грузиться быстро, тут больше вопрос наверно к теме и плагинам.
Достаточно загуглить «google speed 100/100 WP», и после чего автора закидать помидорами.
Порадовал критерий необходимостию что якобы гугл заставляет сидеть всез на статике из-за 3секунд.
Нет. Проблема в том, что ни гугл, ни яндекс, не умеют обходить динамические фреймворки по типу ангуляра или реакта. Потому все магазины и статейники сидят на движках, которые генерят html с контентом прям на серверной стороне. Допотопно, зато seo-робот такое сможет заиндексировать.
Нет. Проблема в том, что ни гугл, ни яндекс, не умеют обходить динамические фреймворки по типу ангуляра или реакта. Потому все магазины и статейники сидят на движках, которые генерят html с контентом прям на серверной стороне. Допотопно, зато seo-робот такое сможет заиндексировать.
Разве вы против, чтобы интернет быстрее работал?
А где про это написано? Я на сколько знаю гугл умеет это все делать (Основы поисковой оптимизации сайтов на JavaScript)
И гугл и яндекс умеют. Но на обход SPA нужно больше времени, и особенные поисковые краулеры. А их меньше, и работают медленнее. Как вывод:
— изменения на server-side сгенерированной странице могут проиндексироваться за неделю (20 минут, если оформили как новостник)
— изменения на SPA могут неиндексироваться 3-4 месяца.
А так да, гугл умеет это делать.
Примечание: можно найти контрпример, когда некоторые SPA индексируются быстро (банки например или новостники) — это актуально для трастовых сайтов, о которых роботы знают, и давным давно повысили им приоритет обхода. Но даже в этом случае, если бы они отдавали HTML, они бы быстрее индексировались.
К сожалению, поисковая оптимизация сейчас это не булевое свойство (есть она или нет), а бизнес-процесс без начала и конца.
— изменения на server-side сгенерированной странице могут проиндексироваться за неделю (20 минут, если оформили как новостник)
— изменения на SPA могут неиндексироваться 3-4 месяца.
А так да, гугл умеет это делать.
Примечание: можно найти контрпример, когда некоторые SPA индексируются быстро (банки например или новостники) — это актуально для трастовых сайтов, о которых роботы знают, и давным давно повысили им приоритет обхода. Но даже в этом случае, если бы они отдавали HTML, они бы быстрее индексировались.
К сожалению, поисковая оптимизация сейчас это не булевое свойство (есть она или нет), а бизнес-процесс без начала и конца.
А можете конкретно дать ссылку на проекты, где есть эта система?
Здравствуйте, не совсем корректно давать ссылки на все проекты. Могу дать только свой — прект виджета отзывов для сайта (сюдой: optiviewer.info), но не думаю, что вы сможете воспользоваться системой либо попробовать поотправлять запросы к файлу админ. панели. Как писал выше, этот один файлик можно переименовать как душе угодно, а можно и удалить после процедуры редактирования/добавления/удаления, поиска контента и.т.п. Нету файла, соответственно, нет к чему отправлять запросы)
CMSimple и CMSimple_XH. Не это ли Вы мастерите?
Приветствую, во многом сходится, но не понял по описанию в википедии, она также обслуживает статические сайты?
Что имею ввиду: если CMSimple — на сервере работает как роутер (т.е. все запросы идут через некий index.php, какой-либо другой файл), в таком случае — мое решение никак на себя не берет роутинг (кроме внутреннего, который связан именно с самой админ. панелью). Также сразу возникает вопрос внедрения: можно ли CMSimple и CMSimple_XH поставить на проект, сделать нужную работу и удалить без последствий?)
Предлагаю для ознакомления halocoder.ilost.ru
файловый менеджер и редактор на php, один файл, бесплатный, свободный
Также я начинал делать на нем CMS, но уже не в один файл.
Если разработка понравится — можете ее использовать для удобства редактирования файлов онлайн. Для безопасности просто смените имя файла на рендомное. Или могу дополнить формой входа по паролю.
Будут вопросы или предложения — пишите.
файловый менеджер и редактор на php, один файл, бесплатный, свободный
Также я начинал делать на нем CMS, но уже не в один файл.
Если разработка понравится — можете ее использовать для удобства редактирования файлов онлайн. Для безопасности просто смените имя файла на рендомное. Или могу дополнить формой входа по паролю.
Будут вопросы или предложения — пишите.
Автор, у меня к вам два вопроса:
1. Почему бы не использовать статическую генерацию какого-нибудь модного фронтенд-фреймворка? Например, такое есть у nuxt.js из экосистемы vue. Уверен, есть и у Реакта, и у Ангуляра, просто не изучал этот вопрос. Так вот, генератор статики nuxt умеет при формировании страниц обходить с помощью написанной вами функции динамические маршруты, дергать, например, серверный api, и генерировать из этого статические файлы. Серверный api, при этом, может быть быстро написан на чем-то типа symfony+api platform, laravel тоже умеет в api. Хочется больше самописного — используйте slim, отличная штука. Но зачем генерировать html статику силами php?
2. Я так и не понял, с какой такой целью вы всё запихнули в один php файл? Как это потом поддерживать? Или разработка идет нормальным образом, а при сборке все склеивается в один файл? Но все равно, непонятно, зачем. Есть же phar, например. Есть докер. Да просто установить cms через composer create-project разве сложно?
В общем, идея ясна и вполне оправдана (имею проект, у которого основная часть страниц сгенерированы в статику и только админка/личный кабинет представляют из себя spa с api на php). Но вот реализация, на мой взгляд, странная
1. Почему бы не использовать статическую генерацию какого-нибудь модного фронтенд-фреймворка? Например, такое есть у nuxt.js из экосистемы vue. Уверен, есть и у Реакта, и у Ангуляра, просто не изучал этот вопрос. Так вот, генератор статики nuxt умеет при формировании страниц обходить с помощью написанной вами функции динамические маршруты, дергать, например, серверный api, и генерировать из этого статические файлы. Серверный api, при этом, может быть быстро написан на чем-то типа symfony+api platform, laravel тоже умеет в api. Хочется больше самописного — используйте slim, отличная штука. Но зачем генерировать html статику силами php?
2. Я так и не понял, с какой такой целью вы всё запихнули в один php файл? Как это потом поддерживать? Или разработка идет нормальным образом, а при сборке все склеивается в один файл? Но все равно, непонятно, зачем. Есть же phar, например. Есть докер. Да просто установить cms через composer create-project разве сложно?
В общем, идея ясна и вполне оправдана (имею проект, у которого основная часть страниц сгенерированы в статику и только админка/личный кабинет представляют из себя spa с api на php). Но вот реализация, на мой взгляд, странная
По поводу однофайлика есть идея.
Почему бы не делать его генерируемым? Т.е. вы вполне можете писать себе по ООПешному, да даже условно на фреймверке, но весь код путем запуска скрипта упаковать по вашим правилам в тот самый 1 файл.
Почему бы не делать его генерируемым? Т.е. вы вполне можете писать себе по ООПешному, да даже условно на фреймверке, но весь код путем запуска скрипта упаковать по вашим правилам в тот самый 1 файл.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как я за вечер написал быструю CMS для статических сайтов по правилам бизнес-логики в одном файлике