{"id":3864,"date":"2026-09-27T13:52:07","date_gmt":"2026-09-27T11:52:07","guid":{"rendered":"https:\/\/mantenimientoweb.pro\/blog\/como-optimizar-el-codigo-html-css-y-js-para-alcanzar-un-100-100-en-google-pagespeed-2\/"},"modified":"2026-09-27T13:52:09","modified_gmt":"2026-09-27T11:52:09","slug":"como-optimizar-el-codigo-html-css-y-js-para-alcanzar-un-100-100-en-google-pagespeed-2","status":"publish","type":"post","link":"https:\/\/mantenimientoweb.pro\/blog\/como-optimizar-el-codigo-html-css-y-js-para-alcanzar-un-100-100-en-google-pagespeed-2\/","title":{"rendered":"\u00bfC\u00f3mo optimizar el c\u00f3digo HTML, CSS y JS para alcanzar un 100\/100 en Google PageSpeed?"},"content":{"rendered":"
\n
\n \u00bfC\u00f3mo optimizar el c\u00f3digo HTML, CSS y JS para alcanzar un 100\/100 en Google PageSpeed? \u26a1<\/p>\n

Una gu\u00eda profesional, realista y profundamente pr\u00e1ctica para acelerar tu sitio web, mejorar Core Web Vitals y dejar de tratar el rendimiento como ese caj\u00f3n lleno de cables que nadie se atreve a abrir.<\/p>\n<\/header>\n

<\/p>\n
\n

Un sitio web lento tiene algo de teatro absurdo: invertimos en dise\u00f1o, fotograf\u00edas impecables, animaciones seductoras y textos trabajados\u2026 para luego obligar al visitante a esperar frente a una pantalla en blanco. Es como recibir a alguien en una mansi\u00f3n y hacerlo entrar por el s\u00f3tano.<\/p>\n

Google PageSpeed Insights no es un juez perfecto, conviene decirlo pronto. A veces parece un profesor severo que resta puntos porque el l\u00e1piz no est\u00e1 alineado con el borde del pupitre. Pero sus advertencias suelen apuntar a problemas reales: JavaScript excesivo, CSS bloqueante, HTML hinchado, fuentes pesadas, im\u00e1genes sin optimizar, plugins que cargan media civilizaci\u00f3n grecorromana para mostrar un bot\u00f3n.<\/p>\n

Alcanzar un 100\/100 en Google PageSpeed<\/strong> es posible en muchos proyectos, especialmente en p\u00e1ginas est\u00e1ticas, landing pages bien construidas y sitios WordPress disciplinados. Pero no deber\u00eda convertirse en una religi\u00f3n. El objetivo serio es otro: hacer que la web sea r\u00e1pida, estable, segura y agradable para personas reales<\/strong>. El 100 es la medalla; la experiencia del usuario es la batalla.<\/p>\n

\ud83d\udccc Mapa de ruta<\/h2>\n
    \n
  1. Qu\u00e9 mide realmente Google PageSpeed<\/a><\/li>\n
  2. C\u00f3mo auditar antes de tocar c\u00f3digo<\/a><\/li>\n
  3. Optimizaci\u00f3n avanzada de HTML<\/a><\/li>\n
  4. Optimizaci\u00f3n de CSS: menos bloqueo, m\u00e1s velocidad<\/a><\/li>\n
  5. Optimizaci\u00f3n de JavaScript: el gran sospechoso<\/a><\/li>\n
  6. Estrategia espec\u00edfica para WordPress<\/a><\/li>\n
  7. Fuentes, im\u00e1genes y recursos cr\u00edticos<\/a><\/li>\n
  8. Servidor, cach\u00e9, CDN y compresi\u00f3n<\/a><\/li>\n
  9. Checklist profesional para acercarte al 100\/100<\/a><\/li>\n<\/ol>\n<\/section>\n
    \n

    1. Qu\u00e9 mide realmente Google PageSpeed Insights \ud83e\udded<\/h2>\n

    Google PageSpeed Insights<\/strong> combina datos de laboratorio y, cuando existen suficientes visitas, datos de campo procedentes del Chrome User Experience Report<\/strong>. Esta diferencia importa mucho. El laboratorio es una maqueta controlada; el campo es la calle con lluvia, tr\u00e1fico, m\u00f3viles antiguos y WiFi de cafeter\u00eda.<\/p>\n

    La puntuaci\u00f3n que ves en PageSpeed se basa en Lighthouse<\/strong>, una herramienta automatizada que simula la carga de una p\u00e1gina, normalmente con condiciones exigentes en m\u00f3vil. No eval\u00faa \u201clo bonita\u201d que es tu web. Eval\u00faa cu\u00e1nto tarda en ofrecer contenido \u00fatil, cu\u00e1nto se mueve la p\u00e1gina mientras carga, cu\u00e1nto bloquea el hilo principal y c\u00f3mo responde ante la interacci\u00f3n del usuario.<\/p>\n

    LCP recomendado<\/span>
    \n \u2264 2,5 s<\/strong><\/p>\n

    Largest Contentful Paint: cu\u00e1ndo aparece el contenido principal visible.<\/p>\n

    INP recomendado<\/span>
    \n \u2264 200 ms<\/strong><\/p>\n

    Interaction to Next Paint: capacidad de respuesta ante clics, toques y teclas.<\/p>\n

    CLS recomendado<\/span>
    \n \u2264 0,1<\/strong><\/p>\n

    Cumulative Layout Shift: estabilidad visual durante la carga.<\/p>\n

    TTFB orientativo<\/span>
    \n < 800 ms<\/strong><\/p>\n

    Time to First Byte: rapidez con la que el servidor empieza a responder.<\/p>\n

    Desde marzo de 2024, INP sustituy\u00f3 a FID<\/strong> como m\u00e9trica oficial de Core Web Vitals. No es un detalle decorativo: antes se med\u00eda la primera interacci\u00f3n; ahora se observa la capacidad general de respuesta. Es una diferencia parecida a juzgar a un camarero por el primer saludo o por todo el servicio de la cena.<\/p>\n

    Importante:<\/strong> un 100\/100 no garantiza autom\u00e1ticamente mejores posiciones SEO. La velocidad influye, s\u00ed, especialmente a trav\u00e9s de Core Web Vitals y experiencia de usuario, pero el posicionamiento depende tambi\u00e9n de contenido, intenci\u00f3n de b\u00fasqueda, autoridad, arquitectura, enlazado interno, rastreabilidad, sem\u00e1ntica, reputaci\u00f3n y otros factores. El rendimiento abre la puerta; no escribe el libro entero.<\/p>\n<\/section>\n

    \n

    2. Antes de optimizar: mide como cirujano, no como adivino \ud83d\udd2c<\/h2>\n

    El pecado original de muchas optimizaciones web es empezar instalando un plugin de cach\u00e9 \u201ca ver si mejora\u201d. A veces mejora. A veces rompe el men\u00fa, oculta el carrito y convierte la web en una ruleta rusa con favicon. Qu\u00e9 elegante forma de ahorrar tiempo perdi\u00e9ndolo todo.<\/p>\n

    Antes de tocar HTML, CSS o JavaScript, crea una fotograf\u00eda del estado actual:<\/p>\n

      \n
    • PageSpeed Insights:<\/strong> \u00fatil para diagn\u00f3stico general, m\u00e9tricas Core Web Vitals y oportunidades de mejora.<\/li>\n
    • Lighthouse en Chrome DevTools:<\/strong> permite pruebas locales, modo inc\u00f3gnito y comparaci\u00f3n tras cambios concretos.<\/li>\n
    • WebPageTest:<\/strong> excelente para analizar cascadas de carga, TTFB, CDN, geolocalizaci\u00f3n y video de renderizado.<\/li>\n
    • Chrome DevTools Performance:<\/strong> imprescindible para detectar tareas largas de JavaScript, bloqueo del hilo principal y problemas de interacci\u00f3n.<\/li>\n
    • Coverage en DevTools:<\/strong> muestra CSS y JS no utilizados, esa especie de polvo digital que se acumula sin hacer ruido.<\/li>\n
    • Query Monitor en WordPress:<\/strong> ayuda a localizar consultas lentas, hooks costosos, plantillas pesadas y plugins problem\u00e1ticos.<\/li>\n<\/ul>\n

      Qu\u00e9 debes registrar antes de empezar<\/h3>\n\n\n\n\n\n\n\n\n\n\n
      Dato<\/th>\nPor qu\u00e9 importa<\/th>\nHerramienta recomendada<\/th>\n<\/tr>\n<\/thead>\n
      LCP<\/td>\nIndica si el contenido principal tarda demasiado en aparecer.<\/td>\nPageSpeed, Lighthouse, WebPageTest<\/td>\n<\/tr>\n
      INP \/ tareas largas<\/td>\nRevela si JavaScript bloquea la interacci\u00f3n.<\/td>\nCrUX, DevTools Performance<\/td>\n<\/tr>\n
      CLS<\/td>\nDetecta saltos visuales provocados por im\u00e1genes, anuncios, fuentes o embeds.<\/td>\nPageSpeed, Lighthouse<\/td>\n<\/tr>\n
      Peso total de la p\u00e1gina<\/td>\nCuanto m\u00e1s se descarga, m\u00e1s depende la experiencia de la red del usuario.<\/td>\nNetwork panel, WebPageTest<\/td>\n<\/tr>\n
      N\u00famero de solicitudes<\/td>\nMuchas peticiones pueden aumentar latencia, aunque HTTP\/2 y HTTP\/3 reducen parte del impacto.<\/td>\nNetwork panel<\/td>\n<\/tr>\n
      TTFB<\/td>\nSi el servidor responde tarde, el frontend empieza la carrera con una piedra atada al tobillo.<\/td>\nWebPageTest, PageSpeed<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

      Trabaja siempre en staging<\/strong> si el sitio es importante. Haz copia de seguridad. Documenta cambios. Optimizar sin m\u00e9todo es como podar un bons\u00e1i con una motosierra: algo quedar\u00e1 m\u00e1s peque\u00f1o, desde luego, pero quiz\u00e1 no m\u00e1s bello.<\/p>\n<\/section>\n

      \n

      3. Optimizaci\u00f3n HTML: la estructura invisible que decide mucho \ud83e\uddf1<\/h2>\n

      El HTML suele ser el pariente tranquilo del rendimiento web. No grita como JavaScript ni bloquea con la solemnidad del CSS, pero una estructura deficiente puede multiplicar nodos, retrasar el renderizado, confundir al navegador y dificultar la accesibilidad.<\/p>\n

      3.1 Reduce el HTML innecesario<\/h3>\n

      Muchos sitios modernos generan capas y capas de contenedores: <div><\/code> dentro de <div><\/code> dentro de <div><\/code>, como mu\u00f1ecas rusas fabricadas por un comit\u00e9 cansado. En constructores visuales de WordPress esto es frecuente: Elementor, WPBakery, Divi o ciertos temas multiprop\u00f3sito pueden producir HTML abundante incluso para secciones simples.<\/p>\n

      No se trata de perseguir un n\u00famero m\u00e1gico de nodos, sino de evitar \u00e1rboles DOM enormes. Un DOM demasiado grande puede aumentar el coste de estilos, layouts y scripts.<\/p>\n

        \n
      • Elimina contenedores que no aportan dise\u00f1o, sem\u00e1ntica ni comportamiento.<\/li>\n
      • Usa etiquetas sem\u00e1nticas: <header><\/code>, <main><\/code>, <section><\/code>, <article><\/code>, <nav><\/code>, <footer><\/code>.<\/li>\n
      • Evita men\u00fas gigantes cargados en todas las p\u00e1ginas si no son necesarios.<\/li>\n
      • No insertes shortcodes pesados en zonas globales si solo se necesitan en una plantilla.<\/li>\n
      • Revisa widgets de redes sociales, iframes y bloques de terceros.<\/li>\n<\/ul>\n

        3.2 Prioriza el contenido visible<\/h3>\n

        El navegador lee el documento de arriba abajo. Lo que coloques en el <head><\/code> y al inicio del <body><\/code> afecta directamente a la percepci\u00f3n de velocidad. Tu objetivo es que el contenido principal \u2014normalmente el t\u00edtulo, el texto inicial y la imagen hero\u2014 aparezca pronto.<\/p>\n

        <!-- Bien: estructura clara y contenido principal temprano -->\n<body>\n  <header>...<\/header>\n\n  <main>\n    <section>\n      <h1>Servicio profesional de mantenimiento WordPress<\/h1>\n      <p>Soporte, seguridad y optimizaci\u00f3n para sitios empresariales.<\/p>\n      <img\n        src=\"\/img\/mantenimiento-wordpress.webp\"\n        width=\"1200\"\n        height=\"675\"\n        alt=\"Panel de administraci\u00f3n de WordPress optimizado\"\n        fetchpriority=\"high\">\n    <\/section>\n  <\/main>\n<\/body><\/code><\/pre>\n
        El atributo fetchpriority=\"high\"<\/code> puede ayudar cuando la imagen principal es el elemento LCP. \u00dasalo con moderaci\u00f3n. Si todo es urgente, nada lo es; una lecci\u00f3n que tambi\u00e9n servir\u00eda para algunos grupos de WhatsApp laborales.<\/p>\n
        3.3 Evita saltos de dise\u00f1o con dimensiones expl\u00edcitas<\/h3>\n
        Una causa habitual de CLS<\/strong> es cargar im\u00e1genes, v\u00eddeos, iframes o anuncios sin reservar espacio. El navegador no es vidente. Si no conoce el tama\u00f1o, pinta una cosa y luego la recoloca. Para el usuario, la p\u00e1gina salta como una liebre asustada.<\/p>\n
        <img\n  src=\"\/imagenes\/consultoria-seo.webp\"\n  width=\"960\"\n  height=\"540\"\n  alt=\"Auditor\u00eda SEO t\u00e9cnica en una pantalla\"\n  loading=\"lazy\"\n  decoding=\"async\"><\/code><\/pre>\n
        En im\u00e1genes bajo el primer pantallazo, loading=\"lazy\"<\/code> suele ser recomendable. En la imagen hero, no. Cargar perezosamente el elemento principal visible puede empeorar el LCP, una iron\u00eda bastante fina: intentas acelerar la web retrasando justo lo que m\u00e1s necesitas mostrar.<\/p>\n
        3.4 Limpia el head<\/h3>\n
        El <head><\/code> de algunas webs parece un trastero con etiquetas meta duplicadas, scripts de campa\u00f1as antiguas, verificaciones olvidadas y hojas de estilo de plugins que ya no existen. Revisa:<\/p>\n
          \n
        • Etiquetas meta duplicadas o generadas por varios plugins SEO.<\/li>\n
        • Scripts de tracking no utilizados.<\/li>\n
        • Preloads obsoletos.<\/li>\n
        • Fuentes externas repetidas.<\/li>\n
        • CSS de plugins cargado globalmente.<\/li>\n
        • Fragmentos de herramientas de marketing retiradas.<\/li>\n<\/ul>\n
          Menos basura en el head significa menos bloqueo, menos DNS lookup, menos posibilidades de conflicto y una auditor\u00eda m\u00e1s limpia.<\/p>\n<\/section>\n
          \n
          4. Optimizaci\u00f3n CSS: el arte de pintar r\u00e1pido sin mancharlo todo \ud83c\udfa8<\/h2>\n
          El CSS es render-blocking por naturaleza: el navegador necesita entender los estilos antes de pintar correctamente la p\u00e1gina. Esto tiene sentido. Nadie quiere ver una web desnuda durante medio segundo y luego vestida de gala, aunque a veces ocurra con una sinceridad casi conmovedora.<\/p>\n
          4.1 Extrae CSS cr\u00edtico<\/h3>\n
          El CSS cr\u00edtico<\/strong> es el conjunto m\u00ednimo de estilos necesarios para renderizar la parte visible inicial de una p\u00e1gina. Si el navegador debe descargar un archivo CSS enorme antes de mostrar el hero, el men\u00fa y el t\u00edtulo, el LCP puede sufrir.<\/p>\n
          Una estrategia habitual:<\/p>\n
            \n
          1. Insertar inline el CSS cr\u00edtico del primer pantallazo.<\/li>\n
          2. Cargar el CSS completo de forma eficiente.<\/li>\n
          3. Eliminar reglas no utilizadas por plantilla.<\/li>\n<\/ol>\n
            <style>\n  body { margin: 0; font-family: system-ui, sans-serif; }\n  .hero { padding: 64px 6vw; background: #0f172a; color: #fff; }\n  .hero h1 { font-size: clamp(2rem, 5vw, 4.5rem); line-height: 1.05; }\n<\/style>\n\n<link rel=\"preload\" href=\"\/css\/app.min.css\" as=\"style\" onload=\"this.onload=null;this.rel='stylesheet'\">\n<noscript><link rel=\"stylesheet\" href=\"\/css\/app.min.css\"><\/noscript><\/code><\/pre>\n
            Esta t\u00e9cnica debe probarse bien. Si se implementa mal, puede provocar FOUC \u2014Flash of Unstyled Content\u2014, ese instante en que la web aparece sin peinar, como quien abre la puerta al cartero en pijama.<\/p>\n
            4.2 Elimina CSS no utilizado<\/h3>\n
            Frameworks, temas comerciales y librer\u00edas de componentes suelen incluir mucho m\u00e1s CSS del que una p\u00e1gina necesita. Bootstrap completo para usar una rejilla y dos botones. Tailwind sin purgado. Icon libraries enteras para mostrar tres iconos. Maravilloso progreso: enviamos una enciclopedia para decir \u201chola\u201d.<\/p>\n
            Acciones recomendadas:<\/p>\n
              \n
            • Usa PurgeCSS<\/strong>, Tailwind content scanning<\/strong> o herramientas equivalentes en procesos de build.<\/li>\n
            • Divide CSS por plantilla: home, blog, producto, checkout, \u00e1rea privada.<\/li>\n
            • Evita cargar estilos de sliders, galer\u00edas o formularios en p\u00e1ginas donde no existen.<\/li>\n
            • Reemplaza librer\u00edas grandes por CSS nativo cuando sea razonable.<\/li>\n
            • Audita con la pesta\u00f1a Coverage<\/strong> de Chrome DevTools.<\/li>\n<\/ul>\n
              4.3 Minifica, pero no confundas minificar con optimizar<\/h3>\n
              Minificar CSS elimina espacios, saltos de l\u00ednea y comentarios. Es \u00fatil. Pero si tu archivo pesa 400 KB porque contiene media tienda de disfraces estil\u00edsticos, minificarlo no resuelve el problema de fondo. Lo hace m\u00e1s peque\u00f1o, s\u00ed, como comprimir una maleta sin preguntarse por qu\u00e9 llevas seis abrigos al Caribe.<\/p>\n\n\n\n\n\n\n\n\n
              T\u00e9cnica<\/th>\nImpacto<\/th>\nRiesgo<\/th>\n<\/tr>\n<\/thead>\n
              Minificaci\u00f3n<\/td>\nReduce peso del archivo.<\/td>\nBajo, si se prueba correctamente.<\/td>\n<\/tr>\n
              CSS cr\u00edtico<\/td>\nMejora FCP y LCP.<\/td>\nMedio: puede causar estilos incompletos si se genera mal.<\/td>\n<\/tr>\n
              Eliminar CSS no usado<\/td>\nReduce descarga y c\u00e1lculo de estilos.<\/td>\nMedio: puede borrar clases din\u00e1micas si no se configuran safelists.<\/td>\n<\/tr>\n
              Divisi\u00f3n por plantilla<\/td>\nEvita cargar CSS innecesario en todo el sitio.<\/td>\nBajo\/medio seg\u00fan arquitectura.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
              4.4 Usa CSS moderno con criterio<\/h3>\n
              CSS moderno permite hacer hoy lo que antes requer\u00eda JavaScript: acordeones simples, sticky headers, scroll snapping, grids complejos, animaciones ligeras. Cada comportamiento que puedas resolver con CSS en lugar de JS reduce trabajo del hilo principal.<\/p>\n
              \/* Evita animar propiedades costosas como width, height, top o left *\/\n.card {\n  transition: transform 180ms ease, opacity 180ms ease;\n}\n\n.card:hover {\n  transform: translateY(-4px);\n}\n\n\/* Respeta usuarios que prefieren menos movimiento *\/\n@media (prefers-reduced-motion: reduce) {\n  * {\n    animation-duration: 0.001ms !important;\n    transition-duration: 0.001ms !important;\n  }\n}<\/code><\/pre>\n
              Anima transform<\/code> y opacity<\/code> siempre que puedas. Evita animaciones que fuerzan layout y repintado constante. La diferencia entre una animaci\u00f3n fluida y una torpe es como la diferencia entre seda y papel de lija: ambas se sienten, pero una no pide disculpas.<\/p>\n<\/section>\n
              \n
              5. Optimizaci\u00f3n JavaScript: domar al animal que m\u00e1s muerde \ud83d\udc09<\/h2>\n
              Si HTML es estructura y CSS es pintura, JavaScript es maquinaria. Puede convertir una p\u00e1gina en una aplicaci\u00f3n brillante o en un tractor cruzando una biblioteca. Gran parte de los problemas de PageSpeed, especialmente en m\u00f3vil, proviene de JavaScript excesivo, mal diferido o innecesario<\/strong>.<\/p>\n
              5.1 Comprende async, defer y type=\u00bbmodule\u00bb<\/h3>\n
              Uno de los errores m\u00e1s comunes es cargar scripts en el <head><\/code> sin estrategia. El navegador se detiene, descarga, ejecuta y solo entonces contin\u00faa. Es como si el camarero dejara de atender a todos para leer el manual de la cafetera en mitad del desayuno.<\/p>\n\n\n\n\n\n\n\n
              Atributo<\/th>\nComportamiento<\/th>\nUso recomendado<\/th>\n<\/tr>\n<\/thead>\n
              defer<\/code><\/td>\nDescarga en paralelo y ejecuta cuando el HTML ya fue parseado, respetando el orden.<\/td>\nScripts propios que dependen del DOM.<\/td>\n<\/tr>\n
              async<\/code><\/td>\nDescarga en paralelo y ejecuta en cuanto est\u00e1 listo, sin garantizar orden.<\/td>\nAnalytics, p\u00edxeles y scripts independientes.<\/td>\n<\/tr>\n
              type=\"module\"<\/code><\/td>\nSe comporta como defer por defecto y permite importar m\u00f3dulos.<\/td>\nJavaScript moderno, modular y mantenible.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
              <!-- Recomendado para scripts propios -->\n<script src=\"\/js\/main.min.js\" defer><\/script>\n\n<!-- Recomendado para scripts independientes de terceros -->\n<script src=\"https:\/\/www.googletagmanager.com\/gtag\/js?id=G-XXXX\" async><\/script>\n\n<!-- JavaScript moderno por m\u00f3dulos -->\n<script type=\"module\" src=\"\/js\/app.js\"><\/script><\/code><\/pre>\n
              5.2 Reduce el coste del hilo principal<\/h3>\n
              El navegador tiene un hilo principal donde ocurren tareas cruciales: parsear HTML, calcular estilos, ejecutar JavaScript, dise\u00f1ar layout y pintar. Cuando JavaScript ocupa ese hilo durante demasiado tiempo, el usuario toca un bot\u00f3n y nada responde. La web parece viva, pero no escucha. Una estatua con formulario de contacto.<\/p>\n
              Para mejorar INP<\/strong> y reducir Total Blocking Time<\/strong> en Lighthouse:<\/p>\n
                \n
              • Divide tareas largas en tareas peque\u00f1as.<\/li>\n
              • Retrasa l\u00f3gica no esencial hasta despu\u00e9s de la carga inicial.<\/li>\n
              • Usa requestIdleCallback<\/code> para trabajos de baja prioridad, con fallback.<\/li>\n
              • Evita listeners excesivos; delega eventos cuando sea posible.<\/li>\n
              • No recalcules layout en bucles leyendo y escribiendo propiedades del DOM alternadamente.<\/li>\n
              • Considera Web Workers para c\u00e1lculos pesados.<\/li>\n<\/ul>\n
                \/\/ Evita ejecutar tareas no cr\u00edticas durante la carga inicial\nfunction runWhenIdle(callback) {\n  if (\"requestIdleCallback\" in window) {\n    requestIdleCallback(callback, { timeout: 2000 });\n  } else {\n    setTimeout(callback, 1200);\n  }\n}\n\nrunWhenIdle(() => {\n  \/\/ Cargar chat, mapas, widgets secundarios o personalizaci\u00f3n no cr\u00edtica\n  initNonCriticalWidgets();\n});<\/code><\/pre>\n
                5.3 Carga JavaScript solo donde se necesita<\/h3>\n
                Una p\u00e1gina de \u201cSobre nosotros\u201d no necesita el JavaScript del checkout. Un art\u00edculo de blog no necesita el slider de la home. Un formulario de contacto no deber\u00eda cargar scripts de una galer\u00eda que vive tres clics m\u00e1s all\u00e1. Parece obvio, hasta que uno abre DevTools y descubre que la p\u00e1gina m\u00e1s simple del sitio transporta equipaje para una mudanza.<\/p>\n
                En proyectos modernos, aplica:<\/p>\n
                  \n
                • Code splitting:<\/strong> dividir el bundle en fragmentos por ruta o componente.<\/li>\n
                • Tree shaking:<\/strong> eliminar c\u00f3digo importado que no se usa.<\/li>\n
                • Dynamic imports:<\/strong> cargar m\u00f3dulos solo cuando hacen falta.<\/li>\n
                • Lazy hydration:<\/strong> hidratar componentes interactivos cuando entran en viewport o cuando el usuario interact\u00faa.<\/li>\n
                • Islas de interactividad:<\/strong> HTML est\u00e1tico por defecto, JavaScript solo en zonas necesarias.<\/li>\n<\/ul>\n
                  const button = document.querySelector(\"[data-open-gallery]\");\n\nbutton?.addEventListener(\"click\", async () => {\n  const { initGallery } = await import(\".\/gallery.js\");\n  initGallery();\n});<\/code><\/pre>\n
                  5.4 Cuidado con las dependencias<\/h3>\n
                  Cada librer\u00eda debe defender su presencia. jQuery no es pecado, pero cargarlo para alternar una clase CSS en 2026 tiene algo de procesi\u00f3n barroca para cambiar una bombilla. Lo mismo ocurre con carruseles, animaciones, popups, selectores personalizados y frameworks completos para interfaces m\u00ednimas.<\/p>\n
                  Preguntas saludables antes de a\u00f1adir una dependencia:<\/p>\n
                    \n
                  • \u00bfCu\u00e1nto pesa minificada y comprimida?<\/li>\n
                  • \u00bfCu\u00e1nto tarda en parsearse y ejecutarse en m\u00f3vil?<\/li>\n
                  • \u00bfSe carga en todas las p\u00e1ginas o solo donde se usa?<\/li>\n
                  • \u00bfExiste una alternativa nativa?<\/li>\n
                  • \u00bfLa dependencia est\u00e1 mantenida y no introduce riesgos de seguridad?<\/li>\n<\/ul>\n
                    5.5 Scripts de terceros: el enemigo cordial<\/h3>\n
                    Analytics, chat, p\u00edxeles publicitarios, mapas, v\u00eddeos incrustados, herramientas A\/B testing, CRM, heatmaps. Todos prometen conocimiento. Todos cobran en rendimiento. Los scripts de terceros son como invitados con maletas: alguno aporta conversaci\u00f3n; demasiados ocupan el sal\u00f3n.<\/p>\n
                    Medidas recomendadas:<\/p>\n
                      \n
                    • Carga scripts de marketing tras consentimiento si aplica normativa de privacidad.<\/li>\n
                    • Retrasa chat y widgets no esenciales hasta interacci\u00f3n o varios segundos despu\u00e9s del LCP.<\/li>\n
                    • Usa fachadas para YouTube, Google Maps o embeds pesados.<\/li>\n
                    • Elimina herramientas duplicadas: dos analytics, tres p\u00edxeles, cuatro heatmaps\u2026 el museo del seguimiento.<\/li>\n
                    • Define un proceso interno: ning\u00fan script externo entra sin responsable, objetivo y fecha de revisi\u00f3n.<\/li>\n<\/ul>\n
                      <button data-youtube-id=\"abc123\">\n  \u25b6 Ver v\u00eddeo\n<\/button>\n\n<script defer>\ndocument.addEventListener(\"click\", event => {\n  const button = event.target.closest(\"[data-youtube-id]\");\n  if (!button) return;\n\n  const iframe = document.createElement(\"iframe\");\n  iframe.src = `https:\/\/www.youtube.com\/embed\/${button.dataset.youtubeId}?autoplay=1`;\n  iframe.width = \"560\";\n  iframe.height = \"315\";\n  iframe.loading = \"lazy\";\n  iframe.allow = \"accelerometer; autoplay; encrypted-media; picture-in-picture\";\n  iframe.allowFullscreen = true;\n\n  button.replaceWith(iframe);\n});\n<\/script><\/code><\/pre>\n<\/section>\n
                      \n
                      6. WordPress: rendimiento real sin romper el sitio \ud83d\udee0\ufe0f<\/h2>\n
                      WordPress puede ser r\u00e1pido. Muy r\u00e1pido. Pero tambi\u00e9n puede transformarse en una ciudad medieval donde cada plugin construye una muralla, abre un mercado y convoca una feria. La diferencia no est\u00e1 solo en WordPress; est\u00e1 en c\u00f3mo se mantiene.<\/p>\n
                      6.1 Elige bien tema, constructor y plugins<\/h3>\n
                      Para lograr un buen PageSpeed en WordPress, el punto de partida pesa m\u00e1s de lo que se admite en reuniones comerciales. Un tema ligero como GeneratePress, Astra, Blocksy o un tema a medida bien hecho suele partir con ventaja frente a temas multiprop\u00f3sito cargados de demos, sliders, icon packs y opciones que jam\u00e1s usar\u00e1s.<\/p>\n
                        \n
                      • Evita instalar plugins para funciones triviales que pueden resolverse con pocas l\u00edneas de c\u00f3digo.<\/li>\n
                      • Desactiva y elimina plugins inactivos.<\/li>\n
                      • Audita plugins que cargan CSS\/JS globalmente.<\/li>\n
                      • Comprueba compatibilidad con PHP actualizado.<\/li>\n
                      • No uses varios plugins que hagan lo mismo: cach\u00e9, SEO, seguridad, optimizaci\u00f3n de im\u00e1genes, formularios.<\/li>\n<\/ul>\n
                        6.2 Descarga assets por condici\u00f3n<\/h3>\n
                        En WordPress puedes evitar que un plugin cargue archivos donde no debe. Por ejemplo, Contact Form 7 no necesita cargar su CSS y JS en todas las p\u00e1ginas si el formulario solo aparece en \u201cContacto\u201d.<\/p>\n
                        \/\/ functions.php o plugin personalizado\nadd_action('wp_enqueue_scripts', function () {\n  if (!is_page('contacto')) {\n    wp_dequeue_style('contact-form-7');\n    wp_dequeue_script('contact-form-7');\n  }\n}, 99);<\/code><\/pre>\n
                        La clave es identificar correctamente los handles de cada script o estilo. Herramientas como Query Monitor, Asset CleanUp o Perfmatters pueden ayudar. Eso s\u00ed: prueba formularios, carritos, popups y \u00e1reas privadas despu\u00e9s. Optimizar rompiendo conversiones es una forma bastante cara de ganar puntos.<\/p>\n
                        6.3 Usa cach\u00e9 de p\u00e1gina y cach\u00e9 de objeto<\/h3>\n
                        Para sitios WordPress, la cach\u00e9 suele marcar una diferencia enorme en TTFB. Una p\u00e1gina servida desde cach\u00e9 evita repetir consultas, renderizado PHP y trabajo innecesario.<\/p>\n
                          \n
                        • Cach\u00e9 de p\u00e1gina:<\/strong> WP Rocket, LiteSpeed Cache, FlyingPress, Cache Enabler o soluciones del hosting.<\/li>\n
                        • Cach\u00e9 de objeto:<\/strong> Redis o Memcached, especialmente en WooCommerce, membres\u00edas o sitios con consultas frecuentes.<\/li>\n
                        • OPcache:<\/strong> recomendable en PHP para mejorar ejecuci\u00f3n.<\/li>\n
                        • CDN:<\/strong> \u00fatil para servir recursos est\u00e1ticos cerca del usuario.<\/li>\n<\/ul>\n
                          6.4 WooCommerce: caso especial<\/h3>\n
                          WooCommerce merece trato delicado. No puedes cachear carrito, checkout o cuenta como si fueran p\u00e1ginas est\u00e1ticas. Tampoco deber\u00edas retrasar scripts esenciales de compra. Aqu\u00ed hay ant\u00edtesis pura: quieres velocidad de escaparate y precisi\u00f3n de caja registradora.<\/p>\n
                          Recomendaciones:<\/p>\n
                            \n
                          • Excluye carrito, checkout y mi cuenta de cach\u00e9 de p\u00e1gina.<\/li>\n
                          • Optimiza fragmentos de carrito si generan llamadas AJAX costosas.<\/li>\n
                          • Carga scripts de pasarelas de pago solo en checkout cuando sea posible.<\/li>\n
                          • Revisa plugins de filtros, variaciones y b\u00fasqueda; pueden ser pesados.<\/li>\n
                          • Usa hosting preparado para consultas din\u00e1micas y tr\u00e1fico concurrente.<\/li>\n<\/ul>\n
                            6.5 Seguridad y rendimiento van juntos<\/h3>\n
                            Un sitio infectado, con spam SEO, redirecciones ocultas o scripts inyectados no va a rendir bien. Adem\u00e1s, un WordPress desactualizado puede cargar c\u00f3digo malicioso que PageSpeed no te explicar\u00e1 con ternura. Te mostrar\u00e1 s\u00edntomas; el diagn\u00f3stico forense lo tendr\u00e1s que hacer t\u00fa.<\/p>\n
                              \n
                            • Mant\u00e9n WordPress, temas y plugins actualizados.<\/li>\n
                            • Elimina extensiones abandonadas.<\/li>\n
                            • Usa permisos correctos en archivos y carpetas.<\/li>\n
                            • Activa WAF si el proyecto lo requiere.<\/li>\n
                            • Implementa cabeceras de seguridad como CSP, X-Content-Type-Options y Referrer-Policy con cuidado.<\/li>\n
                            • Monitoriza cambios de archivos y usuarios administradores.<\/li>\n<\/ul>\n<\/section>\n
                              \n
                              7. Fuentes, im\u00e1genes y recursos cr\u00edticos: aunque el t\u00edtulo diga HTML, CSS y JS \ud83d\uddbc\ufe0f<\/h2>\n
                              Ser\u00eda c\u00f3modo hablar solo de c\u00f3digo, pero PageSpeed no vive en una isla. Im\u00e1genes, fuentes y servidor influyen tanto que ignorarlos ser\u00eda como afinar un viol\u00edn mientras el barco se hunde.<\/p>\n
                              7.1 Optimiza im\u00e1genes para LCP<\/h3>\n
                              La imagen principal suele ser el elemento LCP en p\u00e1ginas comerciales, blogs visuales y tiendas online. Optimizarla puede dar m\u00e1s resultado que discutir durante dos horas si un archivo JS deber\u00eda pesar 27 o 31 KB.<\/p>\n
                                \n
                              • Usa formatos modernos: AVIF<\/strong> cuando sea viable, WebP<\/strong> como opci\u00f3n muy compatible.<\/li>\n
                              • Sirve tama\u00f1os adaptados con srcset<\/code> y sizes<\/code>.<\/li>\n
                              • Comprime sin destruir la calidad perceptual.<\/li>\n
                              • No apliques lazy loading a la imagen LCP.<\/li>\n
                              • Define width<\/code> y height<\/code>.<\/li>\n
                              • Usa CDN de im\u00e1genes si gestionas mucho contenido visual.<\/li>\n<\/ul>\n
                                <picture>\n  <source\n    type=\"image\/avif\"\n    srcset=\"\/img\/hero-640.avif 640w, \/img\/hero-1280.avif 1280w, \/img\/hero-1920.avif 1920w\">\n  <source\n    type=\"image\/webp\"\n    srcset=\"\/img\/hero-640.webp 640w, \/img\/hero-1280.webp 1280w, \/img\/hero-1920.webp 1920w\">\n  <img\n    src=\"\/img\/hero-1280.webp\"\n    width=\"1280\"\n    height=\"720\"\n    alt=\"Equipo t\u00e9cnico optimizando el rendimiento de un sitio web\"\n    fetchpriority=\"high\"\n    decoding=\"async\">\n<\/picture><\/code><\/pre>\n
                                7.2 Fuentes web: belleza con factura<\/h3>\n
                                Las fuentes personalizadas aportan identidad, pero tambi\u00e9n pueden retrasar el renderizado. Una tipograf\u00eda cargada desde un dominio externo a\u00f1ade DNS, conexi\u00f3n TLS y descarga. No es tragedia, pero tampoco magia gratis.<\/p>\n
                                Buenas pr\u00e1cticas:<\/p>\n
                                  \n
                                • Usa formatos WOFF2<\/strong>.<\/li>\n
                                • Limita pesos y estilos: regular, semibold y bold suelen bastar.<\/li>\n
                                • Aloja fuentes localmente cuando sea conveniente.<\/li>\n
                                • Aplica font-display: swap<\/code> o estrategias similares.<\/li>\n
                                • Preload solo de la fuente cr\u00edtica realmente usada en el primer pantallazo.<\/li>\n<\/ul>\n
                                  <link\n  rel=\"preload\"\n  href=\"\/fonts\/inter-var.woff2\"\n  as=\"font\"\n  type=\"font\/woff2\"\n  crossorigin>\n\n<style>\n@font-face {\n  font-family: \"Inter\";\n  src: url(\"\/fonts\/inter-var.woff2\") format(\"woff2\");\n  font-weight: 100 900;\n  font-display: swap;\n}\n<\/style><\/code><\/pre>\n
                                  7.3 Preconnect y DNS-prefetch<\/h3>\n
                                  Cuando dependes de recursos externos cr\u00edticos \u2014fuentes, CDN, APIs\u2014 puedes adelantar conexiones con preconnect<\/code>. \u00dasalo para pocos or\u00edgenes verdaderamente importantes. Si llenas el head de preconnects, vuelves al punto de partida: demasiadas urgencias compitiendo por la puerta.<\/p>\n
                                  <link rel=\"preconnect\" href=\"https:\/\/fonts.gstatic.com\" crossorigin>\n<link rel=\"dns-prefetch\" href=\"\/\/www.googletagmanager.com\"><\/code><\/pre>\n<\/section>\n
                                  \n
                                  8. Servidor, cach\u00e9, CDN y compresi\u00f3n: el c\u00f3digo no corre en el vac\u00edo \ud83c\udf10<\/h2>\n
                                  Una web puede tener HTML impecable, CSS minimalista y JavaScript casi mon\u00e1stico. Si el servidor tarda dos segundos en responder, PageSpeed levantar\u00e1 la ceja. Y con raz\u00f3n.<\/p>\n
                                  8.1 Mejora TTFB<\/h3>\n
                                  El Time to First Byte<\/strong> depende de hosting, DNS, proximidad geogr\u00e1fica, cach\u00e9, base de datos, PHP, plugins, tema y carga del servidor. En WordPress, un TTFB alto suele venir de consultas lentas, ausencia de cach\u00e9, hosting saturado o plugins que ejecutan demasiado trabajo en cada visita.<\/p>\n
                                    \n
                                  • Usa hosting con recursos reales, no solo promesas con foto de cohete.<\/li>\n
                                  • Activa cach\u00e9 de p\u00e1gina.<\/li>\n
                                  • Actualiza a una versi\u00f3n moderna y soportada de PHP.<\/li>\n
                                  • Optimiza base de datos: autoload excesivo, transients vencidos, tablas enormes.<\/li>\n
                                  • Reduce llamadas externas en el renderizado inicial.<\/li>\n
                                  • Implementa CDN si tienes audiencia distribuida geogr\u00e1ficamente.<\/li>\n<\/ul>\n
                                    8.2 Brotli, Gzip y cabeceras de cach\u00e9<\/h3>\n
                                    HTML, CSS y JS deben servirse comprimidos. Brotli suele ofrecer mejores ratios que Gzip en muchos casos, especialmente para texto, aunque depende del servidor y configuraci\u00f3n. La compresi\u00f3n es una de esas mejoras discretas que no hacen ruido, como un buen editor corrigiendo una frase antes de que nadie la vea.<\/p>\n
                                    # Ejemplo orientativo para Nginx: cach\u00e9 de archivos est\u00e1ticos\nlocation ~* \\.(css|js|jpg|jpeg|png|webp|avif|gif|svg|woff2)$ {\n  expires 1y;\n  add_header Cache-Control \"public, max-age=31536000, immutable\";\n}<\/code><\/pre>\n
                                    La estrategia immutable<\/code> funciona bien si versionas archivos, por ejemplo app.8f3a2c.css<\/code>. Si no versionas, puedes dejar a usuarios con archivos antiguos tras cambios importantes. El rendimiento exige memoria; la cach\u00e9, adem\u00e1s, exige disciplina.<\/p>\n
                                    8.3 HTTP\/2 y HTTP\/3<\/h3>\n
                                    HTTP\/2 permite multiplexaci\u00f3n: varias solicitudes sobre una misma conexi\u00f3n. HTTP\/3, basado en QUIC, puede mejorar rendimiento en redes inestables y reducir costes de reconexi\u00f3n. No sustituyen a una buena optimizaci\u00f3n, pero cambian ciertas decisiones antiguas.<\/p>\n
                                    Por ejemplo, en HTTP\/1.1 era com\u00fan combinar todos los archivos para reducir solicitudes. En HTTP\/2, dividir por funcionalidad puede ser razonable si se cachea bien. Antiguo dogma: \u201cun solo archivo para todo\u201d. Nueva prudencia: \u201clos archivos justos, bien priorizados y cacheables\u201d.<\/p>\n<\/section>\n
                                    \n
                                    9. Estrategia pr\u00e1ctica para llegar a 100\/100 sin perseguir fantasmas \ud83c\udfaf<\/h2>\n
                                    Un 100\/100 en Google PageSpeed suele requerir una combinaci\u00f3n de peque\u00f1as mejoras y algunas decisiones valientes. No basta con minificar. No basta con instalar cach\u00e9. No basta con culpar al hosting, aunque a veces el hosting haga m\u00e9ritos con entusiasmo.<\/p>\n
                                    Orden recomendado de trabajo<\/h3>\n
                                      \n
                                    1. Audita:<\/strong> PageSpeed, Lighthouse, DevTools, WebPageTest.<\/li>\n
                                    2. Resuelve servidor y TTFB:<\/strong> cach\u00e9, hosting, PHP, base de datos.<\/li>\n
                                    3. Optimiza el LCP:<\/strong> imagen hero, CSS cr\u00edtico, preload correcto, HTML inicial limpio.<\/li>\n
                                    4. Reduce JavaScript:<\/strong> elimina, divide, difiere, retrasa terceros.<\/li>\n
                                    5. Reduce CSS:<\/strong> cr\u00edtico, purgado, divisi\u00f3n por plantilla.<\/li>\n
                                    6. Controla CLS:<\/strong> dimensiones, espacios reservados, fuentes, banners, anuncios.<\/li>\n
                                    7. Optimiza im\u00e1genes y fuentes:<\/strong> formatos modernos, tama\u00f1os correctos, font-display.<\/li>\n
                                    8. Repite medici\u00f3n:<\/strong> compara antes\/despu\u00e9s y revisa en m\u00f3vil.<\/li>\n
                                    9. Monitoriza datos de campo:<\/strong> Search Console y CrUX necesitan tiempo para reflejar cambios.<\/li>\n<\/ol>\n
                                      Consejo de mantenimiento:<\/strong> no optimices una vez y desaparezcas. Cada plugin nuevo, campa\u00f1a de marketing, p\u00edxel publicitario, banner legal o redise\u00f1o puede degradar Core Web Vitals. El rendimiento web no es una estatua; es un jard\u00edn. Si no lo cuidas, crece maleza.<\/p>\n
                                      Errores frecuentes que impiden el 100\/100<\/h3>\n
                                        \n
                                      • Cargar varias familias tipogr\u00e1ficas con muchos pesos.<\/li>\n
                                      • Usar sliders pesados como elemento principal de la home.<\/li>\n
                                      • Lazy load aplicado a la imagen LCP.<\/li>\n
                                      • JavaScript de chat cargado antes del contenido principal.<\/li>\n
                                      • CSS de todo el sitio en cada p\u00e1gina.<\/li>\n
                                      • Plugins WordPress duplicados o abandonados.<\/li>\n
                                      • Im\u00e1genes subidas directamente desde c\u00e1mara o banco de im\u00e1genes sin redimensionar.<\/li>\n
                                      • No reservar espacio para banners, iframes o anuncios.<\/li>\n
                                      • Precargar demasiados recursos.<\/li>\n
                                      • Confundir puntuaci\u00f3n de laboratorio con experiencia real de usuarios.<\/li>\n<\/ul>\n<\/section>\n
                                        \n
                                        10. Checklist profesional de optimizaci\u00f3n HTML, CSS y JS \u2705<\/h2>\n
                                        HTML<\/h3>\n
                                          \n
                                        • DOM limpio, sin contenedores innecesarios.<\/li>\n
                                        • Contenido principal aparece temprano en el documento.<\/li>\n
                                        • Im\u00e1genes con width<\/code>, height<\/code> y atributos adecuados.<\/li>\n
                                        • Head sin scripts, metadatos o preloads obsoletos.<\/li>\n
                                        • Uso correcto de sem\u00e1ntica y accesibilidad.<\/li>\n<\/ul>\n
                                          CSS<\/h3>\n
                                            \n
                                          • CSS cr\u00edtico inline para above the fold cuando proceda.<\/li>\n
                                          • CSS no utilizado eliminado o reducido.<\/li>\n
                                          • Archivos minificados y comprimidos.<\/li>\n
                                          • Estilos divididos por plantilla o componente.<\/li>\n
                                          • Animaciones basadas en transform<\/code> y opacity<\/code>.<\/li>\n<\/ul>\n
                                            JavaScript<\/h3>\n
                                              \n
                                            • Scripts propios con defer<\/code> o m\u00f3dulos.<\/li>\n
                                            • Scripts independientes con async<\/code> cuando corresponda.<\/li>\n
                                            • Code splitting y carga condicional.<\/li>\n
                                            • Terceros retrasados, auditados y justificados.<\/li>\n
                                            • Tareas largas divididas para mejorar INP.<\/li>\n<\/ul>\n
                                              WordPress<\/h3>\n
                                                \n
                                              • Tema ligero o desarrollo a medida bien estructurado.<\/li>\n
                                              • Plugins auditados y sin duplicidades.<\/li>\n
                                              • Cach\u00e9 de p\u00e1gina activa.<\/li>\n
                                              • Assets descargados solo donde se usan.<\/li>\n
                                              • Base de datos revisada y PHP actualizado.<\/li>\n<\/ul>\n
                                                Recursos y servidor<\/h3>\n
                                                  \n
                                                • Im\u00e1genes WebP\/AVIF con tama\u00f1os responsivos.<\/li>\n
                                                • Fuentes WOFF2, pocas variantes y font-display<\/code> adecuado.<\/li>\n
                                                • Brotli o Gzip activo.<\/li>\n
                                                • Cabeceras de cach\u00e9 correctas.<\/li>\n
                                                • CDN configurado si el p\u00fablico es geogr\u00e1ficamente amplio.<\/li>\n<\/ul>\n<\/section>\n
                                                  \n
                                                  11. \u00bfCu\u00e1ndo no merece la pena perseguir el 100? \ud83e\udde0<\/h2>\n
                                                  Hay p\u00e1ginas donde lograr 100\/100 exige sacrificar funcionalidades valiosas: personalizaci\u00f3n, anal\u00edtica cr\u00edtica, pruebas A\/B, chat comercial, mapas interactivos, publicidad o componentes de aplicaci\u00f3n. En esos casos conviene pensar con madurez. Un 96 con buena conversi\u00f3n puede ser mejor que un 100 asc\u00e9tico que no vende, no mide y no ayuda.<\/p>\n
                                                  La ant\u00edtesis es clara: velocidad sin utilidad es vac\u00edo; utilidad sin velocidad es frustraci\u00f3n<\/strong>. La web excelente vive entre ambos extremos.<\/p>\n
                                                  Me viene a la cabeza una peque\u00f1a an\u00e9cdota. Hace a\u00f1os, en una cafeter\u00eda diminuta, vi a un barista preparar un espresso con una calma casi religiosa mientras la fila crec\u00eda hasta la puerta. El caf\u00e9 era magn\u00edfico. La espera, no tanto. Muchas webs hacen eso: entregan algo bueno demasiado tarde. Y en internet, la paciencia no se evapora lentamente; cae como una copa al suelo.<\/p>\n
                                                  Por eso, la pregunta no es solo \u201c\u00bfc\u00f3mo alcanzo 100\/100 en Google PageSpeed?\u201d. La pregunta m\u00e1s \u00fatil es: \u00bfqu\u00e9 necesita ver, sentir y hacer mi usuario en los primeros segundos?<\/strong> A partir de ah\u00ed, el c\u00f3digo se vuelve estrategia. HTML m\u00e1s claro. CSS menos obstructivo. JavaScript m\u00e1s humilde. Servidor m\u00e1s atento. WordPress m\u00e1s sobrio.<\/p>\n<\/section>\n
                                                  \n
                                                  12. Plan de acci\u00f3n de 7 d\u00edas para mejorar PageSpeed \ud83d\ude80<\/h2>\n\n\n\n\n\n\n\n\n\n\n\n
                                                  D\u00eda<\/th>\nAcci\u00f3n principal<\/th>\nResultado esperado<\/th>\n<\/tr>\n<\/thead>\n
                                                  D\u00eda 1<\/td>\nAuditor\u00eda completa con PageSpeed, Lighthouse, WebPageTest y DevTools.<\/td>\nLista priorizada de problemas reales.<\/td>\n<\/tr>\n
                                                  D\u00eda 2<\/td>\nOptimizaci\u00f3n de servidor, cach\u00e9, PHP, compresi\u00f3n y TTFB.<\/td>\nRespuesta inicial m\u00e1s r\u00e1pida.<\/td>\n<\/tr>\n
                                                  D\u00eda 3<\/td>\nOptimizaci\u00f3n de imagen LCP, preload y estructura HTML inicial.<\/td>\nMejor LCP y percepci\u00f3n de velocidad.<\/td>\n<\/tr>\n
                                                  D\u00eda 4<\/td>\nCSS cr\u00edtico, eliminaci\u00f3n de CSS no utilizado y carga por plantilla.<\/td>\nMenor bloqueo de renderizado.<\/td>\n<\/tr>\n
                                                  D\u00eda 5<\/td>\nJavaScript: defer, async, divisi\u00f3n, reducci\u00f3n de terceros.<\/td>\nMejor TBT, INP y respuesta de interacci\u00f3n.<\/td>\n<\/tr>\n
                                                  D\u00eda 6<\/td>\nFuentes, CLS, lazy loading correcto y limpieza del head.<\/td>\nM\u00e1s estabilidad visual y menos recursos innecesarios.<\/td>\n<\/tr>\n
                                                  D\u00eda 7<\/td>\nPruebas cruzadas, revisi\u00f3n en m\u00f3vil real, staging a producci\u00f3n y monitorizaci\u00f3n.<\/td>\nMejoras sostenibles sin romper funcionalidades.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
                                                  Despu\u00e9s, espera. Los datos de campo no cambian al instante. Google necesita recopilar informaci\u00f3n de usuarios reales durante d\u00edas o semanas. Lighthouse puede felicitarte hoy; CrUX tardar\u00e1 en asentir. La paciencia, por una vez, tambi\u00e9n forma parte de la optimizaci\u00f3n.<\/p>\n<\/section>\n
                                                    <\/main><\/p>\n
                                                  \n
                                                  La velocidad como forma de respeto \u26a1<\/h2>\n
                                                  Optimizar HTML, CSS y JavaScript para Google PageSpeed no consiste en obedecer ciegamente a una herramienta. Consiste en respetar el tiempo ajeno. En reducir ruido. En decidir qu\u00e9 merece cargarse ahora, qu\u00e9 puede esperar y qu\u00e9 nunca debi\u00f3 estar ah\u00ed.<\/p>\n
                                                  Un sitio r\u00e1pido parece sencillo, pero esa sencillez suele ser el resultado de muchas renuncias inteligentes. Menos adornos in\u00fatiles, m\u00e1s intenci\u00f3n. Menos c\u00f3digo por inercia, m\u00e1s arquitectura. Menos \u201cpor si acaso\u201d, m\u00e1s \u201cporque aporta\u201d.<\/p>\n
                                                  Si alcanzas el 100\/100, cel\u00e9bralo. Si te quedas en 92 pero tus Core Web Vitals son buenos, tus usuarios navegan fluidamente y tu negocio convierte mejor, cel\u00e9bralo tambi\u00e9n. La puntuaci\u00f3n es una br\u00fajula, no el territorio. Y el territorio, al final, siempre lo recorren personas.<\/p>\n<\/section>\n<\/article>\n","protected":false},"excerpt":{"rendered":"
                                                  \u00bfC\u00f3mo optimizar el c\u00f3digo HTML, CSS y JS para alcanzar un 100\/100 en Google PageSpeed?<\/p>\n","protected":false},"author":1,"featured_media":3863,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_seopress_titles_title":"","_seopress_titles_desc":"","_seopress_robots_index":"","_seopress_robots_follow":"","_seopress_robots_imageindex":"","_seopress_robots_snippet":"","_seopress_robots_primary_cat":"","_seopress_robots_breadcrumbs":"","_seopress_robots_freeze_modified_date":"","_seopress_robots_custom_modified_date":"","_seopress_robots_canonical":"","_seopress_social_fb_title":"","_seopress_social_fb_desc":"","_seopress_social_fb_img":"","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"","_seopress_social_twitter_desc":"","_seopress_social_twitter_img":"","_seopress_social_twitter_img_attachment_id":0,"_seopress_social_twitter_img_width":0,"_seopress_social_twitter_img_height":0,"_seopress_redirections_value":"","_seopress_redirections_enabled":"","_seopress_redirections_enabled_regex":"","_seopress_redirections_logged_status":"","_seopress_redirections_param":"","_seopress_redirections_type":0,"_seopress_analysis_target_kw":"","_seopress_news_disabled":"","_seopress_video_disabled":"","_seopress_video":[],"_seopress_pro_schemas_manual":[],"_seopress_pro_rich_snippets_disable_all":"","_seopress_pro_rich_snippets_disable":[],"_seopress_pro_schemas":[],"footnotes":""},"categories":[2],"tags":[],"class_list":["post-3864","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-mantenimiento"],"_links":{"self":[{"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/posts\/3864","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/comments?post=3864"}],"version-history":[{"count":1,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/posts\/3864\/revisions"}],"predecessor-version":[{"id":3865,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/posts\/3864\/revisions\/3865"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/media\/3863"}],"wp:attachment":[{"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/media?parent=3864"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/categories?post=3864"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/tags?post=3864"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}