Problemas habituales de rendimiento de las aplicaciones de lienzo y sus soluciones

  • Artículo

Puede crear aplicaciones de lienzo con una amplia gama de orígenes de datos. Elija el origen de datos correcto y un conector según las necesidades empresariales y los escenarios para los que se está diseñando la aplicación. Para aplicaciones empresariales, el origen de datos recomendado es Microsoft Dataverse, ya que proporciona diversas ventajas de rendimiento. Para aplicaciones con algunas transacciones, puede optar por cualquier otro origen de datos disponible en su entorno.

Para las consideraciones de rendimiento de una aplicación, piense en la cantidad de usuarios que usarán la aplicación cuando se haya publicado; el volumen de transacciones de creación, recuperación, actualización y eliminación (CRUD); el tipo de interacciones de datos; acceso geográfico; y los tipos de dispositivos que tienen los usuarios.

En este artículo se describen algunos de los problemas de rendimiento más habituales que pueden hacer que la ejecución de las aplicaciones de lienzo sea lenta, y la forma de solucionarlos. Esta información le ayudará a mejorar el rendimiento de la aplicación teniendo en cuenta su plan de negocios y su crecimiento.

Para empezar, veremos algunos de los problemas de rendimiento que ocurren habitualmente, con independencia del conector que se utilice. En secciones posteriores conocerá los problemas de rendimiento y las soluciones específicas para diversos conectores.

Antes de empezar, asegúrese de comprender las fases de ejecución de las aplicaciones de lienzo y el flujo de llamadas de datos. Además, lea Causas posibles de rendimiento lento de las aplicaciones de lienzo para conocer los errores habituales que se pueden evitar al diseñar o actualizar aplicaciones de lienzo.

Los conjuntos de datos grandes se cargan lentamente en diferentes plataformas

El rendimiento de una aplicación puede variar al cargar grandes conjuntos de datos en distintas plataformas, como iOS o Android. Esta variación se debe a distintas limitaciones de las solicitudes de red en cada plataforma. Por ejemplo, la cantidad de solicitudes de red simultáneas que se permiten puede variar según la plataforma. Para conjuntos de datos grandes, esta diferencia puede afectar de manera importante al tiempo de carga de datos.

Recomendamos cargar únicamente los datos que hay que mostrar inmediatamente en pantalla. Pagine y almacene en caché los demás datos. Más información: Sugerencias y procedimientos recomendados para mejorar el rendimiento de una aplicación de lienzo

Se recuperan demasiadas columnas

Le recomendamos que seleccione únicamente las columnas necesarias para la aplicación. Al agregar más (o todas las) columnas del origen de datos, se descargan todos los datos de las columnas. Esta acción genera una gran cantidad de llamadas de sobrecarga de red y, en consecuencia, un consumo elevado de memoria en el dispositivo cliente. Este problema puede afectar en mayor medida a los usuarios con dispositivos móviles si el ancho de banda de la red es limitado, o si un dispositivo tiene memoria limitada o un procesador antiguo.

Por ejemplo, si usa Dataverse como origen de datos de la aplicación, asegúrese de tener habilitada la característica selección explícita de columnas. Esta característica permite a Power Apps restringir la recuperación de datos a únicamente las columnas utilizadas en la aplicación.

Para activar la función de selección de columna explícita en la aplicación de lienzo, vaya a Configuración > Próximas características > Versión preliminar y luego active el botón de alternancia Selección de columna explícita.

Exploradores incompatibles o heredados

Los usuarios que utilizan navegadores heredados o no compatibles pueden experimentar problemas de rendimiento. Asegúrese de que los usuarios utilicen únicamente exploradores compatibles para ejecutar aplicaciones de lienzo.

Rendimiento lento debido a la distancia geográfica

La ubicación geográfica del entorno y la distancia del origen de datos a los usuarios pueden influir en el rendimiento.

Recomendamos que el entorno se encuentre cerca de los usuarios. Aunque Power Apps utiliza la red de entrega de contenido (CDN, Content Delivery Network) de Azure para el contenido, las llamadas de datos aún obtienen los datos del origen de datos. Que el origen de datos esté en otra ubicación geográfica puede afectar negativamente al rendimiento de la aplicación.

Una distancia geográfica excesiva afecta al rendimiento de diferentes maneras: latencia, reducción del rendimiento, menor ancho de banda o pérdida de paquetes.

La lista de permitidos no se ha configurado

