Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performance - Tree shaking, minificar + bundle JS autogenerado #73

Open
fabianabarca opened this issue Jul 27, 2021 · 3 comments
Open
Assignees
Labels
enhancement New feature or request

Comments

@fabianabarca
Copy link
Owner

Algo así como https://web.dev/ para analizar cómo mejorar el sitio.

@fabianabarca fabianabarca added the documentation Improvements or additions to documentation label Jul 27, 2021
@jeancahu
Copy link
Collaborator

Esta es una de las herramientas junto con las otras que ya ustedes conocen

@jeancahu jeancahu changed the title Estadísticas de desempeño Performance - Tree shaking, minificar + bundle JS autogenerado Sep 24, 2021
@jeancahu
Copy link
Collaborator

  • Uso de la herramienta NPM para mantener control de las dependencias de Javascript y de CSS del frontend del proyecto
  • Reducir en todo lo posible el uso de jQuery ya que este es código viejo (legacy) y sus funcionalidades ya son soportadas por los estándares ES6 y posteriores de Javascript, y por ende la mayoría de navegadores modernos (respecto a esto los sitios web más importantes están tratando de migrar completamente de esta tecnología)
  • Configurar la dependencia development, Webpack como minificador y transpilador para generar el bundle de bibliotecas de frontend
  • Hacer uso de las herramientas que ya bootstrap pone a disposición para autogenerar la hoja de estilos minificada. (CLI, disponible en NPM)
  • Identificar todas las bibliotecas utilizadas más de una vez pero con diferentes versiones para usar solo una de las versiones que soporte todo lo necesario, con el fin de no descargar tantas megas en la carga inicial.
  • Opcional: Es posible utilizar al propio GitHub como servidor de ficheros estáticos, de esta manera se puede diversificar las fuentes y reducir la carga sobre el servidor central.

@jeancahu jeancahu added enhancement New feature or request and removed documentation Improvements or additions to documentation labels Oct 2, 2021
@jeancahu
Copy link
Collaborator

jeancahu commented Nov 6, 2021

Estamos teniendo un problema y es que antes de remover los estáticos es necesarico comenzar a usar las dependencias propias del proyecto por medio del manejador de paquetes JavaScript, es por esto que hice commits revert al branch de tree-shaking la idea es que antes de borrar cosas de /static que deberían estar en el tema lo mejor es mantener el package.json lo más cercano a stable para comenzar a trabajar dependencias desde esta rama ya que están evolucionando por aparte y esto tampoco es sano. Los reverts solo anulan los commits de borrar estáticos, el branch de tree-shaking es equivalente a que solo se hubiera agregado el package.json y las dep de vue, webpack, pero con la diferencia que la historia permanece entonces en caso de necesitar esos commits destructivos se puede regresar en el tiempo y usarlos.

Lo primero que habría que hacer antes de sacar todo el lastre estático y usar el tema correctamente sería automatizar el minificado y el pull de dependencias del código propio del proyecto, es decir, aquel JS que solo habita en este repositorio y no es thirdparty

  • Estabilizar la rama y los ficheros asociados a NPM dependencias y scripts, lo suficiente como para sentarla en stable y construir los JS partiendo ya de esta configuración de webpack para los scripts del proyecto.

  • Hacer un rebase a treeshaking de las ramas enfocadas en frontend para agregarlas ya al esquema de webpack

  • Sacar todo el JS de rutas o django-apps específicas del static/ global y ponerlos en el respectivo static/ de cada directorio, realizar los cambios pertinentes en templates etc.

  • Respecto a este tercer punto lo que pasa es que cada fichero estático que solo se usa en X página debería mantenerse en el directorio django-app/static/ por orden, a la hora de hacer el deployment de la versión de producción ahí sí se toman todos los static/ y se colocan en el mismo directorio todo para que NGINX lo sirva todo junto, pero es hasta ese punto que se juntan y se hace de forma automático por medio de comandos de Django.

Static de rutas lleva adentro otro directorio llamado rutas porque a la hora de moverlo al static global entonces en la URL quedará ese rutas que identificará a los estáticos de esta Django-app con respecto a los de todos los demás, por eso parece redundante pero no lo es, lo que pasa es que está pensado para cuando ya todos estén juntos en el NGINX no se mezclen y no haya colisiones de cosas que se llamen igual.

rutas/
├── admin.py
├── apps.py
├── fixtures
│   ├── agency.json
│   ├── calendar_dates.json
│   ├── calendar.json
│   ├── fare_attributes.json
│   ├── fare_rules.json
│   ├── feed_info.json
│   ├── routes.json
│   ├── stop.json
│   ├── stops.json
│   ├── stoptime.json
│   ├── stop_times.json
│   ├── trip.json
│   ├── trips.json
│   └── zones.json
├── migrations
│   ├── 0001_initial.py
│   ├── __init__.py
├── models.py
├── static
│   └── rutas
│       └── terminal.png
├── templates
│   ├── proximobus.html
│   ├── ruta.html
│   ├── rutas.html
│   ├── tabla-tarifas.html
│   └── tarifas-cards.html
├── tests.py
├── urls.py
└── views.py

Comparar luego del revert

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants