Proporcionando un trabajo rápido en el sitio como parte de la tubería de desarrollo

El rendimiento del sitio web no se trata solo de hacer que las páginas del sitio web se carguen más rápido. También es necesario transmitir la importancia de recursos web efectivos a los desarrolladores y otros participantes del proyecto. El rendimiento es la misma parte de la funcionalidad que todo lo demás, por lo tanto, su implementación no puede posponerse "algún día".



El tema del rendimiento me interesa desde hace mucho tiempo. Recuerdo que todo comenzó por conocer los algoritmos "codicioso" y "divide y vencerás". Había algo particularmente agradable en tomar el código que tardó varios minutos en completarse, rehacerlo y lograr que completara la tarea en un par de segundos.

Si hablamos de redes, entonces los problemas de rendimiento son diferentes: por lo general, no es la complejidad computacional, sino realizar las acciones necesarias en el momento adecuado de la mejor manera. A primera vista, esta tarea puede parecer elemental, pero de hecho es mucho más complicada.

Traducido a Alconost

Steve Suders fue uno de los primeros interesados ​​en analizar cómo los navegadores solicitan recursos web y esperan una respuesta: qué recursos bloquean el trabajo, cuáles pueden posponerse, ¿qué sucede con los encabezados de respuesta? Basado en los resultados de su investigación, hizo una lista de 14 reglas para cargar rápidamente un sitio web . Por ejemplo, estas son las reglas de rendimiento que se aplican en la herramienta YSlow (es posible que ya esté familiarizado con ella) .


14 reglas de Steve Suders ( fuente )

Hoy en día, hay cada vez más herramientas nuevas para controlar la productividad: algunas deben lanzarse por separado, mientras que otras están integradas en la tubería de desarrollo e implementación. Uno de ellos es el Faro de Google: muestra datos sobre indicadores PWA (aplicaciones web progresivas), SEO, etc.


Captura de pantalla de Lighthouse 3.0 mostrada en la conferencia Google I / O 2018 ( fuente )

Dichas herramientas ayudan a determinar a qué prestar especial atención al finalizar el sitio y, al mismo tiempo, han implementado muchos conceptos, entre los cuales no es tan fácil de entender: PRPL, RAIL, Paint Timing API, TTI, HTTP / 2, Índice de velocidad, sugerencias de prioridad y más ...

¿Por qué el rendimiento está detrás de escena?

La cuestión de la capacidad de respuesta de los sitios web es un problema grave en una variedad de empresas. Tenemos excelentes herramientas y guías claras, pero pocas personas dedican tiempo a mejorar la productividad. Es decir, el punto no es que no sepamos por qué los sitios se están cargando durante tanto tiempo.

Por lo tanto, no estoy tratando de explicar por qué el rendimiento del sitio web es importante.

Otros recursos hablan de esto mucho mejor, con números reales para proyectos reales. Quiero hablar sobre la cultura del desarrollo y cómo define las prioridades . Solo percibiendo la productividad como otra "función" del proyecto, aprendemos a prestarle atención.

Si lee esto, lo más probable es que sea un desarrollador, intente mantenerse al tanto de las nuevas tecnologías de Internet y no sea indiferente a la productividad. Si pregunta dónde trabaja y qué hace, puede resultar que pertenece al departamento de desarrollo de alguna empresa, y una de sus tareas es garantizar la productividad. Pero lo más probable es que no se pueda decir lo mismo del resto de los empleados del departamento y de la compañía en general , a menos que, por supuesto, trabaje de manera independiente. Y esto es normal: es imposible saberlo todo sobre todo.

Al resolver tareas cotidianas, debe trabajar en muchas áreas técnicas: desarrollar nuevas funciones, interactuar con otros departamentos (agregar scripts para análisis, publicidad, remarketing, pruebas A / B), organizar la integración y entrega continua (CI / CD), garantizar la seguridad, cree una interfaz agradable y fácil de usar. ¡Pero aún debes cubrir la parte trasera con pruebas!

