¿Cuáles son los pros y los contras de usar un front-end personalizado para recuperar contenido de un back-end de WordPress?

Question

He estado construyendo sitios de WordPress durante algunos años y he notado algunas cosas que me molestan.

1. Es bastante lento (Declaración general horrible, me disculpo)

Mi deseo inicial de crear un front-end personalizado provino de una observación. Los sitios de WordPress que estaba construyendo no eran tan rápido como quería que fueran (3-5 segundos, a veces más largos).

@Kenrik: ciertamente se desplegaron en alojamiento compartido de sobreventa, pero obtuvieron buenos puntajes YSLOW. Lo probé y encontré que los sitios eran aproximadamente tres veces más rápido cuando no cargué la sobrecarga de WP. La misma máquina, la misma puntuación YSLOW, 3 veces más rápido. No soy un experto en el uso de la CPU de WordPress, pero he leído que es bastante intenso, por lo que no me sorprendió las ganancias de velocidad que logré.

2. A menudo es demasiado complejo para las necesidades de un sitio web simple

Solo una nota: estoy construyendo principalmente sitios para líneas de moda y gestión de cartera, complejo en la interacción frontal, pero con relativamente pocos datos. Estos sitios nunca serán enormes y requieren muy poco código para recuperar el contenido necesario. Por lo tanto, mi pregunta es en gran medida teórica.

Creo que WordPress es una plataforma fantástica y que tiene pocos límites para el crecimiento, sin embargo, creo que cargar todos sus recursos es exagerado para muchos proyectos más pequeños, destinado a ser atendido por el alojamiento compartido.

3. Tiene muchos problemas de seguridad (especialmente cuando se usa complementos)

Con respecto a la seguridad, puedo ver cómo mi pregunta fue ambigua y contradictoria. Lo que quise decir es que, a partir de mi entendimiento, un sitio de WordPress, más allá de cualquier agujero de seguridad real, es vulnerable porque los atacantes saben que es un sitio de WordPress. Esto crea un desafío (para violar una plataforma popular) y una hoja de trucos inherente (las vulnerabilidades de WordPress están bien documentadas). Entonces, seguro que una solución personalizada podría tener más agujeros de seguridad reales, pero me pregunto si esto no se vería equilibrado por el hecho de que hace que el funcionamiento interno sea anónimo. Como dijo @kenrik, "probablemente ni siquiera se molesten porque a quién le importa piratear un solo sitio con código personalizado dudoso?"

4. Es difícil optimizar los tiempos de carga de la página

Lo que quise decir con la dificultad de la optimización de la carga de la página es que si se logra una funcionalidad interactiva a través de muchos complementos, se cargan muchos scripts y se vuelve más tedioso regresar y combinar, modificarlos, personalizarlos u optimizarlos. Me resulta más fácil incluir complementos jQuery fuera de WordPress y no tener que lidiar con cómo se conectan a WP_head.

Así que recientemente decidí hacer mi desarrollo de manera diferente y usar WordPress como solo una herramienta de back-end. Utilizo el espacio de administración para actualizar el contenido y llenar la base de datos, pero utilizo una capa de acceso de datos personalizado y funciones personalizadas en el front-end para recuperar y mostrar el contenido. Para las páginas donde se necesita inicio de sesión, incluyo el archivo de cabeza de blog y uso las funcionalidades de administración de credenciales de WordPress.

Como lo veo, los profesionales de esta solución frontal independiente son que facilita el desarrollo (solo escribe lo que necesita, y es todo su propio trabajo), es más fácil optimizar las cargas de página (tiene un mejor control sobre lo que Se utilizan scripts y cómo combinarlos de manera óptima), no está alertando a todo el mundo de piratería sobre la existencia de una instalación de WordPress (porque los archivos ya no se cargan desde un tema) y más.

Contras potenciales: seguridad, falta de escalabilidad, falta de soporte de desarrolladores para soluciones personalizadas ... ¿algo más?

Realmente disfruto crear sitios fuera de las limitaciones de WordPress, solo me preocupa que pueda pasar por alto algunos problemas importantes con este enfoque.

Avíseme si este es el caso.

Salud

Para concluir retroactivamente:

Estoy 100% seguro de que mis sitios son más rápidos en el mismo entorno cuando no uso el front-end nativo de WordPress.

Dudo que mi código sea tan seguro como WordPress, pero creo que puedo bloquearlo y el hecho de que tiene un front-end anónimo podría convertirlo en un objetivo menos.

Estoy seguro de que puedo codificar las funcionalidades mucho más rápido cuando implemento una solución frontal personalizada extremadamente simple.

Así que me pregunto, dada mi entorno y mis limitaciones si hacer esto todavía es una mala idea. Y si es así, cuáles son las principales razones.