Asegúrese de que las URL de servicio requeridas no se hayan bloqueado o que se hayan agregado a la lista de permitidos de su firewall. Para obtener una lista completa de todas las URL de servicio que se deben permitir para Power Apps, vaya a Servicios obligatorios.

Uso de funciones no delegables y límites de filas de datos inadecuados para consultas no delegables

Las funciones delegables delegan el procesamiento de datos en el origen de datos, minimizando la sobrecarga en el lado del cliente. Cuando la delegación no es posible, se puede restringir el límite de filas de datos para consultas no delegables, de manera que el número de filas devueltas desde una conexión basada en servidor siga siendo óptimo.

El uso de funciones no delegables y límites de filas de datos para consultas no delegables inapropiados supone una sobrecarga adicional para la transferencia de datos. Esta sobrecarga tiene como consecuencia la manipulación de los datos recibidos para el montón de JS en el lado del cliente. Asegúrese de utilizar funciones delegables para la aplicación siempre que estén disponibles y el límite de filas de datos óptimo para consultas no delegables.

Más información: Uso de la delegación, Información general sobre la delegación

El evento OnStart requiere un ajuste

El evento OnStart se ejecuta cuando se carga la aplicación. Realizar llamadas para grandes cantidades de datos a través de las funciones de la propiedad OnStart de la aplicación hará que la aplicación se cargue lentamente. Una pantalla con una gran dependencia de los controles y valores definidos en otra pantalla se verá afectada con una navegación de pantalla lenta.

En las siguientes secciones se describen algunos de los problemas más comunes que se experimentan en estas situaciones.

Una gran cantidad de llamadas en el evento OnStart hace que la aplicación se inicie lentamente

En una empresa, el volumen de llamadas de datos a un origen de datos central puede generar cuellos de botella en el servidor o una contención de recursos.

Use el mecanismo de caché para optimizar las llamadas de datos. Una sola aplicación puede ser utilizada por muchos usuarios, lo que genera múltiples llamadas de datos por usuario que llegan a los extremos del servidor. Estas llamadas de datos pueden provocar un cuello de botella o una limitación.

Latencia en el evento OnStart debido a scripts que realizan trabajo pesado

Ejecutar scripts que realizan trabajo pesado en el evento OnStart es uno de los errores más habituales al diseñar aplicaciones de lienzo. Debe obtener únicamente los datos necesarios para que se inicie la aplicación.

Optimice la fórmula en un evento OnStart. Por ejemplo, puede mover algunas funciones a la propiedad OnVisible. De esta manera, la aplicación se iniciará rápidamente y se pueden realizar otros pasos mientras se abre la aplicación.

Más información: Optimizar la propiedad OnStart

Sugerencia

Recomendamos usar la propiedad App.StartScreen, ya que simplifica el inicio de la aplicación y aumenta el rendimiento de la aplicación.

Presión de memoria en el lado del cliente

Es importante comprobar el consumo de memoria de una aplicación de lienzo, ya que la mayoría de las veces la aplicación se ejecuta en dispositivos móviles. Las excepciones de memoria en el montón son la causa más probable de que una aplicación de lienzo se bloquee ("cuelgue") o deje de funcionar en algunos dispositivos.

Un montón de JavaScript (JS) puede llegar al limite si se ejecutan scripts que realizan trabajo pesado en el lado del cliente para agregar, unir, filtrar, ordenar o agrupar columnas. En la mayoría de los casos, la excepción de memoria insuficiente en el montón de un cliente puede hacer que la aplicación se bloquee o deje de funcionar.

Al utilizar datos de orígenes como Dataverse o SQL Server, puede utilizar un objeto Vista para asegurarse de que la unión, el filtrado, la agrupación o la ordenación se realicen en el lado del servidor y no en el lado del cliente. Este enfoque reduce la sobrecarga del cliente debida a la ejecución de scripts para estas acciones.

Si en el lado del cliente se realizan operaciones intensivas, como JOIN o Group By, con un conjunto de datos que tiene 2000 registros o más, aumentará el número de objetos en el montón y eso hará que se supere el límite de memoria.

Las herramientas de desarrollo de la mayoría de los exploradores permiten crear perfiles de la memoria. Esto ayuda a visualizar el tamaño del montón, los documentos, los nodos y las escuchas. Perfile el rendimiento de la aplicación mediante un explorador, como se describe en Información general sobre las herramientas de desarrollo de Microsoft Edge (Chromium). Compruebe los escenarios que superan el umbral de memoria del montón de JS. Más información: Solucionar problemas de memoria