A menudo es casi imposible prestar atención a otra cosa: el tiempo es limitado y el volumen de trabajo pendiente tiende a crecer. Por lo tanto, debes priorizar.



La priorización debe basarse objetivamente en una hipótesis medible. Por ejemplo: "Creemos que con la implementación de la función X, la retención de usuarios aumentará en un Y%", sin embargo, en la práctica esto parece mucho más complicado. Eche un vistazo a las tareas con las que tenemos que lidiar y preste atención a quién las establece:

• Implementación de funciones . Por lo general, el propietario o gerente de producto establece nuevas tareas, de acuerdo con su visión y el objetivo del equipo. La solicitud de una función puede provenir de quienes dependen de nuestro trabajo (por ejemplo, agregar un script de terceros para el seguimiento o las pruebas A / B ).
  
• Organización CI / CD . Los desarrolladores pueden crear sus propias tuberías para el montaje y la implementación, pero lo más probable es que utilicen la infraestructura preparada por otros (por ejemplo, el departamento de infraestructura).
  
• Seguridad . Es genial si el proyecto tiene un departamento (o al menos una persona) especializado en seguridad, que ayuda a verificar la estructura del sistema, la implementación de funciones, nos envía informes de seguridad e informa sobre las correcciones.
  
• Interfaz de usuario Típicamente, un proyecto tiene un diseñador y / o un especialista en interacción con el usuario que es responsable de la apariencia, la usabilidad y la arquitectura de la información.
  
• Pruebas ¿Dónde estamos sin pruebas, verdad?
  

Si alguien es responsable de una tarea, lo más probable es que se encuentre en el tablero de tareas. La mayoría de las tareas se correlacionan con ciertos roles del flujo de trabajo, pero hay aquellos que se asignan tácitamente a los desarrolladores, por ejemplo, las pruebas: el departamento de desarrollo en su conjunto es responsable de ello y, por lo tanto, algunos componentes se prueban mejor que otros.

Quizás nadie argumentará que las pruebas automáticas son útiles. Por lo general, el departamento de desarrollo decide por sí mismo cuán extensamente el código está cubierto por las pruebas; es importante que todos los desarrolladores del equipo puedan escribir pruebas. Una situación similar es con los problemas de rendimiento: generalmente se supone que los desarrolladores deben lidiar con esto. Noté que escribir pruebas para el código y al mismo tiempo comprender las consecuencias que conducirán al funcionamiento incorrecto de un fragmento es más fácil que tener en cuenta todos los elementos que pueden ralentizar el recurso web .

Seis pasos para implementar la importancia del rendimiento de los recursos web

Tenemos herramientas para analizar el rendimiento, pero su uso depende de los propios desarrolladores. ¿Cómo introducir en la empresa la idea de que la productividad debe ser percibida como una de las funciones?

He compilado una lista de seis puntos que debería ayudar en este asunto.

1. Entorno de desarrollo environment entorno de usuario

Trabajo fácil , filmado por Emil Perron

Para el desarrollo de sitios web, uso una MacBook Pro. Tengo un iPhone X como teléfono y tengo un dispositivo de prueba separado. Además, tengo una conexión a Internet muy rápida y estoy sentado cerca de los centros de datos en Estocolmo y Londres. Después del trabajo, voy al metro, donde hay 4G (y sin espacios). En términos generales, fue en Estocolmo donde apareció 4G por primera vez, en 2009 .

Los usuarios difícilmente tendrán condiciones tan elegantes (con raras excepciones).

Si nosotros mismos no tenemos problemas de rendimiento, ¿cómo priorizar la tarea de optimización? Es como tratar de implementar una interfaz para personas con discapacidades sin usar controles de teclado, lectores de pantalla y verificar colores contrastantes, es decir, un mal trabajo.

