Home Blogs Otimização de aplicativos de página única React, Angular ou Vue para desempenho
Applications

Otimização de aplicativos de página única React, Angular ou Vue para desempenho

About The Author

Outline

Neste post, veremos como o Vue, o React e o Angular se comparam em termos de desempenho e o que pode ser feito para otimizar os spas de comércio eletrônico executados nesses frameworks frontend para a melhor experiência do usuário.

Como o Angular, React e Vue se comparam em termos de desempenho

A execução de um site rápido leva ao crescimento de resultados finais através de um melhor ranking de SEO, mais visitantes, sessões mais longas e, como resultado, mais receita. Muitos líderes de comércio eletrônico que entendem o papel da velocidade já mudaram para a arquitetura de comércio sem cabeça, permitindo a adoção de frontends modernos, como aplicativos web progressivos e spas. Os frontends DE SPA leves estão ganhando popularidade porque são uma maneira infalível de resolver vários problemas de desempenho inerentes às plataformas modernas de comércio eletrônico para que os operadores possam fornecer storefrents ultrarrápido.

Bem, essa é a teoria. Para verificar essas elevadas reivindicações, realizamos uma pequena análise interna de desempenho. Para isso, testamos quase 2 000 sites de comércio eletrônico populares executados nos principais frameworks frontend e avaliamos seu desempenho com base nas pontuações do Lighthouse 6. Os resultados foram surpreendentes – a pontuação média do Farol para as fachadas DE SPA testadas foi de apenas 24, com uma mediana de 19 (de 100)! Baixo como parece, isso ainda foi 26% maior do que a pontuação média para os 500 principais varejistas de internet dos EUA por receita.

Os sites Vue.js foram os mais rápidos, com média de 27 pontos com mediana de 20. Os sites Angular viram uma média de 23; no entanto, seus escores de desempenho foram mais dispersos, com uma mediana de apenas 18. Os sites React foram os mais lentos testados, com uma média de pontuação do Lighthouse de 22 e uma mediana de 18. Isso foi surpreendente, especialmente porque o framework é usado por alguns dos maiores jogadores, incluindo sites como PayPal, Grammarly e Vimeo, para citar alguns.

A conclusão do teste foi bastante clara – embora os spas sejam considerados mais rápidos do que os sites tradicionais, ainda há espaço para melhorias. Além disso, o Google crux e outras ferramentas de medição não rastreiam as transições de página de aplicativos de página única (SPAs), deturpando-os como sendo muito mais lentos do que eles e penalizando suas pontuações. Escrevemos mais sobre esta edição em outro post no blog.

O impactos do tempo de inicialização e desempenho em tempo de execução nas pontuações do Lighthouse

O desempenho dos aplicativos é definido por duas métricas: Tempo de inicialização e desempenho de tempo deexecução . O tamanho do pacote de código influencia principalmente o primeiro, ou seja, o código do aplicativo e o código da estrutura combinados. O desempenho do tempo de execução depende dos recursos de otimização específicos do framework e da maneira como ele lida com a manipulação e atualização do DOM.

Tamanho do pacote

Todos os três frameworks têm pacotes de código mínimos e de tamanho semelhante. Embora o tamanho do pacote do framework tenha impactos no tempo de inicialização, a métrica não deve ser o foco principal na comparação do desempenho do Angular, React e Vue.

Mais precisamente falando, o tamanho do pacote angular é apenas um pouco maior do que os tamanhos dos pacotes Vue e React, sendo os pacotes Vue um pouco menores do que os pacotes React. Além disso, vale a pena notar que a equipe de desenvolvimento angular está otimizando constantemente o tamanho de seus pacotes de código (fonte).

Consulte o gráfico abaixo para obter os números aproximados.

Angular, React e Vue oferecem um ótimo desempenho em tempo de execução, e cada um é igualmente adequado para ser o backbone para sites complexos e geradores de receita com tráfego intenso.

As métricas TTI e LCP da Lighthouse

Lighthouse é uma ótima ferramenta de teste que retorna valiosos insights de velocidade. Ele identifica possíveis problemas de desempenho e ajuda a otimizar os vários aspetos de um site. Uma pontuação de farol é calculada com base em uma média ponderada de várias métricas (vá aqui para um resumo completo). Ainda assim, o maior Contentful Paint (LCP), Time to Interactive (TTI) e o Cumulative Layout Shift (CLS) são muito provavelmente os mais importantes da perspetiva do usuário. O TTI e o LCP estão diretamente ligados com a velocidade de carga percebida.