Estoy seguro de que hay otros codificadores curiosos, ambiciosos y subeducados que podrían estar preguntándose lo mismo. Es probable que se beneficien de lo que tenga que decir sobre el tema.

Gracias a todos

Answer 1

Haces una experiencia con WP que regresa más lejos que la mía ... sin embargo, no veo estos problemas como esa especialidad. ¿De qué escala de sitios estamos hablando?

Es bastante lento

Siento que esto es demasiado generalización. Se puede poner lento en el contexto de hardware, tareas y niveles de tráfico específicos. Es una declaración general de lo contrario.

A menudo es demasiado complejo para las necesidades de un sitio web simple

Complejo para quién? Usuarios? ¿Desarrollador? WP es trivial para instalar y ejecutar. Cree un poco de contenido y tendrá ese sitio simple. ¿Dónde está la complejidad aquí?

Tiene muchos problemas de seguridad (especialmente cuando se usa complementos)

De nuevo, mide demasiado la declaración general. WP en sí es relativamente seguro y la mayoría de los problemas de seguridad que tuvieron un impacto importante parecen ser de ejecutar versiones WP muy desactualizadas.

El estado de complementos y seguridad definitivamente está lejos de ser perfecto, pero nada evita que sea muy selectivo o desarrolle complementos seguros y confiables, ¿verdad?

Es difícil optimizar los tiempos de carga de la página

Nuevamente, no estoy seguro de de qué escala estamos hablando. La optimización de sitios de tamaño bajo a medio parece trivial: instale un buen complemento de caché estático, pulir con caché de codo de opto ... Agregue un servidor web alternativo o un proxy inverso si realmente es necesario.

Realmente disfruto crear sitios fuera de las limitaciones de WordPress, solo me preocupa que pueda pasar por alto algunos problemas importantes con este enfoque.

Prácticamente solo tengo una pregunta para ti - ¿Estás absolutamente seguro de que lo estás haciendo mejor, más rápido y más seguro que el front-end nativo de WP?

No pregunto esto sarcásticamente, creo que podría ser plausible que para tareas muy estrechas hechas a medida y bloqueada en el front-end pueda ser razonable. Pero también noto que el exceso de confianza sobre la solución personalizada es "simplemente mejor" que el trabajo colectivo de muchos desarrolladores/empresas no es infrecuente en el desarrollo web.

Actualizar

Mi deseo inicial de crear un front-end personalizado provino de una observación. Los sitios de WordPress que estaba construyendo no eran tan rápido como quería que fueran (3-5 segundos, a veces más largos). [...] Ciertamente se desplegaron en alojamiento compartido de sobreventa, pero obtuvieron buenos puntajes YSLOW.

Yslow (y PageSpeed) son excelentes herramientas, pero son inherentemente limitadas. Solo pueden analizar y asesorar sobre el rendimiento frontal y cómo el sitio procesa el sitio. No dan información en el rendimiento de su servidor y persigue ciegamente los puntajes delanteros altos en realidad pueden ser perjudiciales para la carga del servidor.

Debe usar tales herramientas, pero nunca debe limitar su visión en cómo se desempeña solo el sitio.

En el alojamiento: cualquier sitio dinámico en el alojamiento compartido se ahogará bajo alta carga. Una vez más, si bien puede parecer fácil de ajustar y obtener puntajes altos altos en el lado del servidor, alojamiento compartido críticamente carece de hardware y flexibilidad de pila web, necesario para el sitio con alto tráfico y/o luchar por tiempos de carga rápidos.

Creo que cargar todos sus recursos es exagerado para muchos proyectos más pequeños, destinado a ser atendido por el alojamiento compartido.

¿Había probado el almacenamiento en caché de la página estática? Elimina efectivamente WP Core de la mayoría de las solicitudes y es lo más rápido que puede obtener en el alojamiento compartido. Si lo intentó y no está satisfecho con las páginas, servidas de caché estático, WordPress no es su problema, el alojamiento lo es.

Lo que quise decir es que, a partir de mi entendimiento, un sitio de WordPress, más allá de cualquier agujero de seguridad real, es vulnerable porque los atacantes saben que es un sitio de WordPress. Esto crea un desafío (para violar una plataforma popular) y una hoja de trucos inherente (las vulnerabilidades de WordPress están bien documentadas).

No hay vulnerabilidades de seguridad públicas y conocidas en la versión estable de WordPress. Los que surgen están fijos en cuestión de horas.

La mala configuración del servidor (ocurrencia común en hosts baratos) o ejecutar la versión WP obsoleta es lo que te hace piratear, no el hecho de usar WP.

Lo que quise decir con la dificultad de la optimización de la carga de la página es que si se logra una funcionalidad interactiva a través de muchos complementos, se cargan muchos scripts y se vuelve más tedioso regresar y combinar, modificarlos, personalizarlos u optimizarlos. Me resulta más fácil incluir complementos jQuery fuera de WordPress y no tener que lidiar con cómo se conectan a WP_head.