Y no tiene que esperar los cambios aquí: a los desarrolladores web occidentales les gusta elegir lo último de las computadoras portátiles y otros dispositivos. Lo mismo puede decirse de casi todos los responsables de establecer objetivos para el proyecto y la empresa. Además, en algunos casos, nos enfocamos en el segmento superior de dispositivos, porque son utilizados por aquellos que tienen más probabilidades de estar dispuestos a pagar por nuestro producto. Bruce Lawson dijo sobre este tema que deberíamos construir una "red mundial, no una red para el rico Occidente".

Piense qué es mejor: ¿atraer a más usuarios, incluso si son menos solventes , o menos, pero más solventes?

Curiosamente, sin tener en cuenta el trabajo de los usuarios en dispositivos reales, terminamos haciendo suposiciones falsas . Supongamos que decidimos facilitar el desarrollo y abandonar las plataformas en las que estadísticamente menos usuarios o menor uso (por ejemplo, menos visitas a la página por sesión). No tiene sentido admitir un navegador antiguo que casi nunca usa nadie . Y se podría decir que esta decisión se basa en datos sólidos.

Pero no nos apuremos. Pero, ¿qué sucede si el bajo rendimiento en alguna plataforma es una consecuencia del hecho de que nuestro producto es inconveniente o ineficaz? Esta hipótesis es difícil de probar, porque los desarrolladores dirán que todo está bien con ellos, en sus computadoras y en un navegador específico (supongamos que será Google Chrome). Sin darse cuenta, prestamos más atención al navegador que utilizamos y, como resultado, a menudo nos comprometemos a favor de un entorno de trabajo más moderno. Oh, escucho un grito de dolor desde el otro lado del monitor: “¿Sigues usando este navegador? ¡Que se actualicen!

Recientemente me encontré con una cita que realmente me gustó:

“Cuando trabajé en Google, alguien me contó una historia sobre cómo completaron una gran optimización, y de repente resultó que el tiempo de carga de la página solo aumentó. Después de profundizar en los datos, descubrimos una razón: después de la optimización, comenzó a llegar mucho más tráfico de África. Anteriormente era imposible usar el producto con una Internet lenta, y después de la optimización se hizo posible, y apareció un gran número de usuarios con una conexión débil, lo que aumentó el tiempo promedio de descarga ".
- Dan Lu, "Internet hinchado"

Repito: simular el crecimiento de la productividad al excluir a los usuarios que dan un bajo rendimiento y estropean las estadísticas es fácil. Pero esto no es optimización, sino solo un juego con números .

Tómelo usted mismo y distribúyalo a sus colegas que trabajan en el proyecto, dispositivos antiguos. Simule malas condiciones de conexión, procesadores lentos y adapte su producto a esto. Descubra qué dispositivos tienen los usuarios, y dando prioridad a los dispositivos que realmente acceden a su sitio, esté especialmente atento.

2. Es mejor aprender los conceptos básicos de la tecnología en lugar de bibliotecas específicas

Hasta ahora, muchos requisitos de trabajo y preguntas de entrevistas de trabajo se han centrado en las bibliotecas, en lugar de las tecnologías subyacentes. Aunque sería más correcto preguntar: “¿Qué sucede cuando un navegador intenta cargar un sitio web? ¿Por qué razones puede un sitio cargar durante demasiado tiempo? ¿Cómo organizaría la arquitectura de un proyecto web de tamaño no trivial (cliente, servidor, bases de datos, almacenamiento en caché)?

Un desarrollador que conozca las respuestas a tales preguntas sabiamente elegirá las bibliotecas npm para el proyecto. Discutiendo la funcionalidad con los diseñadores y el cliente, podrá expresar una mirada especial al desarrollo. Dicho desarrollador tendrá en cuenta las API de los navegadores nuevos y antiguos y tratará de aprovechar la plataforma "inconveniente", en lugar de aislarla.

Tal vez, como resultado, el departamento necesitará contratar a un especialista que conozca React o Vue, e inmediatamente incluirlo en el trabajo y continuar con el proyecto. Y al mismo tiempo, sería bueno para los nuevos empleados permanecer más tiempo en la empresa, cuestionar las soluciones técnicas existentes y ofrecer mejores opciones.

