Última verificación: 30 de septiembre de 2026
Reconstruí kevinyoung.net como un sitio estático con SvelteKit y SveltePress en lugar de WordPress, la herramienta que uso en la mayoría del trabajo para clientes. Quería menos piezas móviles, control sobre cada línea que recibe el navegador y un marcador público con el que exigirme. Frente a una lista de calidad web de 172 temas, el sitio obtiene 92 por ciento en su propia auditoría, fallos incluidos. WordPress sigue siendo la herramienta correcta para la mayoría de los sitios de negocios, y RdyToGo sigue construyéndolos. Este es un proyecto personal: lo que elegí, lo que dicen las fuentes y dónde empieza mi opinión.
¿Cómo termina un diseñador web con un sitio desactualizado?
De la misma forma en que un mecánico termina con un auto ruidoso. Construí sitios para clientes durante años mientras el mío seguía congelado en 2023, con una página Acerca de que describía un negocio que ya no era así.
Me molestaba más de lo que admitía. Mi primer sitio web fue el que un compañero y yo construimos en la preparatoria, alrededor de 1997. Aprendimos HTML por nuestra cuenta en el Bloc de notas, y nuestro profesor de computación convirtió ese nuevo pasatiempo en un proyecto de clase: todo el grupo construyó el primer sitio web de la escuela. Cada página era un archivo simple en un servidor. Nada que actualizar, nada que parchar. Simplemente cargaba.
Veintinueve años después, lo más moderno que pude construir para mí resultó ser, otra vez, archivos simples. Con mucho más cuidado por dentro.
¿Con qué lista lo medí?
Usé specification.website, una lista gratuita y abierta de lo que hace un buen sitio web. Cubre 172 temas en diez categorías: Fundamentos (20), SEO (14), Accesibilidad (30), Seguridad (20), URI conocidas (13), Preparación para agentes (21), Rendimiento (26), Privacidad (7), Resiliencia (8) e Internacionalización (13). Cada tema enlaza con el estándar que lo respalda, desde el W3C hasta las WCAG, y el sitio afirma que la especificación aplica ya sea que uses WordPress, Next.js o HTML simple.
Una pequeña ironía me hizo sonreír. La lista fue escrita por Joost de Valk, fundador de Yoast SEO, uno de los plugins de WordPress más conocidos. Así que la regla con la que medí mi sitio sin WordPress vino de alguien del propio mundo de WordPress. A los buenos estándares no les importa con qué construyas.
Le pedí a Claude que auditara el sitio en vivo contra cada punto, y publiqué los resultados, errores incluidos. Al momento de escribir esto: 92.0 por ciento, 268.5 de 292 puntos aplicables. SEO obtuvo 27 de 27. Accesibilidad obtuvo 60 de 63. Seguridad es la categoría más débil, con 80 por ciento. La puntuación era más baja cuando empecé a escribir este artículo, porque seguí corrigiendo cosas.
Es una autoevaluación hecha por una IA, no una certificación, y no he vuelto a revisar cada fila a mano. La página de la auditoría lo dice al principio.
¿Por qué no construirlo simplemente en WordPress?
Porque WordPress es la herramienta correcta para otro tipo de trabajo. Según W3Techs, funciona en cerca del 40 por ciento de todos los sitios web y en casi el 60 por ciento de los sitios con un CMS conocido. Es de código abierto, su directorio de plugins cubre casi cualquier cosa y las personas sin conocimientos técnicos pueden editarlo. Soy coorganizador del Myrtle Beach WordPress Meetup, y RdyToGo construye sitios WordPress cada semana. Este no es un artículo de ruptura.
Eso sí, WordPress trae consigo un trabajo de mantenimiento. En septiembre de 2026, la versión 7.1.1 salió el día 17 con un lote de correcciones de seguridad. La versión 7.1.2 llegó el día 22 para cerrar una falla crítica, calificada con 9.2 sobre 10, que podía permitir a un atacante sin sesión iniciada ejecutar código en algunos servidores. Ambas venían con el mismo consejo: actualiza de inmediato.
Las actualizaciones de seguridad del núcleo suelen instalarse solas. En los temas y plugins todavía hay que hacer clic, probar y, a veces, arreglar lo que rompió una actualización. Eso no es un escándalo. Es el costo de ser el software en el que funciona el 40 por ciento de la web, porque los atacantes apuntan donde está la multitud. Pasé años en esa rueda para mis clientes, y por eso creé Firebolt, que convierte un sitio WordPress en una copia estática ya construida.
¿Podría haber cumplido la lista con WordPress? Probablemente, con suficientes plugins o suficiente código personalizado que trabajara contra los supuestos de la plataforma. Para mi propio sitio, quería menos piezas móviles.
¿Con qué lo construí?
Siete herramientas, cada una elegida para una tarea, servidas mediante Netlify y Cloudflare. No escribí cada línea yo mismo. Construí el sitio conversando con Claude y Claude Code, las herramientas de programación con IA de Anthropic. Yo decidí qué construir, revisé los resultados y pedí cambios hasta que quedaron bien. Mi página de política de IA explica quién hizo qué.
Node es el motor sobre el que corre todo. Es una cosa más que mantener actualizada, pero silenciosa.
pnpm instala las piezas con las que se construye el sitio. En lugar de copiar cada paquete en cada proyecto como hace npm, guarda una sola copia en el disco y enlaza a ella. Además, no ejecuta los scripts de instalación de un paquete nuevo hasta que yo los apruebo, lo que bloquea un truco favorito de los ataques a la cadena de suministro. La página de pruebas de pnpm muestra que supera a npm en los seis escenarios; una instalación limpia de su proyecto de prueba "alotta-files" tomó 4.42 segundos frente a 48.4 de npm. Es el laboratorio de pnpm, en una sola máquina. Quédate con la dirección, no con los decimales.
TypeScript es el corrector ortográfico del código. Señala errores mientras escribo, antes de que algo se ejecute. El costo es una curva de aprendizaje y una compilación más estricta, y solo detecta los errores que un sistema de tipos sabe describir.
Svelte construye lo que la gente ve y toca. Hace su trabajo cuando se compila el sitio y convierte los componentes en archivos JavaScript pequeños, mientras que React hace más de su trabajo en el navegador del visitante. Más sobre la velocidad abajo.
SvelteKit es el framework que rodea a Svelte, y lo elegí por lo en serio que se toma los sitios estáticos. De forma predeterminada, su adaptador estático hace fallar la compilación si alguna página no se prerrenderizó, así que no puedo publicar un sitio a medias estático por accidente. Una sola opción precomprime cada archivo con Brotli y gzip. Su documentación incluso advierte que el modo de aplicación de una sola página perjudica el rendimiento y el SEO.
SveltePress convierte Markdown en páginas. De fábrica ofrece búsqueda y un archivo llms.txt para herramientas de IA, pero omití sus temas y construí uno propio, para que cada página se vea y se comporte como yo quería. La contrapartida es la comunidad. WordPress tiene un meetup en mi ciudad; yo ayudo a organizarlo. SveltePress tiene un repositorio de GitHub. Cuando algo se rompe a las 11 de la noche, esa diferencia importa.
UnoCSS escribe los estilos. Genera solo los estilos que realmente uso y me deja definir mis propias reglas de diseño en lugar de adoptar las de otra persona. No afirmo que produzca archivos más pequeños que Tailwind. Afirmo que se ajusta mejor a mi forma de trabajar.
Netlify y Cloudflare sirven el sitio. HTTPS, encabezados de seguridad y protecciones de DNS viven ahí, no en el framework. Un sitio estático deja gran parte de su seguridad en manos de su proveedor, así que elígelo con cuidado.
¿Es Svelte realmente más rápido que React?
En la única prueba pública en la que confío, sí. En la ejecución con Chrome 152 del js-framework-benchmark, Svelte 5 obtuvo 1.17 y React 19 (hooks) obtuvo 1.58 en el promedio de CPU con claves, donde menos es mejor. Según mi aritmética, la cifra de React es cerca de 35 por ciento mayor.
Esa prueba mide componentes que actualizan una tabla grande en una sola máquina. No dice nada sobre sitios web completos, ni sobre SvelteKit frente a Next.js. Y, siendo honesto, en un sitio personal que es sobre todo texto, los visitantes nunca notarán esa diferencia. Lo que notan es cuánto les envía una página, y una página prerrenderizada envía muy poco.
¿Y Next.js?
No encontré ninguna prueba pública que compare SvelteKit con Next.js, así que no afirmo que uno sea más rápido. Ambos pueden construir un sitio totalmente estático.
Next.js enumera a qué renuncia su exportación estática: reescrituras, redirecciones, encabezados personalizados, regeneración incremental, optimización de imágenes predeterminada, modo borrador y más. Para ser justos, la salida estática de SvelteKit tampoco puede hacer esas cosas por sí sola. Mis redirecciones y encabezados viven en Netlify y Cloudflare. La diferencia que me importa son los valores predeterminados: SvelteKit se niega a publicar un sitio a medias estático a menos que yo se lo indique. Eso es una preferencia mía, no una medición.
¿Qué proyectos deberían seguir usando WordPress?
La mayoría. En 1999 di una clase de computación para adultos a través del departamento de Parques y Recreación de mi municipio. Mi alumna de mayor edad, una repostera de 82 años, levantó el ratón del escritorio la primera noche y lo apuntó hacia la pantalla. Unos meses después, dirigía su negocio desde una computadora. Su historia está aquí. Las personas como ella merecen un panel de control, un botón de vista previa y un botón grande de Publicar. Eso es WordPress.
Si tu personal edita contenido, si un equipo publica en conjunto o si necesitas comercio electrónico, reservas o membresías, usa WordPress. Lo mismo si quieres contratar ayuda con facilidad en cualquier ciudad.
La pila estática encaja en otro tipo de proyecto: un sitio personal, un sitio de marketing, documentación o un blog donde publica un desarrollador y el control de calidad es el objetivo. La mayoría de los clientes de RdyToGo pertenece al primer grupo, y está bien. El segundo grupo ahora tiene una opción que antes no estaba en nuestro menú. Elegir la herramienta adecuada para cada proyecto es todo el trabajo.
¿Qué hice mal en el camino?
Bastante, y la página de la auditoría guarda los recibos.
- Mi primer intento de favicon vectorial pesaba 827 KB, trazado a partir de una foto con 1,481 trazados. Un trazo más simple y algo de limpieza lo dejaron en 27 KB.
- Una prueba solo con teclado descubrió que el panel de ajustes de pantalla se abría, pero dejaba el foco atrás, así que al presionar Tab se lo saltaba. Corregido.
- Al desactivar JavaScript apareció una fila de botones muertos: menú, búsqueda, cambio de tema. Ahora permanecen ocultos hasta que se cargan los scripts, y una fila simple de enlaces reemplaza el menú.
- En un teléfono lento simulado, la imagen principal todavía tarda 4.6 segundos en aparecer. El límite de "bueno" de Google es 2.5 segundos. Ese sigue pendiente.
- Las páginas en español y portugués empezaron como traducciones automáticas. Amigos que hablan esos idiomas de forma nativa las están revisando.
Prefiero mostrarte esa lista antes que una puntuación perfecta.
¿Qué evidencia respalda estas afirmaciones?
Esta sección es para lectores que quieran comprobar mi trabajo. Abrí cada fuente a continuación el 30 de septiembre de 2026.
Svelte frente a React. js-framework-benchmark, resultados oficiales con Chrome 152. Implementaciones con claves, CPU, media geométrica ponderada de la lentitud respecto a la implementación más rápida. Svelte 5.42.1 obtuvo 1.17; React Hooks 19.2.0 obtuvo 1.58. El "cerca de 35 por ciento" es mi aritmética: (1.58 − 1.17) ÷ 1.17. La página no muestra fecha de ejecución, así que la cito por la versión de Chrome. Mide frameworks de interfaz, no SvelteKit frente a Next.js.
pnpm. Página de pruebas de pnpm, proyecto alotta-files, npm 12.1.0 frente a pnpm 12.7.0, la más rápida de tres ejecuciones, con una conexión emulada de 50 ms y 200 Mbps. Instalación limpia: 48.4 s frente a 4.42 s. Sin cambios: 1.24 s frente a 18 ms. Las ejecuta el propio proveedor en una sola máquina, se omiten tres de nueve escenarios y la página se regenera con cifras nuevas en cada despliegue.
WordPress. Uso: W3Techs, 21 de septiembre de 2026. Versiones: WordPress 7.1.1 (17 de septiembre) y 7.1.2 (22 de septiembre), que corrigió CVE-2026-87902.
La auditoría. kevinyoung.net/website-audit: 268.5 de 292 puntos aplicables, ponderados según el nivel de cada punto (3 puntos para Obligatorio, 2 para Recomendado, 1 para Opcional). Auditado por Claude, sin certificación independiente.
También revisé: la lista de specification.website, la documentación de adapter-static de SvelteKit, la documentación de exportaciones estáticas de Next.js y el README de SveltePress.
Preguntas frecuentes
¿Debería mover mi sitio WordPress a SveltePress?
Probablemente no. Si tu personal edita contenido, un equipo publica en conjunto o los plugins manejan tu tienda, reservas o membresías, WordPress es la mejor opción. Mudarse significa reconstruir cómo publica tu gente, no solo las páginas. Una pila estática conviene a sitios donde publica un desarrollador y el control de calidad importa más. RdyToGo construye ambos y te dirá cuál necesita tu proyecto.
¿Puede mi personal editar un sitio SveltePress sin un desarrollador?
No como editan WordPress. El contenido vive en archivos Markdown y los cambios se publican mediante un paso de compilación. No hay panel de control, ni botón de vista previa, ni plugins que instalar para una función nueva. Quien se sienta cómodo con un editor de texto puede aprenderlo en una tarde. Si tu equipo edita a diario y prefiere no ver código, elige WordPress.
¿Es Svelte más rápido que React?
En la ejecución con Chrome 152 del js-framework-benchmark, sí: Svelte 5 obtuvo 1.17 y React 19 obtuvo 1.58, donde menos es mejor. Eso es cerca de 35 por ciento de diferencia según mi aritmética. Mide qué tan rápido se actualizan los componentes en una sola máquina, no qué tan rápido cargan sitios web completos, y no compara SvelteKit con Next.js.
¿Esta pila cuesta menos de mantener?
Tiene menos cosas que pueden fallar. No hay rueda de actualizaciones de plugins, ni base de datos que parchar, y el resultado son archivos simples. Pero menos desarrolladores conocen Svelte que WordPress o React, así que encontrar ayuda es más difícil. El mantenimiento se abarata y la contratación se encarece. Presupuesta ambas cosas con los ojos abiertos.
¿Qué significa la puntuación de auditoría de 92 por ciento?
Significa que el sitio obtuvo 268.5 de 292 puntos posibles en la lista de specification.website, con más peso en los puntos obligatorios que en los opcionales. La auditoría la hizo Claude, no un auditor independiente, y publiqué cada resultado, incluidos los fallos. Cubre SEO, accesibilidad, seguridad, rendimiento, privacidad y más. La cifra cambia a medida que corrijo cosas.
¿RdyToGo va a dejar WordPress?
No. RdyToGo sigue construyendo sitios WordPress y seguirá haciéndolo, porque WordPress es la herramienta correcta para sitios que los clientes editan por sí mismos. La pila estática es una segunda opción para proyectos que quieren el control y el nivel de calidad de un sitio afinado a mano. Dos herramientas, elegidas para cada proyecto.
¿Quieres un sitio web construido con este estándar?
Si quieres un sitio que cumpla el mismo nivel que el mío, en WordPress o en esta pila estática, contacta a RdyToGo. Hablarás conmigo directamente.