Sí, algunos complementos no tienen idea de cómo cargar correctamente los scripts. Eso es realmente argumentos para elegir complementos con cuidado, no contra WordPress Core.

La concatenación y optimización de scripts es trivial con un buen complemento de almacenamiento en caché.

En general, y después de sus actualizaciones, siento que está demasiado ansioso por descartar WordPress para problemas inherentes a cualquier CMS complejo y totalmente realizado (necesita un alojamiento decente para que Snappy) no haya pasado mucho tiempo buscando en caché de soluciones de almacenamiento en caché .

Es posible que no sea un buen ajuste para el tipo de sitios que construye y es mejor que busque CMS más ligeros, más simples y menos funcionales que funcionarán mejor bajo sus limitaciones de alojamiento.

Answer 2

Para agregar a lo que dijo Rarst, pero creo que esta publicación es el trolling de la línea fronteriza.

1. Es bastante lento Debe proporcionar más detalles, un sitio con cientos de miles de páginas y 1 millón de visitas al mes no es lo mismo que un blog/cartera regular. Es bastante simple y muy común tener una carga de sitio de WordPress en menos de 2 segundos dependiendo de alojamiento/complementos/medios/optimización. Este no es realmente un problema específico de WordPress a menos que tenga un sitio muy grande. Su comprensión de la velocidad de la página parece ser pobre, la optimización del sitio web es mucho más que YSLOW ...

Por ejemplo, tengo un sitio dinámico con una buena cantidad de imágenes, widgets, 5 elementos de alimentación RSS remoto y 10 publicaciones, la carga inicial es de 2.9 segundos sin caché, recargada con caché es 1.02 segundos. Puedo decir que esto es normal para todos mis sitios de WordPress. (La mayoría de la carga inicial de 2.9 segundos son imágenes que el caché claramente utiliza en la recarga).

2. A menudo es demasiado complejo para las necesidades de un sitio web simpleWordPress es sin duda uno de los CMS más fáciles que mantiene algunas características bastante avanzadas. Si no aprovecha esas características, ¿por qué está usando WordPress para empezar? Si lo encuentra complejo, ¿con qué está comparando esto con .NET, HTML estático, nodejs?

3. Tiene muchos problemas de seguridad (especialmente cuando se usa complementos)¿Lo hace? WordPress en sí es seguro, especialmente en el último año+, no ha habido problemas importantes. La mayoría de los problemas de seguridad de WordPress provienen de la ignorancia pura por parte de los usuarios que descargan temas de malware, complementos mal escritos, no actualizando su sitio y un mal alojamiento. Con mucho, la gran mayoría de los problemas de seguridad no están relacionados con el núcleo de WordPress en absoluto. Puedo proporcionar ejemplos muy específicos si es necesario.

4. Es difícil optimizar los tiempos de carga de la páginaRealmente no creo que sea preciso, hay un puñado de excelentes complementos que hacen que la optimización de WordPress sea muy fácil en comparación con hacer todo manualmente (que solía ser la norma). Estos complementos literalmente guardan días de trabajo al almacenar en caché de manera óptima, minificando, usando CDN, etc., etc., con literalmente el clic de un botón, ¿cómo lo resulta difícil? ¿Tiene algún datos específicos reales que podamos ver?

Answer 3

Martin: Después de leer esta pregunta y sus respuestas adjuntas, aquí están mis dos centavos en su pregunta:

Pros de uso de un front-end personalizado vs. WordPress

• Tiempos de carga potencialmente más rápidos, ya que puede reducir la cantidad de scripts, etc. que están cargados (pero ver más abajo)
• Más control sobre consultas de bases de datos, lo que podría dar lugar a tiempos de carga de página más rápidos.

Contras de usar una parte delantera personalizada vs. WordPress

Velocidad: Una de sus preocupaciones con WP es la velocidad. En mi experiencia, a menos que use complementos que insertan sus propios JS en el encabezado (a través de wp_head()), WordPress solo carga lo que le dice.

Omitir wp_head() De su plantilla de encabezado evitará que WP cargue la nueva barra de administración, por ejemplo.

Lo que esto significa es que no hay necesariamente ninguna ventaja para usar su propio front-end, ya que puede personalizar qué cargas en su encabezado de todos modos.

Complejidad: Su preocupación por la complejidad parece dirigida al back-end, no al front-end. Si bien creo que WP tiene una gran interfaz de usuario, puedo entender querer adaptar su funcionalidad para proyectos específicos. En muchos casos, puede modificar su archivo Functions.php y decirle a WordPress qué mostrar (Ver esta publicación para algunos ejemplos).