Hay dos constantes que no cambian, donde sea que aplique mis habilidades como desarrollador:

1. Es necesario cuestionar las decisiones de la propia empresa, de lo contrario, un competidor lo hará y se presentará. Estimule los comentarios de los participantes del proyecto y deles tiempo para desarrollar prototipos innovadores y versiones piloto.
   
2. Las soluciones técnicas adoptadas hoy no durarán mucho. Apóyese en la modularidad, la posibilidad de eliminación de componentes y entrega rápida.
   

Si está de acuerdo con lo anterior, está abierto a las ideas de personas que no están comprometidas con una tecnología en particular y puede justificar las ventajas y desventajas de varias soluciones técnicas.

Participa en entrevistas. Ofrezca reservar un tiempo durante el cual los empleados puedan aprender algo (por ejemplo, puede dar pequeñas presentaciones regularmente durante el almuerzo) y explorar ideas que puedan beneficiar los proyectos.

3. Encuentra tiempo para experimentar y probar.

Anteriormente, enviaba a colegas enlaces a discursos en conferencias como Google I / O y artículos sobre todo tipo de cosas nuevas. Me pareció estar al tanto de los últimos eventos tanto para mí como para ellos.

Sin pensar en compartir enlaces interesantes con usted, a menudo solo carga a sus colegas aún más: no solo tienen que hacer su trabajo, sino también leer lo que envió. Se supone que el aprendizaje es mejor en la práctica, por lo que parecerá que necesitan intentar aplicar esta nueva biblioteca, técnica, idea, etc.

Hazles un favor: aplica la novedad en el proyecto tú mismo. "La nueva API del navegador se ve genial" - el enfoque equivocado para la evaluación. Es mejor argumentar así: "Si usa X así, nuestro proyecto mejorará ". El segundo, por supuesto, es más difícil, pero el rendimiento en este caso es mayor, y será mucho más fácil convencer al jefe.

Hay muchos estudios de caso en la red sobre cómo la optimización del rendimiento mejora las métricas clave. Una buena fuente de artículos sobre esto, por ejemplo, como WPO Stats .


Muchos estudios de casos en los que el aumento de la productividad ha llevado a mejores indicadores clave de rendimiento.

A veces, para hacer que una empresa preste más atención a la velocidad de un proyecto web, solo la investigación práctica de alguien no es suficiente como evidencia.

Necesito un prototipo. Pero puede parecer que no hay tiempo y nunca lo será para su creación: todo se gasta en corregir errores y agregar nuevas funciones.

En mi opinión, cada función debe pasar por tres etapas:



La idea puede provenir del propietario o gerente del producto, pero también puede provenir del desarrollador . Es necesario probarlo y demostrar que funciona; para esto necesitamos un prototipo. Solo después de eso se realizará la función. Además, esto significa que antes de la implementación de la idea se debe probar de alguna forma. Será necesario demostrar que mejorar el rendimiento del sitio mejora el rendimiento, pero lo mismo se aplica a otras funciones.

Al buscar lo que se puede acelerar, elija lo que los usuarios pueden experimentar. Para que los usuarios puedan notar la diferencia en un período de tiempo aceptable, la velocidad del sitio debe aumentar al menos en un 20% y mejor, en un 30% .

4. Entrenar colegas

¿Te ha sucedido alguna vez que tuviste que eliminar o reemplazar algún fragmento de código porque nadie entendía cómo funcionaba? Quizás este cuenco no ha pasado a nadie. Si el autor solo entiende y respalda el código, ¿qué sucederá si esta persona se va de vacaciones, se enferma, deja la empresa?


Aprovechamos la ausencia de John, nos deshacemos de la complejidad innecesaria.

La mayoría de nosotros trabajamos en equipo, por lo que al elegir las soluciones debe centrarse en aquellas que la mayoría de los colegas entenderán. Defina el "múltiplo común más pequeño" en el equipo e intente no usar soluciones demasiado complicadas solo porque es divertido meterse con ellas . En la optimización del rendimiento, a veces se logra una pequeña ganancia por un aumento excesivo de la complejidad.

