Каковы плюсы и минусы использования пользовательского интерфейса для получения контента из серверной части Wordpress?

Question

Я занимаюсь созданием сайтов на WordPress уже несколько лет и заметил несколько вещей, которые меня беспокоят.

1.Это довольно медленно (ужасное заявление, прошу прощения)

Мое первоначальное желание создать собственный интерфейс возникло из наблюдения.Сайты Wordpress, которые я создавал, работали не так быстро, как мне хотелось (3-5 секунд, иногда дольше).

@Kenrik - Они, конечно, были развернуты на перепроданном виртуальном хостинге, но получили хорошие оценки Yslow.Я опробовал это и обнаружил, что сайты работают примерно в три раза быстрее, когда я не загружаю накладные расходы WP.Та же машина, тот же показатель Yslow, в 3 раза быстрее.Я не эксперт по использованию процессора Wordpress, но я читал, что он довольно интенсивный, поэтому я не был удивлен достигнутым приростом скорости.

2.Часто это слишком сложно для нужд простого веб-сайта.

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

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

3.Имеет много проблем с безопасностью (особенно при использовании плагинов)

Что касается безопасности, то я вижу, насколько мой вопрос был неоднозначным и противоречивым.Я имел в виду, что, насколько я понимаю, сайт Wordpress, за исключением каких-либо реальных дыр в безопасности, уязвим, поскольку злоумышленники знают, что это сайт Wordpress.Это создает проблему (взлом популярной платформы) и встроенную шпаргалку (уязвимости WordPress хорошо документированы).Итак, конечно, в специальном решении может быть больше дыр в безопасности, но мне интересно, не будет ли это уравновешено тем фактом, что оно делает внутреннюю работу анонимной.Как сказал @Kenrik, «они, скорее всего, даже не будут беспокоиться, потому что кого волнует взлом одного сайта с помощью сомнительного специального кода?»

4.Трудно оптимизировать время загрузки страницы

Под сложностью оптимизации загрузки страниц я имел в виду, что если добиться интерактивной функциональности с помощью множества плагинов, загружается множество скриптов, и становится более утомительно возвращаться и комбинировать, изменять, настраивать или оптимизировать их.Мне проще включать плагины jQuery за пределами Wordpress и не разбираться с тем, как они подключаются к wp_head.

Поэтому недавно я решил пойти по-другому в своей разработке и использовать Wordpress только как внутренний инструмент.Я использую пространство администратора для обновления контента и заполнения базы данных, но я использую пользовательский уровень доступа к данным и пользовательские функции во внешнем интерфейсе для получения и отображения контента.Для страниц, где требуется вход в систему, я включаю файл заголовка блога и использую функции управления учетными данными WordPress.

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

Потенциальные минусы:Безопасность, отсутствие масштабируемости, отсутствие поддержки разработчиками нестандартных решений...Что-нибудь еще ?

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

Пожалуйста, дайте мне знать, если это так.

Ваше здоровье

Заключим задним числом:

Я на 100% уверен, что мои сайты работают быстрее в той же среде, даже если я не использую собственный интерфейс Wordpress.

Я сомневаюсь, что мой код так же безопасен, как Wordpress, но думаю, что смогу его заблокировать, а тот факт, что у него анонимный интерфейс, может сделать его менее привлекательной целью.

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

Так что мне просто интересно, учитывая мое окружение и мои ограничения, является ли это по-прежнему плохой идеей.И если да, то каковы основные причины.

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

Спасибо вам всем

Answer 1

Вы ссылаетесь на опыт работы с WP, возвращающимся дальше, чем у меня ... но я не рассматриваю эти проблемы как эту основную. О каком шкале сайтов мы говорим?

Это довольно медленно

Я чувствую, что это слишком много обобщения. Медленно можно помещать в контекст конкретного оборудования, задач и уровня трафика. В противном случае это общее заявление.

Часто это слишком сложно для потребностей простого веб -сайта

Комплекс для кого? Пользователи? Разработчик? WP тривиально установить и работать. Создайте немного контента, и у вас есть этот простой сайт. Где здесь сложность?

У него много проблем с безопасностью (особенно при использовании плагинов)

Опять же, слишком много общего заявления. Сам WP является относительно безопасным, и большинство проблем безопасности, которые оказали значительное влияние, представляется, связаны с чрезвычайно устаревшими версиями WP.

Состояние плагинов и безопасности определенно далеки от идеального, но ничто не мешает быть очень выборочным или развивать безопасные и надежные плагины, верно?

Трудно оптимизировать время загрузки страниц

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

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

У меня есть только один вопрос для вас - Вы абсолютно уверены, что делаете это лучше, быстрее и безопаснее, чем нативно-фронт-энд WP?

Я не спрашиваю об этом саркастически, я думаю, что это может быть правдоподобно, что для очень узкой задачи, сделанной на заказ и заблокированных передней части, может быть разумным. Но я также замечаю, что чрезмерная уверенность в том, что пользовательское решение является «просто лучше», чем коллективная работа многих разработчиков/компаний, не редкость в веб -разработке.