Ejemplo de presión de memoria para una aplicación vista desde las herramientas de desarrollo de un explorador.

Consideraciones de rendimiento para el conector de SQL Server

Si desea conectarse a SQL Server local o Azure SQL Database, puede usar el conector de SQL Server para Power Apps. En esta sección se describen los problemas habituales relacionados con el rendimiento y sus soluciones para el uso de este conector en una aplicación de lienzo. Más información: Conectarse a SQL Server desde Power Apps, Crear una aplicación de lienzo desde Azure SQL Database

Nota

Aunque esta sección hace referencia a los problemas de rendimiento relacionados con el uso del conector de SQL Server y sus soluciones, la mayoría de las recomendaciones también se aplican cuando se usa como origen de datos cualquier tipo de base de datos (por ejemplo, MySQL o PostgreSQL).

Echemos un vistazo a los problemas de rendimiento habituales que surgen al usar el conector de SQL Server para aplicaciones de lienzo, y sus soluciones.

Consulta N+1

Las galerías que generan demasiadas solicitudes a los servidores provocan problemas de consulta N+1. El problema de la consulta N+1 es uno de los problemas más frecuentes que surgen al utilizar el control Galería.

Para evitar este problema, use objetos de vista en el back-end de SQL o cambie los escenarios de interfaz de usuario.

Recorrido de tabla en lugar de búsqueda de índice

Una aplicación puede ralentizarse si las funciones que utiliza ejecutan consultas en la base de datos, realizando recorridos de tablas en lugar de búsquedas en índices. Más información: Sugerencias, escaneado de tablas y búsqueda en índice

Para solucionar estos problemas, utilice StartsWith en lugar de IN en la fórmula. Con un origen de datos SQL, el operador StartsWith hace que se realice una búsqueda en el índice, mientras que el operador IN hace que se realice un recorrido de índice o tabla.

Consultas lentas

Puede crear un perfil y ajustar las consultas y los índices lentos en la base de datos SQL. Por ejemplo, si hay una fórmula que obtiene determinados datos en orden descendente (DESC) de una columna específica, esa columna de ordenación debe tener un índice con orden descendente. La clave de índice crea un orden ascendente (ASC) de forma predeterminada.

También puede comprobar la dirección URL de las solicitudes de datos. Por ejemplo, el siguiente fragmento de solicitud de datos (llamada OData parcial) solicita a SQL que devuelva 500 registros en los que coincidan los valores de la columna Valor, ordenando por ID en orden descendente.

Items? \$filter=Column eq 'Value' & Orderby = ID desc & top 500

Esto ayuda a comprender los requisitos del índice para cubrir condiciones de solicitud similares. En este ejemplo, si la columna ID tiene un índice con orden descendente, la consulta se realizará más rápido.

Compruebe el plan de ejecución de consultas lentas para ver si existe algún recorrido de tabla o índice. Supervise los costes excesivos de búsqueda de claves en el plan de ejecución.

Más información:

Contención de recursos de base de datos

Asegúrese de que origen de datos (base de datos SQL) no tenga contenciones de recursos, como cuellos de botella del procesador, contención de E/S, presión de memoria o contención de tempDB. Compruebe también los bloqueos, esperas, interbloqueos y tiempos de espera de consulta.

Sugerencia

Use la optimización automática para obtener información sobre posibles problemas de rendimiento de consultas y las soluciones recomendadas, así como para solucionar automáticamente los problemas identificados.

Cliente pesado o solicitudes excesivas

Una aplicación que ejecuta operaciones Group By, Filter By o JOIN en el lado del cliente consume recursos de procesador y memoria de los dispositivos cliente. En función del tamaño de los datos, estas operaciones pueden requerir más tiempo de ejecución de scripts en el lado del cliente, aumentando el tamaño del montón de JS en el cliente. Este problema empeora cuando se usa un origen de datos local, ya que cada llamada de datos de búsqueda viaja al origen de datos a través de la puerta de enlace de datos.

En estas situaciones, use el objeto Vista de la base de datos SQL para las operaciones Group By, Filter By o JOIN. Las vistas pueden usar columnas selectivas y quitar columnas innecesarias con tipos de macrodatos como NVARCHAR(MAX), VARCHAR(MAX) y VARBINARY(MAX).

Sugerencia

Este enfoque también ayuda a abordar el problema de la consulta N+1.

Tamaño de los datos transferidos al cliente