Entonces, si el back-end es demasiado complejo, supongo que siempre puedes construir el tuyo. Si se refiere a la complejidad de las consultas de la base de datos de WP o el uso de recursos, diferiré a alguien con más conocimiento sobre cómo funciona esas cosas.

Seguridad: Realmente no compro el argumento de que ejecutar un front-end personalizado es más seguro. Si se está ejecutando en un back-end de WP, un hacker podría descubrir fácilmente ese hecho mirando sus rutas de URL (que incluyen /WP-Content /, etc.).

Hay complementos en abundancia que eliminan el meta "generado por" del front-end y hacen todo tipo de cosas para mejorar la seguridad (Asegurar WordPress es un buen ejemplo). De hecho creo que es menos Asegúrese para confiar en una solución personalizada de cosecha propia. Este no es un comentario sobre sus habilidades de codificación, pero ... me parece que todo un equipo de desarrolladores se ganó la vida sin hacer nada más que WordPress sería más confiable que un tipo.

Usted plantea un buen punto en ese tipo de WP tiene una diana de hacker. Sin embargo ... solo he sido pirateado en versiones WP obsoletas y en el alojamiento compartido donde el anfitrión tuvo la culpa. Desde 3.0, no ha habido problemas. Creo que si se mantiene actualizado en su instalación, verifique que los complementos que use son seguros y compatibles, y use el sentido común, no tendrá ningún problema de seguridad.

Tiempos de carga de la página: Estoy completamente de acuerdo con usted en que usar un montón de complementos (o ciertos complementos) puede afectar negativamente los tiempos de carga de la página. Sin embargo, esto impone más la culpa de los complementos y la elección del desarrollador de usarlos que en WP, ¿no? Puede usar jQuery recta con o sin su front-end personalizado, por lo que no veo la ventaja de ir a la personalización aquí cuando un tema WP diseñado de manera inteligente funcionará igual de bien.

Portabilidad: Mi mayor preocupación por el uso de un front-end personalizado es que no es tan portátil o futura prueba como las que apoyan la comunidad. Mi empresa nunca Construye CMSS personalizados para clientes, porque hemos tenido muchas personas que vengan a nosotros y le dicen: "Nuestro viejo tipo web construyó esta cosa personalizada, y ahora está en Grecia, y no puedo encontrar a nadie que lo actualice".

WordPress utiliza funciones estándar que están bien documentadas y que cualquier desarrollador de WP experimentado lo sabrá. Con una plataforma grande, robusta y próspera como WordPress, un cliente puede encontrar muy fácilmente otro desarrollador para hacerse cargo del mantenimiento si el viejo desaparece.

Pensamientos finales

Dicho todo lo anterior, creo que hiciste una buena pregunta que plantea algunas preocupaciones válidas. Puedo ver la implementación de un front-end personalizado para un proyecto interno tuyo, pero eso es solo si Crees que vale la pena el tiempo de desarrollo adicional.

Para mí, los contras de este enfoque superan a los profesionales.

Answer 4

Realmente no sé si has usado mucho WordPress en función de lo que publicaste. Usaremos mi sitio como ejemplo. Obtiene una puntuación YSLOW del 90% y se carga en 1,5S para un nuevo usuario. Si lo tienen en caché en su navegador es instantáneo. Ni siquiera uso páginas estáticas.

Ahora estoy en un servidor dedicado ... así que no tengo que lidiar con el alojamiento compartido y puedo optimizar mi servidor (GZIP, etc.)

Mi mejor suposición es que has estado usando un servidor de alojamiento compartido que se vende al 120% ... entonces se trata de un rastreo.

Cualquier cosa personalizada tendrá muchas más vulnerabilidades de seguridad que algo como WordPress que se golpean todos los días. Excepto que lo más probable es que ni siquiera se molesten porque se preocupa por piratear un solo sitio con código personalizado dudoso?

ACTUALIZAR:

Entiendo un poco más de dónde vienes. Sin embargo, gran parte de lo que hace que WordPress "lento" son temas mal codificados o servidores no optimizados. Si su proveedor de alojamiento tiene la configuración de servidores con solo una instalación básica de Apache/Php/MySQL, lo más probable es que no esté optimizado para ejecutar WordPress. Hay ajustes a php.ini/httpd.conf/mysql que lo hace funcionar más rápido con una base de datos impulsada sitio.

Sin embargo, este es un problema de "servidor", no de WordPress. Tengo un sitio que está en mi servidor dedicado (Mac Mini Server, 2.66 C2D, 4GB) que se carga en 1.5 segundos y el mismo sitio se carga en 4 segundos en InMotion, que es uno de los mejores/mejores proveedores de alojamiento compartido.

Ahora mi "pequeño servidor" de ninguna manera es poderoso y, sin embargo, patea los pantalones de cualquier alojamiento compartido. La optimización del servidor es tan importante en la velocidad total del sitio web como la optimización del sitio.