O TTI é uma boa representação do impactos do tamanho do pacote de um framework na velocidade do SPA, pois o pacote precisa ser avaliado inteiramente antes que um usuário possa interagir com o aplicativo. Sites com um TTI longo mostrarão várias partes do site durante o carregamento, mas não permitirão que os usuários interajam com ele, o que pode levar à frustração.

A métrica LCP, por outro lado, mede quanto tempo leva até que o maior elemento do conteúdo da página seja renderizado na tela.

Lighthouse vs. Crux dados de navegação da vida real

Vale a pena notar que as ferramentas de medição de velocidade sintéticas (como o Lighthouse) não contam a história completa. A velocidade do site é mais sobre como o site “se sente” quando os usuários navegam por ele. Uma pontuação de desempenho do Lighthouse é um bom ponto de referência, mas é um pouco arbitrário e difícil correlacionar-se a uma experiência do mundo real. Por exemplo, é difícil traduzir o quanto melhor seria uma pontuação de desempenho de 60, em termos de experiência do usuário, em comparação com uma pontuação de 50.

Testes sintéticos também tendem a simular dispositivos e conexões mais antigos (por exemplo, Lighthouse simula conexões 3G), enquanto na realidade, a maioria dos usuários móveis está em redes LTE rápidas ou até 5G.

Um site rodando em uma estrutura específica pode “sentir” mais rápido, mas perder para outros sites em relação à sua pontuação de desempenho bruto e vice-versa. Isso se deve principalmente a truques específicos (por exemplo, carregamento lento) que cada framework emprega para melhorar a rapidez com que o site “se sente” para os usuários.

Nas próximas seções, analisaremos as oportunidades que cada um desses frameworks oferece para melhorar o desempenho do site.

Angular

O Angular estende o código HTML com novas tags e atributos e interpreta os atributos para executar a vinculação de dados.

Devido aos seus recursos avançados, o aplicativo de trabalho pode ser muito maior (aproximadamente 500KB) em comparação com Vue ou React, o que pode impactar ligeiramente o desempenho.

Abstração MVC do Angular (fonte )

Aqui está um resumo rápido dos principais benefícios do Angular.

  • Geração de código. O Angular gera código altamente otimizado para máquinas virtuais JavaScript, dando os benefícios do código escrito à mão. Modelos HTML combinados com JavaScript abrem a porta para otimizações impossíveis em outros frameworks, por exemplo, React.
  • Divisão de código. Graças ao Component Router, as aplicações Angular são carregadas rapidamente, proporcionando divisão automática de código. Dessa forma, os usuários carregam o código necessário para renderizar a exibição que eles solicitam.
  • DOM real. O Angular usa DOM real; portanto, é mais adequado para aplicativos de página única, onde o conteúdo é atualizado apenas de tempos em tempos, não aqueles que mudam frequentemente, como a maioria dos sites de comércio eletrônico. Manipular o DOM virtual é muito mais rápido porque nada é desenhado na tela.

Reagir

Criado e desenvolvido pelo Facebook, o React é um dos mais populares frameworks de aplicativos móveis de código aberto. Ele não fornece uma ampla gama de bibliotecas; portanto, seu tamanho é significativamente menor do que o do Angular.

Com dados de direção única, o React permite um melhor controle sobre o projeto – ao projetar um aplicativo, os desenvolvedores do React podem aninhar componentes filhos em componentes pai de ordem superior.

React oferece algumas caraterísticas interessantes, incluindo:

  • DOM virtual: Os nós são re-renderizados apenas conforme necessário. O React compara os novos dados com o DOM original e atualiza a visualização automaticamente. Isso melhora o desempenho de aplicativos de todos os tamanhos que precisam de atualizações regulares de conteúdo.
  • Vinculação de dados unidirecional: O React usa a vinculação de dados unidirecional com a arquitetura de aplicativos do Flux Controls. O ReactJS ajuda a atualizar a exibição para o usuário e o Flux controla o fluxo de trabalho do aplicativo. O DOM virtual adiciona vantagens à medida que compara os novos dados com o DOM original e atualiza a visualização automaticamente.
  • Suporte para agrupamento e tremidação de árvore : Minimiza a carga de recursos do usuário final.
  • Suporte a renderização do lado do servidor (SSR): Oferecendo ganhos de velocidade em implementações específicas.