Обновлять

Мое первоначальное желание создать пользовательский фронт-энд произошло от наблюдения. Сайты WordPress, которые я строил, были не так быстрыми, как я хотел, чтобы они были (3-5 секунд, иногда дольше). [...] Они, безусловно, были развернуты на перепроданном общем хостинге, но они получили хорошие результаты YSLOW.

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

Вы должны использовать такие инструменты, но вы никогда не должны ограничивать свое понимание того, как сайт работает в одиночку.

На хостинге - любой динамический сайт на общем хостинге будет задыхаться под высокой нагрузкой. Опять же, хотя может показаться легко настроить и получить высокие баллы на переднем крае, на общем хостинге на стороне сервера критически не хватает гибкости аппаратного и веб -стека, необходимый Для сайта с высоким трафиком и/или стремлением к быстрой загрузке.

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

Вы пробовали статическое кэширование страницы? Это эффективно удаляет WP Core из большинства запросов, и это примерно настолько быстро, как вы можете получить на общем хостинге. Если вы пытались и не удовлетворены страницами, обслуживаемыми из статического кеша, WordPress не ваша проблема - хостинг.

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

В стабильной версии WordPress нет публичных и известных уязвимостей безопасности. Те, которые возникают, фиксируются в срок часа.

Плохая конфигурация сервера (общее происшествие на дешевых хостах) или запуск устаревшей версии WP - это то, что вас взломает, а не просто факт использования WP.

Что я имел в виду под сложности оптимизации нагрузки страниц, так это то, что если кто-то достигает интерактивной функции с помощью множества плагинов, многие сценарии загружаются, и становится более утомительным возвращаться и комбинировать, модифицировать, настраивать или оптимизировать их. Мне легче включить плагины jQuery за пределами WordPress, и мне не нужно иметь дело с тем, как они зацепляются в WP_head.

Да, некоторые плагины понятия не имеют, как правильно загрузить сценарии. Это действительно аргументы для тщательного выбора плагинов, а не против WordPress Core.

Согласование и оптимизация сценариев тривиально с хорошим плагином кэширования.

В целом, и после ваших обновлений я чувствую, что вы слишком стремитесь отказаться от WordPress для проблем, присущих любым сложным и полнофункциональным CMS (вам нужен приличный хостинг, чтобы сделать его резким), и вы не потратили много времени на кэширование решений Анкет

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

Answer 2

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

1. Это довольно медленно Вам необходимо предоставить более подробную информацию, сайт с сотнями тысяч страниц и 1 миллион просмотров в месяц не то же самое, что обычный блог/портфель. Это довольно просто и очень распространено иметь загрузку сайта WordPress за 2 секунды в зависимости от хостинга/плагинов/носителя/оптимизации. Это не конкретная проблема WordPress, если у вас нет очень большого сайта. Ваше понимание скорости страницы кажется плохим, оптимизация веб -сайтов намного больше, чем YSLOW ....

Например, у меня есть динамический сайт с достаточным количеством изображений, виджетов, 5 удаленного элемента канала RSS и 10 постов, начальная нагрузка составляет 2,9 секунды без кэша, перезагружена с кэшем, это 1,02 секунды. Я могу сказать, что это нормально для всех моих сайтов WordPress. (Большая часть начальной нагрузки на 2,9 секунды - это изображения, которые кэш явно использует при перезагрузке.)

2. Часто это слишком сложно для потребностей простого веб -сайтаWordPress, без сомнения, один из самых простых CMS, который сохраняет некоторые довольно продвинутые функции. Если вы не используете эти функции, то почему вы используете WordPress для начала? Если вы находите это сложным, что вы сравниваете это, .net, Static HTML, Nodejs?

3. У него много проблем с безопасностью (особенно при использовании плагинов)Оно делает? Сам WordPress безопасен, особенно в прошлом году+, не было никаких серьезных проблем. Большинство проблем безопасности WordPress происходят из -за чистого невежества со стороны пользователей, загружающих темы вредоносных программ, плохо написанные плагины, не обновлять их сайт и плохой хостинг. Безусловно, подавляющее большинство проблем безопасности вообще не связаны с ядром WordPress. Я могу предоставить очень конкретные примеры, если это необходимо.

4. Трудно оптимизировать время загрузки страницЯ действительно не думаю, что это точно, есть несколько отличных плагинов, которые делают оптимизацию WordPress на бриз по сравнению с ручным выполнением всего (что раньше было нормой). Эти плагины буквально экономят дни работы, оптимально кэшируя, мини -минимуму, используя CDN и т. Д. И т. Д., Буквально нажимая кнопку, как вам это трудно? Есть ли у вас какие -либо конкретные данные, на которые мы можем посмотреть?

Answer 3

Мартин:Прочитав этот вопрос и сопровождающие его ответы, вот мои два цента на ваш вопрос:

