La siguiente función en PHP te permite obtener el tiempo estimado de lectura de un texto.
Copy
<?php/*** Get the estimated reading time in minutes.** @paramstring $content The post content.* @paramint $wpm Words per minute. Default to 250.* @returnfalse|float Reading time in minutes.*/functionget_estimated_reading_time($content, $wpm =250) { $content =strip_tags($content); $word_count =str_word_count($content);returnceil($word_count / $wpm);}
A partir de aquí te explico sobre la función, así que si solo llegaste por el código es tu momento para copiar el código y seguir programando.
Tiempo estimado de lectura en PHP
Para que la función cumpla su cometido necesitamos dos cosas, el contenido y la cantidad de palabras leídas por minuto.
El contenido es el texto al cual tenemos que calcular el tiempo estimado de lectura. Por otra parte, la cantidad de palabras leídas por minuto es la clave para obtener el tiempo estimado de lectura.
Sabiendo esto, nuestro valor por default para el tiempo estimado de lectura o $wpm es de 250.
A continuación te muestro una prueba de la función en PHPSandbox.io. Da click en el botón Run para ejecutar el script.
La función usa strip_tags() para eliminar todas las etiquetas HTML y PHP de un string. Ninguna etiqueta HTML o PHP es necesaria para el cálculo, solo necesitamos el texto.
También se usa la str_word_count() para devolver la cantidad de palabras en un texto. El valor devuelto servirá para calcular el tiempo de lectura estimado y el resultado será guardado en la variable $word_count.
Al final, hay que dividir la cantidad de palabras, $word_count, y la cantidad de palabras leídas por minuto, $wpm.
El resultado de la división anterior la pasaremos dentro de la función ceil(). Así podemos enviar el resultado al usuario con un valor redondeado.
Si necesitas reducir o incrementar el valor de las palabras leídas por minuto, puedes especificarlo desde la llamada de la función en el segundo parámetro, por ejemplo:
Copy
get_estimated_reading_time($content, 300);
Tiempo estimado de lectura en WordPress
También puedes implementar el tiempo estimado de lectura en WordPress, tal como al principio de este y cualquier post de mi blog.
Como la función es para WordPress, no olvides agregar un prefijo a la función. Y si estás desarrollando un plugin para WordPress, aquí te dejo una lista sobre cómo desarrollarlos.
He estado estudiando sobre el pensamiento crítico y solución de problemas para así aplicarlo en mi vida y en el desarrollo de software que realizo en mi trabajo.
Se me hizo interesante y fácil de entender gracias al material visual y los ejemplos que aparecen en el video.
Básicamente, del tema que quieres estudiar o de un proyecto que quieres implementar, aplica los cinco puntos que mencionan en el video:
Formula preguntas.
Recolecta información.
Aplica la información.
Considera las implicaciones.
Explora otros puntos de vista.
Este video me hizo recordar la experiencia que tuve al querer cambiar una funcionalidad de un proyecto que había desarrollado sin aplicar pensamiento crítico.
El proyecto, mi propuesta y ¿por qué falló?
Una de las funcionalidades del proyecto del que hablo hace aparecer una ventana emergente o popup, para promocionar un servicio, en la página web después de cierto tiempo.
Mi propuesta de cambio comenzó cuando leí el sitio web MODALZ MODALZ MODALZ. El sitio web te explica el por qué no deberías usar ventanas modales y te da alternativas, como un toast o poner el producto a promocionar dentro del contenido.
Se me prendió el foco, me pregunté y dije:
Oye, ¿no crees que la ventana modal actual es algo entrometida? Tal vez si se cambia a un CTA flotante en la parte de abajo de la página, no interrumpa la lectura del visitante.
Me dejé llevar por la información de ese sitio web. No apliqué pensamiento crítico y mandé la propuesta al equipo.
Mi propuesta era convertir la ventana modal a un tipo de “CTA” flotante en la parte de abajo de la página web.
En mi mente, la ventana modal interrumpía la lectura del usuario. Y tal vez sí. Así que mi propuesta de cambio parecía ser la solución.
De nuevo, ésta solución era magnífica en mi mente.
Al final, la propuesta no pasó por dos razones:
Al usuario, realmente, no le afecta la ventana modal.
Mi propuesta reduce la importancia del servicio promocionado.
Si hubiese aplicado el pensamiento crítico, le hubiese ahorrado tiempo cognitivo al equipo de trabajo.
Pensamiento crítico
Si no me hubiese emocionado con el cambio y hubiese aplicado el pensamiento crítico, tal vez mi propuesta tendría más peso y confianza para aplicarse en el proyecto.
¿O tal vez no?
Veamos cómo hubiese sido el aplicar el pensamiento crítico, en mi propuesta, con los cinco puntos mencionados en el video.
Cabe destacar que el pensamiento crítico que te presento aquí es de mi propia autoría. Y tal vez sea muy diferente a tu criterio.
Recordemos que mi propuesta es convertir la ventana modal a un tipo de “CTA” flotante en la parte de abajo de la página web para no interrumpir la lectura del visitante.
Formula preguntas
Cuestiona todo. Pregunta sobre lo que quieres aprender o lo que no entiendes. Dicen por ahí que, ignorante es el que no pregunta.
Formulamos las siguientes preguntas:
¿La ventana modal es molesto para el usuario si aparece de la nada?
¿El usuario se sale de la página cuando aparece la ventana modal?
¿El usuario cierra la ventana modal y continúa su lectura?
¿El usuario le da click al botón del CTA en la ventana modal?
Recolecta información
Hay que documentarse. Obtén toda la información que puedas para dar una respuesta lógica a nuestras preguntas.
Nuestra mayor fuente de información será Hotjar. Esta es una plataforma para ver el comportamiento de los usuarios en el sitio web.
Observa el comportamiento de múltiples usuarios cuando la ventana modal aparezca. No olvides anotar lo que observas en los videos, los enlaces a esas grabaciones, el timestamp de los videos e incluso exportar la información a un Excel.
Además, el sitio web MODALZ MODALZ MODALZ nos da información sobre el cambio que queremos hacer.
Y no olvides preguntar a tu equipo de trabajo su postura actual sobre la ventana modal. Más sobre esto en el último punto.
Aplica la información
Lee e interpreta detenidamente la información recolectada. Esta te ayudará a tomar una decisión que sea lógica.
Observé el comportamiento de los usuarios en más de 10 grabaciones. ¿Y qué hicieron? El 100% cerró la ventana modal y siguió navegando el sitio web.
Por otra parte, mi equipo de trabajo mencionó que hacían lo mismo que los usuarios de las grabaciones. Cierran la ventana modal y siguen en el sitio web.
También mencionaron que cambiar la ventana modal por un CTA flotante le quitaría importancia al servicio ofrecido. ¿Interesante verdad? Jamás pensé en eso.
No creo. En mi opinión, MODALZ ofrece buenas alternativas pero dependerá de los requerimientos de tu negocio, sitio web y el comportamiento de tus usuarios para poder implementarlas.
El saber toda esta información me dice que mi propuesta de cambio no es necesaria en el proyecto.
Considera las implicaciones
¿Qué pasaría si…? Ten en cuenta en qué sucederá si aplicas tus decisiones.
Si el equipo y yo hubiésemos aprobado el cambio propuesto en el sitio web, podemos imaginar dos posible escenarios. Uno positivo y otro negativo.
Por lo que veo, el único escenario positivo que veo es que los usuarios no se serían interrumpidos al ver el CTA flotante en la parte de abajo. No interrumpe el flujo de lectura.
Sin embargo, conforme a la información recolectada en el paso 2, sabemos que al usuario, en realidad, no le molesta la ventana modal.
Por lo tanto, el escenario negativo sería que el CTA flotante, si se llegase a aplicar, no tendría el mismo impacto que la ventana modal. Es decir, menos interacción y menos ingresos monetarios.
Explora otros puntos de vista
La opinión y conocimiento de otras personas te hacen ver las cosas de una manera distinta.
Este punto te hace reflexionar bastante. De vez en cuando te hace salir de tu zona de confort e incluso ponerte los pies en la tierra.
En una de las reuniones uno a uno con mi jefe, le pregunté su opinión sobre la propuesta de cambio que había realizado en la semana.
Él comentó que para empezar, él ya estaba acostumbrado a las ventanas modales, él solo cierra y continúa con la navegación.
Por otra parte, él sentía que si usábamos un CTA flotante en la parte de abajo, el servicio que se está promocionando tendría menos importancia que usándolo en la ventana modal.
¡En ese momento me estalló la cabeza!
Su primer comentario es muy acertado y es validado con la información del paso 2.
Mientras que su siguiente comentario, tiene sentido común, tan común que ni se me ocurrió pensar tal cosa…El CTA flotante, en la parte de abajo, se verá menos y no generará el impacto requerido en el usuario y, por lo tanto, menos ingresos para el negocio.
El chiste de este punto es ir con la mente abierta a nuevas ideas y experiencias para así poder aprender y crecer.
Conclusiones
Gracias al pensamiento crítico, he aprendido que experiencias como la que acabo de redactar, entre muchas otras, me ha permitido mejorar tanto a nivel personal como profesional.
Aplicar los cinco puntos del video sobre el pensamiento crítico, ya sea en la vida diaria o en el trabajo, no es sencillo, pero mejora con la práctica constante.
Habrá momentos en que tomemos decisiones sin realizar un análisis profundo, tal vez porque la situación lo permita o porque no tenemos la motivación en ese instante, y eso está bien. Puedes corregir y ajustar sobre la marcha, como lo hice con mi propuesta de cambio.
Lo importante es no quedarse estancado. Analiza lo que hiciste, y lo que no, aplicando el pensamiento crítico. Solo así mejorarás tu proceso de trabajo y aprendizaje, con eso tu vida personal y profesional crecerán exponencialmente.
Con el nuevo servicio Cloudflare Browser Rendering se abren más posibilidades de usar Puppeteer en los servidores de Cloudflare y sin mucha configuración de por medio.
Cloudflare Browser Rendering usa Puppeteer. Esta es una librería en JavaScript que ejecuta una instancia de Google Chrome permitiendo realizar varias interacciones, por ejemplo, de un sitio web podrás generar PDFs, tomar capturas de pantalla, obtener datos e incluso modificar el DOM.
Uno de los proyectos de la empresa donde trabajo es tomar captura de pantallas de los resultados de Google (SERP), específicamente donde los resultados de la web de la empresa aparezcan. Así que, ese proyecto cayó en buen momento para probar Cloudflare Browser Rendering.
En este post te enseñaré a cómo sacar una captura de pantalla a la primera página de resultados de Google usando Cloudflare Browser Rendering.
Cloudflare Browser Rendering
Este es un producto de Cloudflare que permite ejecutar Puppeteer en los servidores de Cloudflare.
Funciona bajo la plataforma de Cloudflare Workers y está desarrollado para que los desarrolladores solo se enfoquen en desarrollar sus aplicaciones, así que no necesitas configurar nada relacionado con Puppeteer.
Cloudflare Browser Rendering está disponible para usuarios que pagen el servicio de Workers y el precio que pagarás será de acuerdo al consumo de memoria y CPU de tu aplicación.
Proyecto: Captura de pantalla a la primera página de los resultados de Google
Aunque, por este medio, no puedo compartir el código desarrollado en la empresa donde trabajo, si puedo mostrarte cómo implementar Cloudflare Browser Rendering usando nuestro propio proyecto.
Vamos a desarrollar una aplicación de Cloudflare Workers que tome captura de pantalla a la primera página de los resultados de Google usando Cloudflare Browser Rendering.
La lógica del proyecto es la siguiente:
La aplicación se ejecuta haciendo un HTTP GET.
Agregamos el parámetro keyword al enlace que nos dará nuestro Worker.
Aplicar validaciones necesarias.
Si hay algún error, enviar una respuesta JSON.
Iniciar Puppeteer, entrar a la página de Google con la palabra clave indicada.
Tomar la captura de pantalla.
Mostrar la captura de pantalla al navegador del usuario.
Requisitos
Los siguientes requisitos nos ayudarán a desarrollar nuestra aplicación:
Tener instalado Node.js (versión 16.13.0 o mayor).
Desarrollo del proyecto
1. Crea un Cloudflare Worker
En si, todo el proyecto es un Cloudflare Worker. Un Worker es un sistema serverless, es decir, ejecutas tu código en un servidor en la nube con cero configuración en la infraestructura.
Ejecuta el siguiente comando y contesta las preguntas que aparecerán en la terminal. El proyecto puedes llamarlo browser-rendering:
Copy
npmcreatecloudflare@latest
Si estás en Windows, ejecuta el comando usando la Windows PowerShell en modo administrador para responder las preguntas en la terminal.
Si te pregunta qué tipo de aplicación deseas crear, escoge la opción “Hello World” Worker. Además, te preguntará si usarás JavaScript o TypeScript. En nuestro caso, usaremos JavaScript.
2. Instala Puppeteer
Dentro de tu proyecto browser-rendering, instala el Puppeteer de Cloudflare. Así es, Cloudflare ha hecho un fork de la librería Puppeteer y le aplicaron algunos cambios para hacerlo funcionar con Workers.
Copy
npminstall@cloudflare/puppeteer--save-dev
3. Configura tu archivo Wrangler
Un proyecto de Cloudflare Worker siempre tiene su archivo wrangler.toml, este archivo sirve para configurar tu proyecto con los productos de Cloudflare.
El archivo wrangler.toml está compuesto por el nombre de variables y sus valores. En este archivo todo es importante porque declaramos valores para que nuestro proyecto sea compatible con Node.js, desde donde se ejecuta nuestro proyecto y más.
Ahora, la variable browser contiene el binding con su valor MYBROWSER. Este binding establecerá la conexión entre nuestro Worker con el Chrome ejecutado desde Cloudflare.
El valor del binding puede ser cualquiera de tu preferencia. En este proyecto usaremos MYBROWSER.
Algo que no mencionan al configurar el wrangler.toml, es la variable account_id. Aunque esta variable es opcional, por alguna razón cuando ejecutaba el Worker me pedía que ingresara el account_id. Esta nos permite interactuar directamente con la zona de Cloudflare donde ejecutaremos nuestro Worker.
Puedes ver más configuraciones del archivo wrangler.toml en este enlace.
4. El código
Una vez configurado el archivo wrangler.toml ya podemos empezar a desarrollar nuestra aplicación que tomará capturas de pantalla a un sitio web. El código JavaScript es el siguiente:
Copy
import puppeteer from"@cloudflare/puppeteer";/** * Send error response. * * @since 1.0.0 * * @param{string}message The error message. * @param{int}status The status code. * @returns{Response} The response. */functionsendError(message, status=400) {constjson= { message, success: false, };returnnewResponse(JSON.stringify(json), { status, headers: { 'content-type': 'application/json;charset=UTF-8' }, });}/** * Get the Google URL. * * @since 1.0.0 * * @param{string}keyword The keyword. * @returns{string} The Google URL. */functiongetGoogleUrl(keyword) {constparams= { q: keyword, gl: 'us', hl: 'en', };consturlSearchParams=newURLSearchParams(params);return`https://www.google.com/search?${urlSearchParams}`;}exportdefault {/** * Fetch the SERP screenshot. * * @since 1.0.0 * * @param{object}request The request. * @param{object}env The environment variables. * @returns{Promise<Response>} The response. */asyncfetch(request, env) {if (request.method !=='GET') {returnsendError('Method not allowed.', 405); }const { searchParams } =newURL(request.url);let keyword = searchParams.get('keyword');if (!keyword) {returnsendError('You need to specify a keyword.'); }try {constbrowser=await puppeteer.launch(env.MYBROWSER);constpage=await browser.newPage();await page.goto(getGoogleUrl(keyword), { waitUntil: 'load' });constscreenshot=await page.screenshot();await browser.close();returnnewResponse(screenshot, { headers: {'content-type': 'image/png', } }); } catch (e) {returnsendError(e.message); } }}
La función sendError la ejecutamos cuando hay algún tipo de error en nuestras validaciones o cuando Puppeteer arrojó algún otro tipo de error. Por otra parte, obtendremos el enlace de Google para buscar nuestra palabra clave con la función getGoogleUrl.
Y dentro de la función fetch se ejecutará la funcionalidad de Puppeteer. Dentro de esta función ejecutamos validaciones al principio:
Solo debemos aceptar peticiones HTTP GET.
La variable keyword debe existir.
Ahora, la parte que ejecuta la funcionalidad de Puppeteer, preferentemente, debe estar encerrado dentro de un try/catch, para que podamos detectar cualquier error lanzado por Puppeteer.
Y acá viene lo más importante, la constante browser contiene la instancia de Chrome, la cual usaremos para abrir nuevas ventanas y cerrar la conexión. Pero, ¿ya notaste que la función puppeteer.launch() tiene un parámetro?
Dentro de la función puppeteer.launch() ponemos el binding que hemos configurado en nuestro archivo wrangler.toml.
Copy
browser = { binding = "MYBROWSER" }
Esto permitirá la comunicación entre nuestro Worker y Chrome. Después de establecer la comunicación, ahora podemos tomar capturas de pantalla y más.
¡No olvides cerrar la conexión del navegador! Aunque si tu instancia (Chrome) no recibe algún comando durante 60 segundos entonces se cierra automáticamente.
Cloudflare Wrangler nos provee de un comando para ejecutar y probar nuestra aplicación:
Copy
wranglerdev--remote
El comando tiene que ejecutarse dentro de tu proyecto, desde la consola de comandos, con la opción —-remote para que se conecte con los servidores de Cloudflare y ejecute la instancia de Chrome.
Abre el localhost junto con el puerto que te ha dado el output del comando y abrelo en el navegador, por ejemplo:
Copy
http://localhost:8787/?keyword=roel%20magdaleno
Verás la imagen en tu navegador en aproximadamente 6 segundos:
Lo que he notado al usar el Cloudflare Browser Rendering es que tarda alrededor de 2 o 3 segundos en abrir la instancia de Chrome y otros 3 segundos para abrir una ventana y realizar la búsqueda.
Si tu objetivo es buscar múltiples palabras claves, entonces agrega un bucle en tu código para que busque en una sola instancia de Chrome.
6. Sube la aplicación a Cloudflare Workers
Ahora, si deseas subir la aplicación a tu cuenta Cloudflare, solo tienes que ejecutar el siguiente comando:
Copy
wranglerdeploy
En la terminal verás el enlace generado por el comando y luce así:
Este enlace será el que usaremos para tomar las capturas de pantalla en producción.
¡Y listo! Has desarrollado un Cloudflare Worker que toma capturas de pantallas de un sitio web, sin embargo, como ya sabes, también puedes generar archivos PDF. ¿Cómo usarás esta herramienta?
¿Problemas con el Buffer de Node.js?
Este problema ya ha sido solucionado en nuevas versiones del Cloudflare Browser Rendering pero si por alguna razón te sale un error con el Buffer, quiere decir que la librería de Puppeteer no está detectando esa funcionalidad de Node.js.
Por suerte, alguien en el Discord de Cloudflare sugirió aplicar la siguiente solución:
Declaramos el Buffer justo antes de puppeteer y lo registramos en el globalThis de nuestra aplicación. Reiniciamos la aplicación y debe funcionar perfecto.
De acuerdo al diagrama de flujo anterior, te explicaré cuáles son las tecnologías que hay detrás de Unserialize.dev:
PHP/WordPress
Utilizo WordPress como backend. He creado un plugin para WordPress que registra una ruta API en este sitio web. Cuando se le envían los datos, los valida y si todo sale bien, procede a ejecutar la función unserialize() de PHP. Al final, hace el formateado para JSON o Array y retorna la respuesta al cliente.
Vue/Nuxt
Toda la interacción del usuario con el cliente está desarrollado con el framework Nuxt con las siguientes dependencias:
Utilizo Cloudflare Pages para hostear la aplicación Nuxt de forma gratuita. Simplemente tengo mi código en GitHub, hago algún deploy a la rama main y el sitio se actualiza por si solo.
Supabase
Para guardar las respuestas en una base de datos quise probar Supabase, ya que todo mundo hablaba bastante bien sobre él. Y la verdad es que concuerdo, debido a su simple integración con las aplicaciones.
Tailwind CSS
Para los estilos utilizo Tailwind CSS y Tailwind UI. No hay más que agregar, me gusta para sacar prototipos rápidos.
Syntax Highlighting
Como puedes ver, la respuesta JSON se ve bien formateada gracias a Torchlight, la cual es una API donde envías código y te retorna un bloque de código formateado correctamente. Es gratuito para proyectos open source.
Gracias
Gracias por llegar hasta aquí.
Este proyecto fue divertido, soluciona varios problemas que encontraba en otras aplicaciones web. Además, siempre es bueno probar nuevas herramientas, aporta más conocimiento.
Espero que esta herramienta te pueda servir también.
En este post hablaremos sobre event delegation, en JavaScript. La solución a tus problemas de performance y escalabilidad en tu proyecto actual, donde tal vez tengas una tabla de usuarios.
Cada usuario tiene los botones de editar o eliminar. Sin embargo, estás haciendo un loop para asignarles un evento click para hacer sus respectivas funciones.
Esto soluciona tu requerimiento, pero, si tienes más de 1000 usuarios en esa tabla, ¿será bueno en performance? y mejor aún, ¿será escalable?
¿Qué es event delegation?
El event delegation es un patrón en JavaScript que sugiere registrar un evento, por ejemplo, click, en nuestro document para interceptar todas las interacciones de nuestro documento.
Es decir, si haces click en un botón, lo estás escuchando, y si haces click fuera del botón, también lo estás escuchando.
¿Suena ilógico no? ¿Por qué queremos escuchar todos los clicks de todo nuestro sitio web si solo podemos asignarle el evento a los elementos a través de un loop?
Lo mismo pensé cuando escuché sobre esto la primera vez, pero cuando piensas en el performance y escalabilidad, empieza a cobrar sentido.
¿Cómo funciona event delegation?
El truco está en que dentro de la función callback de nuestro evento, hay que usar el objeto event.target.
En nuestro ejemplo, event.target es equivalente al elemento que hemos hecho click, el botón, en este caso.
Por otra parte, si haces click afuera del botón, el evento también se ejecutará. Es ahí donde tienes que agregar las condiciones necesarias para que el evento solo responda a los botones y no a todo el contenido del sitio.
Funciones como matches() o closest() se usan mucho cuando se está trabajando con event delegation.
Antes de event delegation, se usaba un loop
Retomemos el ejemplo del primer párrafo. Tenemos la tabla de 1000 usuarios, y cada uno de ellos tiene un botón para editar; digamos que al hacer click a ese botón, se abre un modal con los datos del usuario para editar.
Lo que yo solía hacer para abrir ese modal, es agregar un evento click a cada uno de los botones con la siguiente lógica:
Obtener los botones.
Pasar por un loop los botones.
Asignar un evento a cada uno de los botones pasados en el loop.
Observa el siguiente demo. Utilizo un forEach para hacer un loop de los elementos y asignarles el evento; también puedes usar for y for ... in. La funcionalidad es la misma.
Si bien el código anterior funciona. ¿Qué es lo que lo hace incorrecto?
Problema #1: Performance
El performance es algo que debes incluir en tus desarrollos web. Es muy medido por Google y sus Core Web Vitals, además, un buen performance asegura una mejor experiencia para el usuario.
Si tenemos 1000 usuarios y por cada uno podría haber dos botones, editar y eliminar, eso hace que nuestro sistema tenga 2 mil botones en total. Imagina agregar otro botón más.
Ahora, con nuestro sistema actual tendría que hacer loop y agregar los eventos a esos 2 mil botones; y eso, no es para nada saludable para el sitio y navegador web. ¿Diría que incluso podría saturar el navegador?
Tu cliente quiere agregar usuarios en esa misma tabla usando AJAX. Se puede, sí; sin embargo, ¿nuestros botones de editar funcionarán después de agregar al usuario?
Seguramente no funcionará porque, previamente, has agregado los eventos a los botones existentes, no a los nuevos.
Uno piensa, ¡ah! pues después de crear el usuario, busco los nuevos botones y les asigno el evento. Si y no. Esto solo genera complejidad y duplicidad de código. No es escalable.
Conclusión
Debemos acostumbrarnos al uso del event delegation, pero siempre analiza si este tipo de patrón es el adecuado para los requerimientos de tu proyecto.
Ya no podemos usar las viejas formas en las que programábamos con JavaScript. Tenemos que actualizar nuestro código para hacer el uso de la web más satisfactoria para los usuarios.
En nuestro post “Prueba tus WordPress Plugins con PHPUnit en Local” configuramos PHPUnit junto con Local para después hacer pruebas a nuestros plugins. Es una buena forma para mantener nuestro código a prueba de errores, entre otros beneficios.
Cuando estamos desarrollando nuestros plugins para WordPress, lo último que se nos viene a la mente es, probarlos. Y con probarlos me refiero a integrar PHPUnit y crear pruebas para confirmar que nuestro plugin para WordPress funciona.
¿No te gustó el botón “Empezar” en el Messenger Bot de tu página? Al parecer a muchas personas no les agradó y mostraron su inconformidad en este post. Desconozco el motivo, pero supongo que el “botón” en vez de ayudar, estorba.
Tener el botón de “Empezar” es un proceso más para el usuario para ponerse en contacto contigo y tu página. ¿Es mucho mejor que el usuario te contacte sin hacer click en un botón, no?
La petición
Antes de realizar la petición, debes tener tu page_access_token, una cadena de caracteres que sirve para autenticar nuestra petición.
Para eliminar el botón “Empezar” de tu Messenger, solo necesitas mandar una petición DELETE a los servidores de Facebook. Será algo similar a lo que hicimos en el post: Agrega el botón “Empezar” en tu Messenger Bot.
Tenemos que enviar una petición al siguiente enlace (<PAGE_ACCESS_TOKEN> será sustituido por tu page access token generado por Facebook):
De la petición anterior, nota que dentro del parámetro fields existe la palabra get_started. Significa que lo que vas a eliminar de tu página de Facebook será el botón de “Empezar”.
Existen más fields que puedes eliminar de tu página de Facebook como greeting, persistent_menu, entre otros.
Resultados del Messenger Bot
Después de hacer la petición, y si todo sale bien, deberás obtener la siguiente respuesta:
Copy
{ "result": "success" }
Ahora, puedes ir al Messenger de tu página y el botón “Empezar” se habrá ido:
Cuando estamos desarrollando un sitio web, ya sea con WordPress o una página web sencilla es clásico cargar todo nuestro código PHP, JavaScript y CSS a la vez en todas las páginas del sitio web.
Como la mayoría de los sitios web están construidos en WordPress, es donde nos enfocaremos ya que muchos desarrolladores desarrollan temas y/o plugins para esta plataforma y no siempre piensan en el performance de su código.
¿En qué afecta cargar código innecesario?
Bien, cuando ejecutas código PHP, JavaScript y CSS en una página estás usando CPU, memoria RAM, entre otros recursos de tu servidor y al final eso se traduce en un costo monetario para tu cliente.
Entre más recursos ocupes, tu sitio web podría presentar estos problemas:
La carga de tu sitio web será muy lenta (A no ser que tu servidor sea escalable y esté bien configurado).
Perderás usuarios y dinero si tu sitio web es lento.
Para servidores en la nube no bien administrados, puede generar un costo alto.
WordPress siempre cargará los archivos PHP, CSS y JavaScript del tema y plugins activos, así que entre más plugins activos tengas, más recursos usará tu servidor.
Identifica JavaScript y CSS innecesarios
Un código innecesario puede existir en un archivo de PHP, JavaScript y CSS, y podemos identificarlo de las siguientes formas:
Network
Firefox y Google Chrome (u otro navegador) tienen una opción llamada Network o Red donde puedes ver los archivos JavaScript y CSS cargados en la página que estás visitando actualmente.
Pestaña de Network o Red mostrando los archivos JS y CSS cargados en la página actual.
¿Ves un archivo que no pertenece a la página actual que estás visitando? Probablemente no está siendo cargado adecuadamente.
Coverage
Google Chrome tiene una opción llamada Coverage la cual permite encontrar el código JavaScript y CSS usado y no usado en la página que quieras analizar.
¿No sabes cómo usar el Coverage? He creado un video sobre cómo utilizar el Coverage en Google Chrome:
WebPageTest
Este servicio para analizar el performance de tu sitio web hace algo similar que la opción Network, te mostrará los recursos cargados desde que inicia y termina tu sitio web.
WebPageTest mostrando los recursos cargados en la página actual.
¿Cómo cargar mal un recurso?
Los archivos CSS y JavaScript comúnmente son cargados usando las funciones wp_enqueue_style() y wp_enqueue_script(); mientras que un código PHP se puede ejecutar dentro de action y filter hooks y en el dashboard de WordPress o en el frontend.
Un ejemplo es el siguiente código, donde estamos cargando el script wp-countup-show-counter.min.js en el frontend:
El problema del código es que está cargando el script en todas las páginas de tu sitio web pero tu sólo estás usando el script, digamos que, en la página /contact. ¿No tiene sentido que cargues tu script en todas las páginas, verdad?
¿Cómo cargar bien un recurso?
Retomando el ejemplo anterior, queremos que el script wp-countup-show-counter.min.js solo se ejecute en la página /contact. Para eso solo tenemos que agregar una condición de guardia donde si la página actual no es /contact entonces no cargues el script:
Pueden existir múltiples condiciones para cargar un script o estilo, en el ejemplo anterior utilizamos una página como condición pero también puedes usar:
Ya que hayas identificado el código innecesario en tu WordPress, es hora de desactivarlos. Para eso, WordPress te provee dos funciones wp_dequeue_script() y wp_dequeue_style() para desactivar los scripts y estilos registrados.
Esta sección merece su propio post y lo puedes leer en el siguiente enlace.
Y ten en cuenta que lo explicado en este post lo puedes aplicar para cualquier sitio web, incluso si no está hecho en WordPress.
Espero hayas aprendido y apliques los conocimientos que aquí he plasmado, si lo haces, podrás darle a tus sitios web más performance para que tus usuarios tengan una buena experiencia.
Si tienes alguna duda y/o comentario puedes dejarlo en los comentarios.