Considerações ao criar painéis de Looker com bom desempenho
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Uma das melhores maneiras de permitir que os usuários explorem dados é fornecendo visualizações selecionadas criando painéis eficazes do Looker. Se você quiser criar uma ótima experiência de performance para seus usuários, considere as dicas desta página ao projetar seus painéis.
Os painéis do Looker são carregados no navegador. Para criar um desempenho ideal, considere os seguintes fatos.
O elemento mais importante do desempenho do painel é a consulta SQL subjacente. Cada elemento do painel, quando não retornado do cache, executa uma consulta SQL que leva tempo para ser executada no banco de dados. Consulte a seção Otimizar o desempenho da consulta da página de práticas recomendadas Otimizar a performance do Looker para mais detalhes sobre como criar consultas com bom desempenho.
Alguns componentes exigem mais memória do que SQL e podem causar lentidão nos painéis:
O volume de dados tem o maior impacto no desempenho. Quanto mais dados forem retornados
em um elemento individual, mais recursos de memória serão consumidos. Os elementos de visualizações e painéis que são retornados com muitos milhares de pontos de dados vão usar mais memória.
Limite o número de elementos do painel. Não
há uma regra rígida sobre o número, já que o design de um único
elemento afeta o consumo de memória com base em alguns fatores (abordados
mais adiante nesta página). No entanto, evite criar painéis com 25 ou mais consultas. Mantenha a performance do painel suave criando links de navegação entre painéis ou criando links para URLs personalizados para criar uma navegação selecionada de um painel para outro. Você também pode tentar concatenar medidas semelhantes na mesma visualização de valor único para evitar muitas visualizações de bloco único.
Use as configurações do painel de maneira estratégica. Se o painel usa autoatualização, verifique se ele é atualizado mais rápido do que o processo de ETL. Em geral, evite definir a atualização automática com menos de 15 minutos. Não use run on load se o painel for filtrado. Use filtros obrigatórios para impedir que os usuários executem painéis sem os filtros necessários.
Use o armazenamento em cache. É recomendável usar datagroups para sincronizar todo o conteúdo do Looker (painéis, Looks, programações) com seu processo de ETL. Isso ajuda
a evitar consultas desnecessárias quando os dados não estão atualizados.
Os recursos de processamento pós-consulta, como resultados mesclados, campos personalizados e cálculos de tabela, consomem memória. Quanto
mais recursos de processamento pós-consulta forem usados, mais memória será consumida. Se você estiver usando os mesmos cálculos de tabela, resultados mesclados ou campos personalizados em vários painéis e visualizações, considere codificá-los no modelo do LookML sempre que possível. Em geral, não adicione mais de quatro Blocos de resultados combinados a um painel.
As dimensões dinâmicas consomem memória. Quanto
mais dimensões são pivotadas em um Bloco de informações ou painel, mais memória é consumida quando o painel é
carregado. Como mencionado no primeiro ponto, isso ocorre porque mais dados são usados à medida que mais dados são retornados. Se a dimensão que você está girando tiver uma cardinalidade alta (muitos valores únicos), haverá uma coluna para cada valor. Filtre no painel ou no Look para permitir que o usuário selecione os valores de dimensão que ele quer comparar, em vez de mostrar tudo de uma vez.
Ter muitas colunas e linhas consome mais memória. Para melhorar a performance do navegador, recomendamos 50 colunas ou menos. Novamente, como discutido no primeiro ponto, o retorno de um grande volume de linhas e muitas colunas pode prejudicar a performance. Filtre no nível do painel ou do Look para reduzir o número de resultados em um elemento.
Use filtros compartilhados com uma única consulta para renderizar um único resultado de consulta em vários blocos. Isso vai reduzir
o número total de consultas executadas no painel usando uma
consulta para acionar vários elementos do painel.
Envie consultas usando a opção Todos os resultados com moderação, porque algumas consultas podem ser muito grandes e sobrecarregar o servidor do Looker quando processadas.
Teste a performance do painel depois de adicionar elementos. Durante a criação, continue navegando até o painel e atualize a página para determinar como a performance é afetada à medida que você adiciona mais Looks.
Quando estiver satisfeito com o novo painel do Looker, use o permissão de pastas para
garantir que o painel não seja alterado acidentalmente. Use grupos de usuários para gerenciar o acesso e as permissões de conteúdo em massa, em vez de por usuário.
Se você tiver problemas de desempenho, entre em contato diretamente com o suporte do Looker. Nossa equipe está sempre pronta para investigar e ajudar.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-07-31 UTC."],[],[],null,["# Considerations when building performant Looker dashboards\n\nOne of the best ways to empower users to explore data is by providing them with curated views by [building effective Looker dashboards](/looker/docs/creating-user-defined-dashboards). If you want to create a great performance experience for your users, consider the tips on this page as you design your dashboards.\n\n\nLooker dashboards load in the browser. To build for optimal performance, keep the following facts in mind.\n\n\nThe most important element of dashboard performance is the underlying SQL query performance. Each dashboard element, when not returned from cache, runs a SQL query that takes time to execute on the underlying database. See the **Optimize Query Performance** section of the [Optimize Looker performance](/looker/docs/best-practices/how-to-optimize-looker-server-performance#optimize-query-performance) Best Practices page for more details regarding building performant queries.\n\n\u003cbr /\u003e\n\n\nSome components are more memory-intensive than they are SQL-related --- these can cause slow performance in dashboards:\n\n-\n **Data volume has the greatest impact on performance.** The more data that is returned\n in an individual element, the more memory resources will be consumed. Looks and dashboard elements that are returned with many thousands of data points will use more memory.\n\n-\n **Limit the number of dashboard elements.** There\n is no hard and fast rule about the number, since the design of a single\n element impacts its memory consumption based on a few factors (covered\n later on this page). However, avoid creating dashboards with 25 or more queries. Keep dashboard performance slick by creating navigation links\n between dashboards or by [creating links to custom URLs](/looker/docs/reference/param-field-link) to\n create a curated navigation from dashboard to dashboard. You can also\n try concatenating similar measures into the same single value visualization to\n avoid many single tile visualizations.\n\n-\n **Use dashboard settings strategically.** If\n your dashboard uses [autorefresh](/looker/docs/editing-user-defined-dashboards#autorefresh), make sure it refreshes no faster than your ETL process. In general, you should avoid setting the autorefresh faster than 15 minutes. Don't use [run on load](/looker/docs/editing-user-defined-dashboards#run_on_load) if the dashboard is meant to be filtered. Use [required filters](/looker/docs/filters-user-defined-dashboards#requiring_a_filter_value) to prevent users from running dashboards without the\n necessary filters.\n\n-\n **Leverage caching.** It's best practice to use [datagroups](/looker/docs/caching-and-datagroups) to sync all Looker content (dashboards, Looks, schedules) with your ETL process. This helps\n avoid unnecessary querying when the data is not up to date.\n\n-\n **Post-query processing features, such as [merged results](/looker/docs/merged-results), [custom fields](/looker/docs/custom-fields), and [table calculations](/looker/docs/table-calculations), consume memory.** The\n more post-query processing features used, the more memory is consumed. If you are using the same\n table calculations, merged results, or custom fields across multiple Looks\n and dashboards, consider hard-coding them into your LookML model wherever possible. In general, don't add more than four merged results tiles to a dashboard.\n\n-\n **Pivoted dimensions consume memory.** The\n more dimensions that are [pivoted](/looker/docs/creating-and-editing-explores#pivoting_dimensions) in a Look or dashboard tile, the more memory is consumed when the dashboard\n is loaded. As mentioned in the first bullet point, this is because more data is used as more data is returned. If the dimension you are pivoting has high cardinality (many unique values), there will be a column for each value. Filter at the dashboard or Look level to allow the user to select the dimension values that they are most interested in comparing, as opposed to showing everything at once.\n\n-\n **Having many columns and rows consumes more memory.** For browser performance, 50 or fewer columns is recommended. Again, as discussed in the first bullet point, Looks returning a high volume of rows and many columns can slow performance. Filter at the dashboard or Look level to reduce the number of results within an element.\n\n-\n Leverage [shared filters with a single query](https://community.looker.com/technical-tips-tricks-1021/shared-filters-on-single-value-charts-performance-technique-29987) to\n render a single query result across multiple tiles. This should reduce\n the total number of queries run from the dashboard by leveraging one\n query to power multiple dashboard elements.\n\n-\n **[deliver queries](/looker/docs/and-or-filters-in-explores\u003eAND/OR filters\u003c/a\u003e\u003c/strong\u003e. There is no limit to the number of groups that can be created; however, excessive filter groups may impact browser performance.\n \u003c/p\u003e\n \u003c/li\u003e\n \u003cli\u003e\n \u003cp\u003e\n Download or \u003ca href=) using the [**All Results**](/looker/docs/downloading#all_results) option sparingly, as some queries can be very large and overwhelm the Looker server when processed.**\n\n**Make sure that you test dashboard performance after you add elements. As you are building, continue to navigate to the dashboard and refresh the page to determine how performance is impacted as you add additional Looks.\nOnce you are satisfied with your new Looker dashboard, be sure to utilize [folder permissioning](/looker/docs/organizing-spaces#folder_access_levels) to\nensure that the dashboard cannot inadvertently be changed. Leverage [user groups](/looker/docs/admin-panel-users-groups) to manage content access and permissions in bulk, instead of on an individual-user basis.\nIf you're having performance issues, reach out to [Looker Support](https://console.cloud.google.com/support/) directly --- our team is always ready to investigate and lend a hand!**"]]