Плюсы использования пользовательского интерфейса по сравнению сWordPress

• Потенциально более быстрая загрузка, поскольку вы можете уменьшить количество скриптов и т. д.которые загружены (но см. ниже)
• Больше контроля над запросами к базе данных, что потенциально может привести к ускорению загрузки страниц.

Минусы использования пользовательского интерфейса по сравнению сWordPress

Скорость: Одна из ваших проблем с WP — скорость.По моему опыту, если вы не используете плагины, которые вставляют в заголовок собственный JS (через wp_head()), WordPress загружает только то, что вы ему скажете.

Пропуск wp_head() из вашего шаблона заголовка, например, не позволит WP загрузить новую панель администратора.

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

Сложность: Ваше беспокойство по поводу сложности, похоже, направлено на серверную часть, а не на интерфейсную часть.Хотя я считаю, что у WP отличный пользовательский интерфейс, я понимаю желание адаптировать его функциональность для конкретных проектов.Во многих случаях вы можете изменить файл function.php и указать WordPress, что отображать (см. этот пост некоторые примеры).

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

Безопасность: Я не совсем согласен с утверждением, что запуск пользовательского интерфейса более безопасен.Если вы используете серверную часть WP, хакер может легко обнаружить этот факт, просмотрев ваши URL-пути (включая /wp-content/ и т. д.).

Существует множество плагинов, которые удаляют мета-данные, «сгенерированные» из внешнего интерфейса, и делают множество других вещей для повышения безопасности (Безопасный WordPress хороший пример).Я действительно верю, что это меньше безопасно полагаться на собственное индивидуальное решение.Это не комментарий к вашим навыкам кодирования, но... мне кажется, что целая команда разработчиков, зарабатывающая на жизнь ничем, кроме WordPress, была бы надежнее, чем один парень.

Вы действительно поднимаете хороший вопрос в том, что WP как бы нацелен на хакерское яблочко.Однако... Меня взломали только на устаревших версиях WP и на виртуальном хостинге, где виноват хост.С 3.0 проблем не было.Я думаю, если вы будете следить за своей установкой, проверять, что используемые вами плагины безопасны и поддерживаются, а также руководствоваться здравым смыслом, у вас не возникнет никаких проблем с безопасностью.

Время загрузки страницы: Я полностью с вами согласен, что использование нескольких плагинов (или отдельных плагинов) может отрицательно повлиять на время загрузки страницы.Однако это больше возлагает вину на плагины и решение разработчика их использовать, чем на WP, не так ли?Вы можете использовать простой jQuery со своим пользовательским интерфейсом или без него, поэтому я не вижу преимуществ в использовании пользовательского интерфейса, когда разумно разработанная тема WP подойдет так же хорошо.

Портативность: Больше всего меня беспокоит использование пользовательского внешнего интерфейса в том, что он не настолько портативен и перспективен, как те, которые поддерживаются сообществом.Моя компания никогда создает специальные CMS для клиентов, потому что к нам приходили многие люди и говорили: «Наш старый веб-мастер создал эту специальную штуку, и теперь он в Греции, и я не могу найти никого, кто мог бы ее обновить».

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

Последние мысли

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

Для меня минусы такого подхода перевешивают плюсы.

Answer 4

Я действительно не знаю, использовали ли вы WordPress, основываясь на том, что вы опубликовали? Мы будем использовать мой сайт в качестве примера. Он получает оценку YSLOW 90% и загружается в 1,5S квартиры для нового пользователя. Если они кэшируют в своем браузере, это мгновенно .. Я даже не использую статические страницы.

Сейчас я на специальном сервере ... поэтому мне не нужно иметь дело с общим хостингом, и я могу оптимизировать свой сервер (GZIP и т. Д.)

Я предполагаю, что вы использовали Shared Hosting Server, который продается на 120%. Затем он доходит до ползания.

Что -нибудь на заказ будет иметь гораздо больше уязвимостей безопасности, чем что -то вроде WordPress, которое будет стучать каждый день. За исключением того, что они, скорее всего, даже не будут беспокоиться, потому что кто заботится о взломе одного сайта с помощью пользовательского кода?

ОБНОВИТЬ:

Я немного больше понимаю, откуда ты. Однако многое из того, что делает WordPress "медленный" плохо закодированные темы или нептимизированные серверы. Если у вашего хостинга есть настройка серверов с базовой установкой Apache/PHP/MySQL, скорее всего, он не оптимизирован для запуска WordPress. Есть настройки для php.ini/httpd.conf/mysql, которые запускают его быстрее с помощью базы данных. сайт.

Это, однако, проблема «сервера», а не WordPress. У меня есть сайт, который находится на моем выделенном сервере (MAC Mini Server, 2.66 C2D, 4GB), который загружается в 1,5 секунды, а тот же сайт загружается в 4SEC на INMOTION, который является одним из лучших/лучших поставщиков хостинга.

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