Em maior medida do que o Angular e o Vue, o React utiliza determinadas técnicas que tornam a página “mais rápida” para os usuários finais. Por exemplo, a estrutura prioriza a entrada do usuário sobre a renderização de conteúdo na página.

Vue

O Vue é rápido e muito pequeno com cerca de 30KB (gzipado), o que resulta em primeiras cargas mais rápidas. Isso o torna o menor de todos os três frameworks e acelera significativamente o desempenho de sites executados no Vue.

Vue oferece:

  • Renderização do lado do servidor (SSR)
  • Árvore que treme
  • Agrupamento
  • DOM virtual: As alterações dentro de um projeto não afetam o DOM corretamente. Modificar o DOM real é uma tarefa intensiva de recursos, então as atualizações são aplicadas primeiro ao DOM virtual.

Confira este relatório detalhado de benchmark para comparar tempos de inicialização, alocação de memória e a duração de operações específicas nos principais frameworks e bibliotecas JavaScript. Comparado ao React, o Vue é um pouco melhor em termos de alocação de memória e tempos de inicialização, embora o React seja um pouco mais rápido em termos de tempo de execução.

Angular e Vue usam modelos HTML combinados com JavaScript. Isso lhes dá espaço extra para otimização React não oferece. Por exemplo, o Vue rastreia dependências impedindo renderizações desnecessárias de componentes filhos.

Otimização Vue vs. React vs. Angular SPA

Sabemos que benchmarks e pontuações de desempenho não contam toda a história. A velocidade do site pode variar dependendo do tamanho do aplicativo e seus esforços de otimização. Aqui estão algumas ideias para ajudar a otimizar os spas Vue, React e Angular para velocidade.

1. Renderização do lado do servidor (SSR)

No geral, existem quatro benefícios principais de usar SSR com sites DE SPA:

  • SSR permite carregar rapidamente um MODELO SPA e exibir conteúdo para o usuário (embora o usuário possa não ser capaz de interagir com ele imediatamente). Sem SSR, os usuários olhavam para uma tela vazia, esperando que o conteúdo fosse carregado e renderizado no navegador.
  • SSR reduz a carga na máquina do usuário final.
  • Como o Google agora pode rastrear adequadamente o CONTEÚDO DO SPA, a renderização do lado do servidor pode não ser tão importante para SEO como costumava ser. Mas o benefício de usar SSR é que muitos outros mecanismos de busca ainda não entendem JavaScript e não conseguem rastrear sites com JavaScript pesados corretamente.
  • As redes sociais muitas vezes não conseguem exibir adequadamente o conteúdo compartilhado a partir de sites DE SPA renderizados pelo cliente. Por exemplo, o raspador do Facebook depende apenas das meta tags definidas pelo servidor e não funciona com meta tags renderizadas do lado do cliente. Para controlar melhor a aparência do seu SITE SPA quando compartilhado através do Open Graph, SSR é uma obrigação.
  • AMP acelera as primeiras cargas em dispositivos móveis, mas não permite que você use JavaScript. É impossível renderizar AMP do React no cliente, ele deve ser feito no servidor. No entanto, mesmo com o SSR no lugar, há um monte de aros para saltar através para converter um aplicativo React em um aplicativo AMP válido. Felizmente, alguns frameworks frontend, como React Storefront, podem lidar com tudo para você.

O SSR funciona melhor para sites estáticos, mas os sites DE eCommerce SPA ainda são cacheáveis, com a infraestrutura certa. Com Layer0, o conteúdo é renderizado no lado do servidor e depois armazenado em cache na borda com nosso CDN-as-JavaScript. Dessa forma, sites de grande escala orientados por banco de dados, como spas de comércio eletrônico com milhares ou milhões de páginas, personalização, inventário em tempo real e muito mais, podem encantar os usuários com cargas de páginas de sub-segundos desde o desembarque até o checkout.

O service worker CDN-as-JavaScript (chamado Layer0 Workers) busca dados dinâmicos de forma inteligente da borda antes que seu visitante toque em um link e o transmita para o navegador, com base no que eles provavelmente irão tocar.