De forma predeterminada, una aplicación de lienzo muestra datos utilizando las tablas o vistas de los objetos de base de datos disponibles. Recuperar todas las columnas de una tabla puede hacer que la respuesta sea lenta, especialmente cuando se utilizan tipos de macrodatos como NVARCHAR(MAX).

La transferencia de grandes cantidades de datos a los clientes lleva tiempo. Esta transferencia también da como resultado más tiempo de ejecución de scripts cuando hay grandes cantidades de datos en el montón de JS en el lado del cliente, como se describió anteriormente en este artículo.

Para reducir el tamaño de los datos que se transfieren al cliente, use vistas con las columnas concretas que requiere la aplicación y asegúrese de que esté habilitada la selección de columnas explícita, como se describió anteriormente en este artículo.

Consideraciones específicas de SQL Server local

El rendimiento de una aplicación de lienzo que utiliza el conector de SQL Server con una puerta de enlace de datos local puede verse afectado de varias formas. En esta sección se enumeran los problemas de rendimiento comunes y las soluciones específicas del uso de un origen de base de datos local.

Puerta de enlace de datos local incorrecta

Las organizaciones pueden definir varios nodos para pasarelas de datos locales. Si alguno de los nodos es inaccesible (aunque sea solo uno), las solicitudes de datos dirigidas al nodo que no funciona no devolverán el resultado en un tiempo razonable o harán que se muestren mensajes de error de "nodo inaccesible" tras un rato de espera.

Asegúrese de que todos los nodos de puerta de enlace de datos locales estén en buen estado y configurados con una latencia de red mínima entre los nodos y la instancia de SQL.

Ubicación de la puerta de enlace de datos local

Una puerta de enlace de datos requiere llamadas de red a orígenes de datos locales para interpretar las solicitudes de OData. Por ejemplo, la puerta de enlace de datos debe comprender el esquema de la tabla de datos para traducir las solicitudes de OData en declaraciones de lenguaje de manipulación de datos (DML) de SQL. Se agrega una sobrecarga adicional cuando la puerta de enlace de datos se configura en una ubicación distinta con alta latencia de red entre la puerta de enlace de datos y la instancia de SQL.

En un entorno empresarial, se recomienda usar un clúster de puertas de enlace de datos escalable si se esperan solicitudes de grandes cantidades de datos. Compruebe cuántas conexiones se establecen entre los nodos de puerta de enlace de datos y la instancia de SQL.

Al comprobar las conexiones simultáneas en una puerta de enlace de datos local o en una instancia de SQL, su organización puede identificar el punto en el que hay que horizontalmente la puerta de enlace de datos y con cuántos nodos.

Escalabilidad de puerta de enlace de datos

Si espera acceder a un gran volumen de datos desde la puerta de enlace de datos local, tener un solo nodo de la puerta de enlace de datos local puede convertirse en un cuello de botella para procesar un volumen tan grande de solicitudes.

Un solo nodo de la puerta de enlace de datos local puede ser suficiente para controlar 200 conexiones simultáneas como máximo. Sin embargo, si todas estas conexiones simultáneas ejecutan consultas activamente, otras solicitudes tienen que esperar que una conexión esté disponible.

Para obtener más información sobre cómo asegurarse de que la puerta de enlace de datos local se adapte al volumen de datos y las solicitudes, vaya a Supervisar y optimizar el rendimiento de la puerta de enlace de datos local.

Consideraciones específicas de Azure SQL Database

Las aplicaciones de lienzo se pueden conectar a Azure SQL Database mediante el conector de SQL Server. Una causa común de los problemas de rendimiento al usar Azure SQL Database es seleccionar un nivel equivocado para los requisitos de la empresa.

Azure SQL Database está disponible en diferentes niveles de servicio, con capacidades variadas para satisfacer diferentes requisitos empresariales. Para obtener más información sobre cómo configurar los niveles, vaya a la Documentación de Azure SQL Database.

Con solicitudes de grandes cantidades de datos, los recursos del nivel que seleccione pueden verse limitados una vez que se alcanza el valor de umbral. Esta limitación afecta al rendimiento del siguiente conjunto de consultas.

Compruebe el nivel de servicio de Azure SQL Database. Un nivel inferior tendrá algunas limitaciones y restricciones. Desde la perspectiva del rendimiento, la CPU, el rendimiento de E/S y la latencia son importantes. Por lo tanto, le recomendamos que compruebe periódicamente el rendimiento de la base de datos SQL y vea si el uso de recursos supera el umbral. Por ejemplo, SQL Server local suele establecer el umbral de uso de CPU en el 75 %, aproximadamente.