Hace un par de meses escribí sobre la optimización de imágenes y cómo mejorar la velocidad aparente de descarga . Comencé con lo obvio: menos consultas, elegir el formato correcto, optimizar imágenes. Sin embargo, la mayoría recuerda solo el uso de imágenes de marcador de posición, que le permiten hacer una transición suave a la imagen deseada.


Opciones de lo que puede mostrar antes de cargar una imagen.

¡Esta es la parte más interesante e innovadora! Enserio? Ahora trate de decirles a sus colegas que va a crear un servicio de back-end que procesará las imágenes en cola y almacenará un pequeño boceto que se incrustará en la página cuando se procese. ¿Cuándo va a disparar? ¿Cuánto tiempo llevará? ¿Dónde almacenar bocetos? ¿Cómo escalar este servicio en diferentes servidores?

Es más efectivo evitar la entrega de imágenes y optimizar las que aún deben entregarse; esto es por lo que debe esforzarse.

Además de elegir soluciones "suficientemente buenas" que sean comprensibles para la mayoría de los colegas, debe pensar en elevar el nivel de conocimiento en el departamento . ¿Te consideran un muelle en un área específica? Haga una presentación a sus colegas e inspírelos con una nueva idea.

Después de todo, si solo promueves una idea determinada, no durará mucho.

5. Comparta historias de éxito (y fracasos)

Para cambiar la forma de pensar en la empresa, primero tendrá que convencer a sus propios colegas del nuevo enfoque. Pero debe compartir los resultados de sus experimentos fuera de su departamento.

A nivel de toda la empresa, esto ayudará a inspirar a otros empleados y abrirá el camino para emprendimientos más ambiciosos . Y será más fácil obtener soporte para los servicios e infraestructura correctos si varios departamentos lo consideran necesario.

- , .

-, Etsy. :

« « », , : , , , ».
— , « »

.

, , , .


Etsy

, , . Vox Media — , The Verge . 2015 . Vox Media , .

« . — . ».
— Vox Media, « » ( )

SpeedCurve , The Verge Vox Media ( )

Vox Media ( , ) , .


Vox Media .

: ( ), . , , .

6.

— ́ , -.

, : WebPagetest , Pagespeed Insights , Audits Chrome . .


WebPagetest — .

, , , .

, , . — .

— . . , ( , , . .).

RUM-, . , , , - , .

, , — Google Analytics , — : , Calibre , SpeedCurve SiteSpeed .

, .

— . (, SiteSpeed) , . , .

- Caliber . « », - . :

• . , ( , ) .
  
• . , , , , . , , , , .
  
• . , , : « - », « Caliber», «», «» « ». , , — : .
  

? , .

1. , .
   
2. . — .
   
3. — , , .
   
4. , , , .
   
5. La herramienta fue capaz de visualizar indicadores de rendimiento y mostrar su cambio, lo cual fue útil cuando decidimos compartir nuestra experiencia con otros desarrolladores web de la compañía. Dichas herramientas hacen que sea necesario establecer restricciones en los indicadores de rendimiento, superando lo cual provocará que se rechacen las solicitudes de cambios en el código (o solo recibirán notificaciones).
   
6. La herramienta propuesta se incluyó en el flujo de trabajo y podía funcionar sin esfuerzo de nuestra parte; no era necesario tomar recursos de otras tareas.
   

Conclusión

Traté de dar algunos consejos sobre cómo crear sitios más receptivos, espero tener éxito. Gracias por su atencion!

Sobre el traductor

El artículo fue traducido por Alconost.

Alconost localiza juegos , aplicaciones y sitios en 68 idiomas. Traductores en lengua nativa, pruebas lingüísticas, plataforma en la nube con API, localización continua, gestores de proyectos 24/7, cualquier formato de recursos de cadena.

También hacemos videos de publicidad y capacitación , para sitios que venden, imágenes, publicidad, capacitación, teasers, expliner, trailers de Google Play y App Store.

Más detalles