As ferramentas de rede e monitoramento Layer0 garantem que os dados dinâmicos sejam armazenados em cache pelo menos 95% do tempo, protegendo seu banco de dados das solicitações extras criadas por pré-busca. Dessa forma, você pode fornecer cargas de páginas de sub-segundos, oferecendo aos seus visitantes uma experiência perfeita desde o desembarque até o checkout.

Ferramentas de rede e monitoramento Layer0

Em geral, em relação aos recursos de SSR e à documentação detalhada, o Vue é superior ao React, que precisa de bibliotecas de terceiros (por exemplo, Next.js) para renderizar páginas do lado do servidor.

2. AMP

AMP cria experiências melhores e mais rápidas na web móvel, simplificando o HTML e aplicando limitações rigorosas em CSS e JavaScript. Essas páginas são então armazenadas em cache e pré-renderizadas no servidor do Google, o que torna a transição para o seu aplicativo quase instantânea.

A desvantagem é que é diferente de como você escreve um PWA/SPA e significa uma reescrita completa do aplicativo, a menos que você use uma estrutura dedicada com suporte a AMP integrado, como React Storefront.

As PÁGINAS AMP têm cargas de página medianas de 500ms para tráfego proveniente do SERP do Google. Essas velocidades são possíveis porque os servidores do Google pré-obtêm e prerenderizam o conteúdo AMP para o navegador de um usuário antes de clicar no link da página AMP. O site de comércio eletrônico médio recebe uma grande parte do seu tráfego a partir da pesquisa do Google (orgânica e paga), para que esses ganhos possam ter um impactos enorme.

Os sites que usam AMP também veem taxas de rejeição reduzidas, já que os usuários que normalmente podem saltar enquanto esperam que uma página carregue agora serão atendidos com uma experiência extremamente rápida.

3. Divisão de código

Seu aplicativo de página única crescerá ao longo do tempo à medida que você continuar a adicionar recursos. Mas sabemos que cada aplicativo tem alguns recursos que dificilmente são usados e desnecessariamente desaceleram. Você deve implementar a divisão de código para manter seu aplicativo o mais rápido possível.

A divisão de código envolve a criação de pacotes separados para cada componente de nível superior em seu aplicativo. No caso de um eCommerce SPA, haverá pacotes separados para a página inicial, listas de produtos e páginas de descrição do produto. Desta forma, quando um usuário chega ao seu aplicativo através de um link para um produto específico, o navegador não precisa baixar e executar o código para todas as páginas anteriores, cortando assim os tempos TTI e FID.

Com a divisão de código, o aplicativo pode “lazy-load” outros componentes de página em segundo plano e usá-los se o usuário decidir navegar neles. Isso economiza largura de banda e diminui o primeiro atraso de entrada ou FID (nota que o FID é frequentemente aproximado pelo tempo para métrica interativa ou TTI), melhorando a velocidade do seu site e classificação do mecanismo de pesquisa.

4. Carregamento lento

Vue, React e Angular suportam carregamento lento, o que, em combinação com SSR, pode fornecer melhorias significativas na velocidade.

O carregamento lento apresenta um desafio ao implementar SSR. O servidor deve saber quais componentes foram usados para renderizar o HTML de saída e enviar o código para esses componentes ao lado do HTML. Caso contrário, o aplicativo precisará montar no navegador e executar dois ciclos de renderização antes de estar pronto para ser interativo, o que aumentará o FID (e TTI), o que pode levar ao conteúdo flash ou jank.

Carregamento lento e SSR estão conetados. A biblioteca que você escolher para carregamento lento (por exemplo, React Loadable )afetará como você gera o HTML final enviado de volta na resposta. Para capturar os pacotes que precisam ser carregados para hidratar o HTML que foi renderizado no servidor, você precisará <adicionar loadable.capture></loadable.capture> para o seu código SSR, em seguida, use a função getBundles do React Loadable para descobrir qual <script><as tags /script> precisam ser adicionadas ao corpo do documento.

Como as dicas do cliente de carregamento lento ainda não são suportadas globalmente por todos os navegadores, existem algumas soluções alternativas para implementar o carregamento lento sem problemas.

Solução n.o 1

Em vez de renderizar as imagens do lado do servidor, você pode deixá-las preencher o lado do cliente quando o aplicativo for montado.

