interactuar con el DOM También usado del lado del servidor Desarrollado por Brendan Eich de NetScape (en 10 días) ⬡ Mocha -> LiveScript -> JavaScript ⬡ ⬡ ⬡ ⬡ * No tiene nada que ver con Java 5
en el server ⬡ En tu servidor tienes: A) HTML con el contenido ya generado (poco eficiente y cero escalable) B) Templates en los que hay variables que se rellenan de contenido y que cambian según cada ruta de la URL 14
= Single Page Application (no hay urls) • PWA = Progressive Web App (Es como una SPA pero con funcionalidades extra que imita a una app) • Otras opciones mixtas 20
estático con todo montado para el navegador • El servidor devuelve una serie de archivos de HTML y JS que después el navegador tendrá que procesar y “montar” 25
aquel proceso que tiene que ver con la accesibilidad del site y la obtención de información por parte de Googlebot. Multitud de procesos destinados a la comprensión del lenguaje, cálculos de relevancia, renderización de componentes y otros temas. Algoritmos encargados de procesar la “query” y cruzar los datos del índice (índex) con tal de devolver los resultados más relevantes. 36
- Duplicidad - Internacionalización - Tasa de actualización - … Similar al índice de las últimas páginas de un libro: una entrada para cada palabra de cada página web que se indexa.
versión disponible de Chromium • Googlebot renderiza con Chrome/Chromium • Soporta: ◦ ES6 y otras funcionalidades de JS ◦ IntersectionObserver para lazy load ◦ V1 APIs para Componentes Web 48
cliente • El HTML viene vacío o con la estructura básica y se rellena en el navegador • Es la configuración más costosa para Google (y la que suele dar más problemas) 70
extra que crea todo el HTML final evitando ese trabajo al navegador • Se manda un archivo totalmente estático • La opción preferida de Google, la menos costosa para ellos (y la que mejor suele funcionar) 72
Mayor coste para el servidor • Necesidad de cacheado por componentes • Más amigable con los motores de búsqueda • Más rápido en server pero más lento en cliente • Dispositivos con poca potencia tendrán muchas dificultades • Nada amigable con los motores de búsquedas 74
sólo la más crítica o la más reutilizable • A través de la “rehidratación” rellenan los huecos con JS usando el DOM pre-cargado en servidor • Se pueden realizar customizaciones para adaptar elementos CSR + SSR 82
páginas • Si usamos CSR, muchos se descubrirán en la segunda ola de indexación • Depende cómo estemos “mostrando” esos links los tendrá en cuenta o no en el cálculo del link graph 87
<a href=”javascript:void(0)”>nope, falta enlace</a> <span onclick=”goTo(‘page’)”>no es el elemento HTML adecuado</span> <option value="page">no, elemento HTML erroneo</option> <a href=”#”>no hay enlace</a> 89
su ruta son la misma URL para Google ◦ ejemplo.com/#category • La URL debe estar en un <a> con un href sin el hash (y por nuestro lado debemos implementar la lógica para mandar al usuario a otra página) 91
estatus HTTP 200 ok • Una página de destino de una redirección que no tenga que ver con la página origen • Páginas sin rellenar o apenas con contenido 100
el primer error (página de error cargada en cliente pero con un código 200 desde server) • ¿Cómo se soluciona? ◦ Redirect a una página de error tipo: /not-found (y devolviendo 404 o 410) ◦ Añadir un noindex 101