Consideraciones de rendimiento para el conector de SharePoint

Puede usar el conector de SharePoint para crear aplicaciones usando datos de Microsoft Lists. También puede crear aplicaciones de lienzo directamente desde la vista de lista. Echemos un vistazo a los problemas de rendimiento habituales que surgen al usar un origen de datos de SharePoint con aplicaciones de lienzo.

Demasiadas columnas de búsqueda dinámica

SharePoint admite diversos tipos de datos, incluidas las búsquedas dinámicas como Persona, Grupo y Calculado. Si una lista define demasiadas columnas dinámicas, se necesita más tiempo para manipular estas columnas dinámicas dentro de SharePoint antes de devolver los datos al cliente que ejecuta la aplicación de lienzo.

No abuse del uso de las columnas de búsqueda dinámica en SharePoint. Este uso excesivo puede provocar una sobrecarga evitable y adicional en el lado de SharePoint para la manipulación de datos. En lugar de ello, puede usar columnas estáticas para almacenar los alias de correo electrónico o los nombres de las personas.

Columna de imagen y archivo adjunto

El tamaño de una imagen y un archivo adjunto pueden contribuir a una respuesta lenta mientras se recuperan en el cliente.

Revise su lista y asegúrese de que solo se hayan definido las columnas necesarias. El número de columnas en la lista afecta el rendimiento de las solicitudes de datos. Este efecto se debe a los registros coincidentes, o a que se obtengan los registros hasta los límites de fila de datos definidos y se transmitan de vuelta al cliente con todas las columnas definidas en la lista (aunque la aplicación no use todos los registros).

Para consultar solo las columnas utilizadas por la aplicación, habilite la característica de selección explícita de columnas descrita anteriormente en este artículo.

Listas grandes

Si tiene una lista grande con cientos de miles de registros, considere la posibilidad de crear particiones de la lista o dividirla en varias listas en función de parámetros como las categorías o la fecha y la hora.

Por ejemplo, sus datos podrían almacenarse anual o mensualmente en diferentes listas. En un caso así, puede diseñar la aplicación para permitir que un usuario seleccione un período de tiempo para recuperar los datos de ese intervalo.

Dentro de un entorno controlado, el punto de referencia de rendimiento ha demostrado que el rendimiento de las solicitudes de OData en las listas de Microsoft o SharePoint está muy relacionado con el número de columnas en la lista y el número de filas que se recuperan (limitado por el límite de fila de datos para consultas no delegables). Un número menor de columnas y un límite de fila de datos más bajo pueden hacer que una aplicación de lienzo funcione mejor.

Sin embargo, en el mundo real las aplicaciones están diseñadas para cumplir determinados requisitos empresariales. Puede que no sea rápido o sencillo reducir el límite de filas de datos o el número de columnas en una lista. Sin embargo, le recomendamos que supervise las solicitudes de OData en el lado del cliente y ajuste el límite de filas de datos para consultas no delegables y el número de columnas en la lista.

Consideraciones de rendimiento al usar el conector de Dataverse como origen de datos

Cuando usa Microsoft Dataverse como origen de datos, las solicitudes de datos van directamente a la instancia del entornosin pasar por Azure API Management. Más información: Flujo de llamadas de datos al conectarse a Microsoft Dataverse

Sugerencia

Cuando se utilizan tablas personalizadas en Dataverse, es posible que se requiera una configuración de seguridad adicional para que los usuarios puedan ver los registros con aplicaciones de lienzo. Más información: Conceptos de seguridad en Dataverse, Configurar la seguridad del usuario en recursos de un entorno y Roles de seguridad y privilegios

Una aplicación de lienzo conectada a Dataverse puede funcionar con lentitud si usa scripts de ejecución intensiva en el cliente, como cláusulas Filter By o JOIN en el cliente en lugar del servidor.

Use las vistas de Dataverse siempre que sea posible. Una vista con los criterios de unión o filtro necesarios ayuda a reducir la sobrecarga de usar una tabla completa. Por ejemplo, si necesita unir tablas y filtrar sus datos, puede definir una vista uniéndolos y defina solo las columnas que necesite. A continuación, use esta vista en la aplicación que crea esta sobrecarga en el lado del servidor para la operación de unir/filtrar en el lado del cliente. Este método no solo reduce las operaciones adicionales; también reduce la transmisión de datos. Para obtener información sobre la edición de filtros y los criterios de ordenación, vaya a Editar criterios de filtrado.