Solução n.o 2

Use apenas carregamento lento para imagens “abaixo da dobra”, ou seja, aqueles que você sabe não serão visíveis imediatamente após o carregamento. Isso é desafiador porque a linha de dobra pode mover-se para cima e para baixo dependendo do dispositivo do usuário e do tamanho da tela. No entanto, algumas heurísticas ajudam. Por exemplo, em uma página de categoria de comércio eletrônico, você pode desativar o carregamento lento para o primeiro conjunto de imagens de produto (elas provavelmente estarão “acima da dobra)”. E para os itens que você sabe que estarão consistentemente acima da dobra (por exemplo, cabeçalhos, logotipos da empresa, ícones de carrinho), você não deve habilitar o carregamento lento de qualquer maneira e sempre pode renderizá-los no lado do servidor.

Solução n.o 3

A deteção do agente do usuário pode ajudar a fornecer uma versão apropriada da página renderizada pelo SSR. A deteção de user-agent geralmente não é recomendada para implementar o aprimoramento progressivo, mas faz o truque como uma solução temporária enquanto os navegadores pegam e implementam dicas de cliente.

Essa solução requer que você normalize suas chaves de cache adequadamente; caso contrário, você pode fragmentar seu cache significativamente.

5. CDN moderno

Otimizar seu SPA para velocidade e usar uma boa CDN em cima disso aumentará seu site, mas não é suficiente para alcançar velocidades abaixo de segundo. Isso ocorre porque a maioria dos CDNs tradicionais só são bons em armazenar arquivos estáticos em cache, mas no geral eles não lidam tão bem com dados JSON/HTML/SSR, enquanto isso é exatamente do que os sites DE eCommerce SPA são feitos. Tornar esses sites mais rápidos requer várias tecnologias da web funcionando de forma eficiente em uníssono. Ao contrário de outros CDNs, o CDN com reconhecimento de aplicativos Layer0 funciona bem com spas de comércio eletrônico. Ele otimiza as taxas de acerto do cache para níveis inéditos e traz inteligência para a borda. Isso ajuda os proprietários de negócios a decifrar tendências e oportunidades de otimização categorizando páginas semelhantes como tais (por exemplo, PDP, PLP e Cart) em vez de apenas exibir uma lista interminável de URLs. Isso permite que você tome medidas e veja uma diferença nos tempos de carregamento do site.

Mas o mais importante, o CDN-as-JavaScript usa técnicas avançadas de pré-busca preditiva para transmitir dados armazenados em cache da borda para os navegadores dos usuários antes que eles toquem em qualquer coisa. Isso mantém os sites 5 segundos à frente dos toques dos compradores, permitindo que eles encantem os usuários com uma experiência de navegação instantânea.

6. Ferramentas móveis

O Angular é ótimo para a construção de aplicativos móveis. Você pode usar a estrutura para criar um aplicativo da Web que seja executado em qualquer dispositivo ou desenvolver aplicativos nativos do iOS e Android combinando o Angular com o NativeScrip. Isso permite reutilizar conceitos angulares, como vinculação de dados, injeção de dependência, serviços e roteamento.

React Native é considerado o rei do desenvolvimento multiplataforma. Ele permite que os desenvolvedores reutilizem até 99% do código JavaScript entre Android e iOS com componentes semelhantes ao React. Isso significa que os desenvolvedores podem criar widgets 100% nativos que controlam seu próprio estilo. A estrutura lida com a camada View como uma saída de estado puro, o que facilita a criação de aplicativos complementares para iOS/Android com um visual e desempenho nativos.

Embora o Vue esteja atrás do React, ele ainda oferece várias soluções valiosas para o desenvolvimento móvel. Por exemplo, o NativeScript permite gravar aplicativos Vue e compilá-los em aplicativos nativos iOS/Android.

Então vem Vue Native. A estrutura combina as vantagens dos ecossistemas Vue e RN, renderização declarativa, ligação bidirecional e um conjunto de componentes básicos para a criação de um aplicativo nativo multiplataforma.

Os spas são mais rápidos, mas ainda têm problemas de velocidade