Consideraciones de rendimiento para el conector de Excel

El conector de Excel proporciona conectividad desde una aplicación de lienzo a los datos de una tabla que está en un archivo de Excel. Este conector tiene limitaciones en comparación con otros orígenes de datos (como una función delegable limitada), lo que restringe la carga de datos en la aplicación de lienzo a 2000 registros como máximo. Para cargar más de 2000 registros, divida sus datos en diferentes tablas de datos como otro orígenes de datos.

Veamos los problemas de rendimiento habituales que surgen al usar Excel como origen de datos para aplicaciones de lienzo, y cómo se pueden solucionar.

Demasiadas tablas de datos y una gran cantidad de datos

Una aplicación puede funcionar de forma lenta si usa un archivo de Excel con demasiadas tablas de datos, o con tablas de datos que tienen una cantidad de datos enorme en varias columnas. Un archivo de Excel no es una base de datos relacional ni un origen de datos que proporcione funciones delegables. Power Apps primero tiene que cargar datos de las tablas de datos definidas y luego usa funciones como Filtrar, Ordenar, UNIRSE, Agrupar por y Búsqueda.

Si hay demasiadas tablas de datos, con una gran cantidad de filas y columnas, el rendimiento de la aplicación se verá afectado y habrá sobrecarga en el cliente, ya que esto obliga a manipular cada tabla de datos en el montón de JS. Este efecto también hace que la aplicación consuma más memoria del cliente.

Para asegurarse de que su aplicación no se vea afectada por este problema, defina únicamente las columnas que necesita en la tabla de datos de un archivo de Excel.

Transacciones intensivas

Excel no es un sistema de base de datos relacional. Excel administra cualquier cambio de una aplicación de la misma manera que un usuario cambia los datos en un archivo de Excel. Si la aplicación tiene un gran número de lecturas, pero menos operaciones CRUD, puede funcionar bien. Sin embargo, si la aplicación realiza transacciones intensivas, el rendimiento de la aplicación puede verse afectado negativamente.

No existe un valor umbral específico para el número de transacciones, ya que también depende de los datos que se manipulan. Hay otros aspectos que también afectan el rendimiento de la aplicación, como la sobrecarga de la red o el dispositivo del usuario.

Si tiene datos de solo lectura, puede importarlos en la aplicación localmente, en lugar de cargarlos desde el origen de datos. Para aplicaciones empresariales, use orígenes de datos como Dataverse, SQL Server o SharePoint en su lugar.

Tamaño de archivo

Puede elegir entre una amplia gama de opciones de almacenamiento en la nube con capacidad de almacenamiento variable o configurable para el archivo de Excel. Sin embargo, tener un solo archivo grande de Excel con todas las tablas definidas en ese archivo supone una sobrecarga adicional para la aplicación mientras se descarga el archivo y se leen los datos que se van a cargar en el cliente.

En lugar de utilizar un archivo grande, divida los datos en varios archivos de Excel con tablas de datos mínimas. Conéctese a cada archivo solo cuando lo necesite. De esta manera, los datos de la tabla se carga fragmento a fragmento, lo que reduce la sobrecarga de tener muchas tablas o un conjunto de datos grande.

Ubicación de los archivos

La ubicación geográfica del origen de datos y su distancia a las ubicaciones de cliente puede crear un cuello de botella de rendimiento común para la aplicación e inducir latencia de red. Este efecto puede amplificarse en un cliente móvil con un ancho de banda limitado para la conectividad.

Es mejor mantener el archivo cerca de los usuarios finales (o, la mayoría de los usuarios finales, si tiene un público global) para que el archivo se pueda descargar rápidamente.

Pasos siguientes

Sugerencias y procedimientos recomendados para mejorar el rendimiento de las aplicaciones de lienzo

Consultar también

Comprender las fases de ejecución de las aplicaciones de lienzo y el flujo de llamadas de datos
Fuentes comunes de rendimiento lento para una aplicación de lienzo
Problemas habituales y sus soluciones para Power Apps
Solución de problemas de inicio de Power Apps

Nota

¿Puede indicarnos sus preferencias de idioma de documentación? Realice una breve encuesta. (tenga en cuenta que esta encuesta está en inglés)

La encuesta durará unos siete minutos. No se recopilan datos personales (declaración de privacidad).