O fascínio original de um aplicativo de página única é que as páginas subsequentes não recarregam durante a navegação, levando a uma experiência de navegação mais rápida e sem atrito. Mas os frontends modernos DO SPA são apenas parte da solução da velocidade do local, e um par de problemas ainda precisam ser abordados:

  • Benchmarks e testes de velocidade sintéticos não contam necessariamente toda a história. A velocidade desses frameworks pode variar dependendo do tamanho do aplicativo e de seus esforços de otimização.
  • Embora várias tecnologias de frontend de ponta, incluindo aplicativos web progressivos, spas e AMP, possam melhorar drasticamente a experiência do cliente, a velocidade do site é um problema de pilha completa. Ele abrange o navegador, borda e servidor. É por isso que uma solução completa é necessária para acelerar qualquer site, SPA e aplicativo de várias páginas.
  • Todas essas tecnologias podem melhorar as velocidades, mas funcionam melhor quando aplicadas em uníssono. Fazer com que todas essas tecnologias funcionem juntas é uma tarefa complexa que as equipes internas podem não conseguir lidar (por exemplo, requer a criação de uma camada Node.js).

Layer0: Tornando a Web instantânea e simples

Layer0 é uma solução completa para tornar sites de comércio eletrônico mais rápidos e fáceis de desenvolver. Ele combina técnicas avançadas de otimização para acelerar sites em grande escala, baseados em banco de dados, como spas de comércio eletrônico, juntamente com ferramentas poderosas que dão aos desenvolvedores de volta um dia por semana, colocando o código no centro de seus fluxos de trabalho. Layer0 essencialmente traz Jamstack para grandes sites de comércio eletrônico.

Instantâneo: Ao combinar frontends modernos com um CDN-como-JavaScript com uma taxa de acerto de cache de 95% para conteúdo dinâmico na borda e um backend para frontend Node.js, Layer0 ajuda sites complexos a otimizar a velocidade em toda a pilha. É a única plataforma que garante tempos médios de sub-segunda maior pintura de conteúdo (LCP) para sites de comércio eletrônico em grande escala.

Simples: Layer0 (agora Edgio) é a sua plataforma tudo-em-um para desenvolver, implantar, visualizar, experimentar, monitorar, e execute o frontend que permite:

  • Utilize Jamstack para eCommerce através de renderização pré e just-in-time
  • Ative a rede de latência zero por meio de pré-busca de dados de APIs de catálogo de produtos
  • Configure o EDGE nativamente em seu aplicativo (CDN-as-JavaScript)
  • Execute regras de borda localmente e em pré-prod
  • Crie URLs de visualização a partir do GitHub, GitLab ou BitBucket com cada novo branch e push
  • Execute divisões na borda para testes A/B de desempenho, implanta canary e personalização
  • JavaScript sem servidor que é muito mais fácil e confiável do que o AWS Lambda

Conclusão

Executar um site mais rápido não é apenas um truque extravagante. No final do dia, você não está apenas tentando impressionar seus usuários, mas também tentando agradar o maior motor de busca do mundo. Como a classificação do Google em breve será determinada, em parte, pela velocidade da página, ela não pode ser tomada de ânimo leve. Um site rápido significa que aumenta seus rankings e conversões de SEO, o que, por sua vez, gera mais receita.

Embora muito possa ser dito sobre o desempenho de cada framework, há três pontos a serem lembrados:

  1. As diferenças reais no desempenho do framework podem ser minúsculas. O desempenho dos SITES DE SPA depende de tantas variáveis que é impossível comparar esses frameworks lado a lado de forma significativa.
  2. Se você estiver no Angular, Vue ou React, ainda há muito espaço para melhorias.

Tornar os spas mais rápidos requer uma combinação de tecnologias web avançadas que funcionam em uníssono, e suas equipes internas podem não ser capazes de implementá-los de forma eficiente. Felizmente, alguns fornecedores inovadores, incluindo Layer0, fizeram o trabalho pesado para você.

Layer0 combina renderização do lado do servidor com pré-busca preditiva avançada e pré-cache na borda. Como os dados dinâmicos são armazenados em cache pelo menos 95% do tempo, seu banco de dados é protegido das solicitações extras criadas por pré-busca. Layer0 CDN-as-JavaScript service worker busca inteligentemente suas páginas dinâmicas antes que seu visitante toque em um link. Dessa forma, você pode fornecer cargas de páginas secundárias em aplicativos de página única, oferecendo aos seus visitantes uma experiência perfeita desde o desembarque até o checkout.