Na corrida de hoje para acelerar o tempo de carregamento do site, cada milissegundo importa. A equipe da Kinsta testou e estudou o impacto da velocidade do site nas vendas, conversões, experiência do usuário e envolvimento do usuário.

Mas há uma advertência. Embora a otimização no local seja importante para melhorar a velocidade, não é o único aspecto que devemos considerar. A infraestrutura de hardware e rede que suporta o nosso site e o liga aos nossos visitantes é importante.

Hoje vamos discutir porque é que o Google está investindo muito dinheiro na sua infraestrutura de rede e algumas das diferenças na rede de nível Premium e na rede de nível Standard do Google Cloud Platform.

Largura de banda e latência (critérios chave para o desempenho da infraestrutura de hospedagem)

Antes de mergulhar em detalhes sobre a rede do Google Cloud, é importante entender primeiro os dois conceitos a seguir: largura de banda e latência.

A largura de banda é a capacidade de throughput da rede, medida em Mbps; enquanto a latência é o atraso ou a soma de todos os atrasos que diferentes roteadores ao longo do caminho adicionam às nossas solicitações e respostas web.

Figurativamente, a largura de banda ou a capacidade de passagem pode ser retratada como largura do tubo de água para permitir a passagem de um certo volume de água por segundo. A latência pode ser comparada ao atraso a partir do momento em que o tubo de água é aberto até começar a jorrar através dele.

Devido à pequena sobrecarga no estabelecimento da conexão entre diferentes roteadores, cada “salto” ao longo do caminho adiciona uma pequena quantidade de latência às solicitações e respostas finais.

Assim, quanto mais distante estiver o visitante e o servidor onde o site está hospedado, maior será a latência. Além disso, quanto mais fragmentada for a rede, maior será a latência.

Podemos imaginar isto usando uma ferramenta chamada traceroute, ou tracert nas janelas. Nas capturas de ecrã seguintes, utilizámo-lo para controlar os atrasos de encaminhamento de dois pedidos, feitos a partir da Europa. Especificamente:
um para weibo.com:

Weibo.com
Weibo.com

e outro para bbc.co.uk:

Bbc.co.uk
Bbc.co.uk

Como esperávamos, o número de saltos para o site na China é quase 2x maior do que para o europeu. Então é a latência adicionada comparada a um pedido para um site hospedado no Reino Unido.

As três colunas que o tracert mostra representam três roundtrips (RTT). Cada linha representa diferentes roteadores ou saltos ao longo do caminho. Eles geralmente têm URLs que nos ajudam a determinar onde esse roteador específico está localizado.

O tempo de ida e volta para os roteadores na China / Hong Kong leva cerca de um terço de segundo.

Nós usamos pingdom para carregar um site hospedado em Londres a partir da localização de Pingdom na Austrália, para tentar estabelecer o compartilhamento que a rede tem nos tempos de carregamento geral de um site.

Exemplo de tempos de carga
Exemplo de tempos de carregamento

Estes são os dados de um pequeno arquivo CSS carregado neste cenário de teste. A parte Connect tem a maior participação no carregamento desse recurso, seguida por SSL e Espera. TTodo o tempo até lá, incluindo o tempo de espera, também é conhecido como tempo de primeiro byte (TTFB), que inclui a latência da rede.

Quando os Provedores de Serviços de Internet anunciam a velocidade da conexão de internet, eles normalmente anunciam em sua largura de banda (a “largura do tubo” lembra?) o que realmente não é um medida de velocidade. Aumentar a largura do tubo pode aumentar a velocidade do site apenas até certo ponto. É mais útil quando precisamos de uma grande quantidade de dados enviados por segundo, como quando transmitimos conteúdo de vídeo de alta definição. Mas para os usuários que podem estar jogando jogos multiplayer em tempo real online, a latência será muito mais importante.

Mike Belshe, um dos coautores da especificação HTTP/2 e do protocolo SPDY, fez uma análise do impacto do aumento da largura de banda na velocidade de carregamento do site vs. o efeito da diminuição da latência na velocidade de carregamento do site.

Aqui estão os achados da Belshe com curadoria em um belo gráfico:

Tempo de carga/alteração de largura de banda vs. Tempo de carga/alterações de latência
Tempo de carregamento/alteração de largura de banda vs. Tempo de carregamento/alterações de latência

Deve ficar claro que melhorar a velocidade do site aumentando a largura de banda não é a forma mais eficaz de alcançar um melhor desempenho. Por outro lado, ao reduzir o RTT (round-trip-time) ou a latência, podemos ver melhorias consistentes do tempo de carregamento da página.

Redes vs Internet Peering vs Transit

Para entender um pouco melhor o nosso tópico, precisamos explicar o básico da topologia da internet. Em sua essência, a internet global consiste em múltiplas redes globais, regionais e locais.

A partir de 2018, existem mais de 60.000 AS (Sistemas Autónomos). Estas redes pertencem a governos, universidades, ISPs.

Entre estas, destacam-se as redes Nível 1, Nível 2 e Nível 3. Estes níveis representam a independência de cada rede na Internet como um todo.

  • As redes de nível 1 são independentes, no sentido de que não têm de pagar para se ligarem a qualquer outro ponto da Internet.
  • As redes de nível 2 têm acordos de peering com outros ISPs, mas também pagam pelo trânsito.
  • As redes de nível 3, o nível mais baixo, ligam-se ao resto da Internet através da compra de trânsito a partir de níveis mais elevados. São praticamente como consumidores que têm de pagar para aceder à Internet.

A relação de peering significa que duas redes trocam tráfego numa base de igualdade, pelo que nenhuma delas paga à outra pelo trânsito, e devolvem o mesmo gratuitamente.

O principal benefício do peering é uma latência drasticamente mais baixa.

Como as solicitações web passam pela rede hierárquica dos ISPs
Como as solicitações web passam pela rede hierárquica dos ISPs

Na imagem acima, vemos um cenário clássico, em que o pedido web passa pela rede hierárquica de ISPs nos níveis 1, 2 e 3 para recuperar um site hospedado em um diretório num centro de dados numa localização remota.

As setas representam o percurso do pedido web. Setas tracejadas representam as conexões de trânsito, e setas de linha cheia representam as conexões de peering.

Uma vez alcançado o prestador de serviços de nível 1, a sua relação com outro prestador do mesmo nível é uma relação entre pares. As redes Nível 1 ligam-se a outras e transmitem os seus pedidos exclusivamente através de parceiros peering. Podem chegar a todas as outras redes na Internet sem pagar pelo trânsito.

Também podemos ver um cenário alternativo, em que dois provedores de nível 2 têm um acordo de peering, designado com cor turquesa. O número de saltos neste cenário é menor e o site levará muito menos tempo para carregar.

Protocolo Gateway de Fronteira (BGP)

O BGP é um protocolo sobre o qual raramente se fala, excepto em contextos muito técnicos. No entanto, este protocolo está no cerne da Internet tal como a conhecemos hoje. É fundamental para a nossa capacidade de aceder a praticamente tudo na Internet e é uma das ligações vulneráveis da pilha de protocolos da Internet.

O Protocolo de Gateway de Fronteira é definido em IETFs Request For Comments #4271 de 2006 e desde então tem tido várias atualizações. Como diz o RFC:

“A principal função de um sistema de fala BGP é trocar informações sobre a acessibilidade da rede com outros sistemas BGP.”

Simplificando, o BGP é um protocolo responsável por decidir a rota exata de uma solicitação de rede, sobre centenas e milhares de nós possíveis até seu destino.

Protocolo de Gateway de Fronteira
Protocolo de Gateway de Fronteira

Podemos imaginar cada nó como um Sistema Autônomo ou uma rede que consistiria de vários nós ou roteadores, servidores e sistemas conectados a ele.

No protocolo BGP, não há nenhum algoritmo de auto-descoberta (um mecanismo ou protocolo pelo qual cada nó recém-conectado pode descobrir nós adjacentes para se conectar), em vez disso, cada par BGP tem que ter seus pares especificados manualmente. Quanto ao algoritmo de caminho, para cita um especialista da Cisco:

“O BGP não tem uma métrica simples para decidir qual é o melhor caminho. Em vez disso, ele anuncia um extenso conjunto de atributos com cada rota e usa um algoritmo complexo que consiste em até 13 passos para decidir qual é o melhor caminho.”

Os sistemas autónomos transmitem dados de encaminhamento aos seus pares, no entanto, não existem regras rígidas que possam ser aplicadas relativamente à selecção dos canais horários. O BGP é um sistema implicitamente baseado na confiança e esta pode ser uma das maiores falhas de segurança da Internet de hoje. Roubo em 2018, quando O tráfego do MyEtherWallet.com foi sequestrado e mais de 200 Éteres foram roubados (valor de US$ 152.000) expondo essa vulnerabilidade.

Na realidade, esta fraqueza do BGP resulta mais frequentemente em várias redes (AS) que emitem dados BGP com outros interesses em mente que não a eficiência e a eficiência velocidade para usuários finais. Podem ser interesses comerciais, como trânsito pago, ou mesmo considerações políticas ou de segurança.

Desenvolvimento da computação em nuvem, CDN e Mercado de edge

Devido às necessidades crescentes do mercado de TI, desde a indústria web, jogos online, até a Internet das Coisas e outros, o espaço de mercado para provedores de serviços e produtos que resolvem o problema da latência tornou-se óbvio.

Ano após ano, vemos mais produtos baseados em nuvem que armazenam recursos estáticos perto dos visitantes (Content Delivery Networks) ou aproximam a computação real dos usuários finais. Um desses produtos é o Workers da Cloudflare, que executa Código compatível com motores javascript V8 na rede edge nodes do Cloudflare. Isto significa que mesmo o WebAssembly ou o código GO podem ser executados muito perto do visitante.

O [email protected] by Amazon é outro exemplo dessa tendência, assim como a parceria entre a Intel e a Alibaba Cloud para oferecer a Plataforma de Computação Joint Edge visando o mercado IoT.

Outra que vale a pena mencionar é que a rede global do Google de nós de cache serve tanto como uma CDN quanto como uma rede de cache e entrega de vídeo para sua subsidiária YouTube.

Para ilustrar o quão refinada e avançada a indústria da nuvem se tornou, e o quanto ela conseguiu reduzir a latência de rede para usuários finais, vamos dar uma olhada no GaaS.

GaaS é a abreviatura de Gaming as a Service. É uma oferta de nuvem que dá aos usuários a capacidade de jogar jogos hospedados e executados na nuvem. Este artigo compara alguns produtos proeminentes no nicho GaaS.

Todos aqueles que já compraram uma TV ou um projetor de vídeo para jogos, ou passaram algum tempo configurando o Miracast ou outra conexão de fundição entre uma TV e outro dispositivo, saberão o quão crítica é a latência. No entanto, existem provedores de GaaS que agora oferecem streaming de jogos com resolução de 4k e taxa de atualização de 60Hz… e os jogadores não precisam investir em hardware.

O drama da recente proibição da Huawei pelos EUA chamou a atenção para a questão das redes 5G e para a necessidade urgente de uma via clara para melhorar a infraestrutura mundial de redes.

Sensores que transmitem enormes quantidades de informação em tempo real, com latência mínima, para coordenar cidades inteligentes, casas inteligentes, veículos autônomos dependerão de redes densas de dispositivos de ponta. Latência é o teto atual para coisas como carros automotores, com diferentes informações de sensores, dados LIDAR, processamento destes dados vs dados de outros veículos.

Content Delivery Networks e Cloud Computing Providers estão na vanguarda desta corrida. Já falámos sobre o Protocolo QUIC / HTTP3 a ser implementado pelos líderes da indústria capazes de controlar o ciclo de resposta ao pedido.

Como os provedores de nuvem resolvem o problema da latência?

A AWS pode ser o maior provedor de nuvem por participação de mercado. Em 2016, eles investiram no Sistema de Cabo Submarino Transpacífico da Hawaiki com o objetivo de proporcionar maior largura de banda e diminuir a latência entre o Havaí, Austrália e Nova Zelândia, que foi seu principal objetivo. primeiro investimento em infraestrutura submarina. Ele… entrou em funcionamento em 2018.

Cabos de fibra óptica submarina
Cabos de fibra óptica submarina (Fonte de imagem: NEC)

Nessa altura, o Google já estava muito à frente da sua concorrência na criação de espinhas dorsais submarinas. Um ano antes do primeiro investimento da Amazon, a ITWorld publicou um artigo intitulado: “Os data centers do Google crescem muito rápido para redes normais e, por isso, criam suas próprias redes”.

Na verdade, foi em 2005 que um jornalista técnico Mark Stephens, também conhecido como Robert X Cringely escreveu no seu coluna para PBS.org, comentando sobre a onda de compras do Google do fibra escura (infraestrutura de fibra ótica não utilizada):

“Isto é mais do que outra Akamai ou mesmo uma Akamai com esteróides. Esta é uma Akamai dinâmica, inteligente e termonuclear, com um canal de retorno dedicado e hardware específico para aplicações. Haverá a Internet, e depois haverá o Google Internet, sobreposto no topo.”

Infra-estrutura de cabos de rede em nuvem do Google
Infraestrutura de cabos de rede em nuvem do Google (fonte: Google)

Em 2010, em um artigo no zdnet.com, diz Tom Foremski:

“O Google é uma daquelas empresas que possuem uma grande parte da Internet”, e continua: “O Google concentrou-se em construir a Internet privada mais eficiente e de menor custo de operação. Esta infraestrutura é fundamental para o Google, e é fundamental para compreender o Google.”

Naquela época, o artigo de Cringley levantou algumas preocupações sobre o Google tentando assumir o controle da internet, mas as coisas ficaram mais claras quando a empresa lançou o site Google Fiber, a tentativa do Google de conquistar o mercado de ISP nas maiores cidades dos EUA. Desde então, o projeto desacelerou tanto que a TechRepublic publicou um post mortem do projeto em 2016, mas investimentos em infraestrutura, agora em escala global, não abrandou.

O último investimento do Google, previsto para entrar em funcionamento este ano, é uma espinha dorsal que liga Los Angeles nos EUA e Valparaíso no Chile, com uma filial para a futura ligação ao Panamá.

“A internet é comumente descrita como uma nuvem. Na realidade, é uma série de tubos molhados e frágeis, e o Google está prestes a ter um número alarmante deles”. — VentureBeat

Por que o Google está investindo tanto em sua Infraestrutura de rede?

Roteiro standard
Rota Standard

Todos nós sabemos que O Google é o mecanismo de pesquisa número um, mas também:

É por isso que ele precisa da menor latência possível e da máxima largura de banda possível. Google também quer possuir a infraestrutura real, porque a sua “fome insaciável” por mais largura de banda e latência coloca o Google, e seus pares de empresas de grande escala como a Amazon ou Microsoft, em uma posição onde eles precisam para chegar a soluções de hardware e software completamente personalizado.

Nós PoP
Nodes PoP

Os pontos de presença, ou nodes PoP de ponta (edge), estão na rede global privada de cabo de ponta do Google. Lá eles servem como pontos de entrada e saída para o tráfego que se conecta aos centros de dados do Google.

A Lei de Moore é uma observação de Gordon Moore, co-fundador da Intel, que afirma que a cada dois anos, o número de transistores que podemos colocar em um circuito integrado dobrará. Durante décadas, essa expectativa se manteve verdadeira, mas agora, a indústria da computação está prestes a colocar a lei de Moore à prova, talvez assinando seu fim em um futuro próximo. PARA SUA INFORMAÇÃO, O CEO da NVIDIA proclamou a lei de Moore morta no início deste ano.

Então, como isso se relaciona com o setor de nuvem e com a infraestrutura de rede do Google?

No Open Networking Foundation Connect Event em dezembro de 2018, o vice-presidente do Google e TechLead for Networking, Amin Vahdat, admitiu o fim da lei de Moore e explicou o enigma da empresa:

“A nossa procura de computadores continua a crescer a um ritmo espantoso. Vamos precisar de aceleradores e de um computador mais bem acoplado. O tecido da rede vai desempenhar um papel fundamental na ligação destes dois juntos.”

Uma forma de os provedores de nuvem acompanharem a crescente demanda por poder de computação é o clustering. Clustering, para simplificar, significa reunir vários computadores para trabalhar em um único problema, para executar processos de uma única aplicação. Obviamente, uma pré-condição para beneficiar de tal configuração é a baixa latência ou a capacidade séria da rede.

Quando o Google começou a projetar seu próprio hardware, em 2004, os fornecedores de hardware de rede pensavam em termos de boxes, e roteadores e switches precisavam ser gerenciados individualmente, via linha de comando. Até então, o Google estava comprando clusters de switches de fornecedores como a Cisco, gastando uma fortuna por único switch. Mas o equipamento ainda não conseguiu acompanhar o crescimento.

Cansado do suporte de hospedagem WordPress de nível 1 sem as respostas? Experimente nossa equipe de suporte de classe mundial! Confira nossos planos

O Google precisava de uma arquitetura de rede diferente. A demanda na infraestrutura do Google estava crescendo exponencialmente (um A partir de 2015, o artigo de investigação do Google afirma que a sua capacidade de rede cresceu 100x em dez anos) e o seu crescimento foi tão rápido que o custo de aquisição do hardware existente também os incitou a criar as suas próprias soluções. O Google começou a construir switches personalizados a partir de chips de silício commodity, adotando uma topologia de rede diferente que era mais modular.

Os engenheiros do Google começaram a construir sobre um antigo modelo de rede de telefonia chamado Clos Network, que reduz o número de portas necessárias por switch:

“A vantagem da rede Clos é que você pode usar um conjunto de dispositivos idênticos e baratos para criar a árvore e ganhar alto desempenho e resiliência que de outra forma custaria mais para construir. — Redes Fechadas: O que é velho é novo novamente, Mundo em Rede

Para este novo hardware modular, a equipe do Google teve também de redefinir os protocolos existentes e construir um sistema operativo de rede personalizado. O desafio que eles estavam enfrentando era pegar um grande número de switches e roteadores e operá-los como se fossem um único sistema.

A pilha de rede personalizada juntamente com a necessidade de redefinir protocolos levou o Google a recorrer ao Software Defined Networking (SDN). Aqui está uma palestra de Amin Vahdat, Vice-Presidente do Google, Engineering Fellow e líder da equipe de infraestruturas de rede, a partir de 2015, explicando todos os desafios e as soluções que encontraram:

Para os mais curiosos, há este interessante post de blog vale a pena ler.

Espresso

O expresso é o mais recente pilar da SDN do Google. Permite que a rede do Google vá além das restrições dos routers físicos na aprendizagem e coordenação do tráfego que entra e sai para os parceiros de peering do Google.

O Espresso permite ao Google medir o desempenho das ligações em tempo real e basear a decisão no melhor ponto de presença para um visitante específico em dados em tempo real. Desta forma, a rede do Google pode responder dinamicamente a diferentes congestionamentos, desacelerações ou interrupções nos seus parceiros Peering / ISP.

Além disso, o Espresso torna possível utilizar o poder computacional distribuído do Google para analisar todos os dados de rede de seus pares. Todo o controle e lógica de roteamento não residem mais com roteadores individuais e Border Gateway Protocol, mas são transferidos para a rede de computação do Google.

“Alavancamos nossa infraestrutura de computação em larga escala e os sinais da própria aplicação para aprender como os fluxos individuais estão funcionando, conforme determinado pela percepção de qualidade do usuário final.” — O expresso torna o Google Cloud mais rápido, 2017

Como isso é relevante para a rede do Google Cloud?

O que cobrimos até agora vai destacar todas as questões e desafios (tanto com base em hardware como em software) que o Google atravessou para reunir o que é provavelmente a melhor rede privada global atualmente disponível.

Quando se trata de participação de mercado, o Google Cloud Platform é o terceiro fornecedor global (depois da participação de mercado AWS e da participação de mercado Microsoft Azure). Mas em termos de sua infraestrutura de rede privada premium, deixa seus concorrentes muito para trás, como mostram os dados da BroadBand Now:

Propriedade do cabo submarino
Propriedade do cabo submarino, Setembro de 2018. (fonte: BROADBANDNOW, Centerfield BBN LLC)

Em 2014, a GigaOM publicou um artigo comparando a AWS e o Google Cloud Platform, mas apenas uma semana depois, eles publicaram outro, intitulado: “O que eu perdi no debate entre o Google e a Amazon cloud – fibra!”, onde eles reconhecem que o Google está anos à frente em termos de infraestrutura.

“Ter tubos grandes e rápidos disponíveis para o seu – e para o tráfego dos seus clientes – é um grande negócio.” — Barb Darrow, GIGAOM

Rede de nível Premium do Google vs. Rede de nível Standard do Google

Plataforma Google Cloud Network
Rede do Google Cloud Platform

O Google Cloud Platform oferece dois níveis de rede diferentes que diferem tanto em preço como em desempenho.

Rede de nível Premium do Google

Com a rede de nível Premium do Google, os utilizadores podem tirar partido da rede global de fibra óptica, com Pontos de presença distribuídos globalmente. Todo o tráfego de entrada (inbound) do cliente para os centros de dados do Google é encaminhado para o Ponto de Presença mais próximo, que é distribuído globalmente, e então a solicitação é encaminhada 100% sobre o backbone privado do Google. Como dissemos em um artigo anterior – isso pode significar uma latência 30% melhorada ou uma largura de banda 50% melhor.

No regresso, todos os dados enviados do centro de dados para o visitante são encaminhados utilizando Política Cold Potato. Ao contrário do Roteamento Hot Potato, utilizado na rede de nível Standard, onde o tráfego é, o mais cedo possível, entregue (ou descartado) a outros ISPs, roteamento de nível Premium significa que o tráfego de saída é mantido o maior tempo possível na própria fibra do Google, e é entregue aos colegas ou ISPs de trânsito o mais próximo possível do visitante.

Para pôr as coisas nos termos do leigo. Os pacotes de nível Premium passam mais tempo na rede do Google, com menos oscilações e, portanto, têm melhor desempenho (mas custam mais).

Para os fãs de ficção científica entre nós, pode ser comparado a um wormhole cósmico, que transfere o nosso tráfego diretamente para o nosso destino sem passar pela internet.

Em Kinsta, utilizamos a Rede de Nível Premium do Google Cloud em todos os nossos planos de hospedagem gerenciada de WordPress. Isso minimiza a distância e os saltos, resultando em um transporte global mais rápido e seguro de seus dados.

Arquitetura de hospedagem Kinsta
Arquitetura da hospedagem Kinsta

Rede de nível Standard do Google

Por outro lado, a rede de nível Standard usa pontos de presença próximos ao centro de dados onde nosso conteúdo ou aplicativo da Web reside. Isto significa que o tráfego de nossos visitantes viajará através de muitas redes diferentes, Sistemas Autônomos, ISPs, e através de muitos saltos até chegar ao seu destino. Neste cenário, a velocidade está comprometida.

O conteúdo que viaja no nível Standard não será capaz de colher plenamente os benefícios do SDN do Google e do vasto poder de computação para calcular as melhores rotas dinamicamente. O tráfego estará sujeito às políticas BGP de todos os sistemas entre o Google e o visitante.

Para pôr as coisas nos termos do leigo. Os pacotes de nível Standard passam menos tempo na rede do Google e mais tempo jogando hot potato em redes públicas e, portanto, têm pior desempenho (mas custam menos).

Além disso, o nível Premium utiliza o Global Load Balancing, enquanto o nível Standard oferece apenas o Regional Load Balancing, que traz mais complexidade e mais “footwork” para os clientes Standard .

A rede de nível Premium oferece um Acordo de Nível de Serviço (SLA) global, o que significa que o Google aceita a responsabilidade contratual pela prestação de um determinado nível de serviço. É como um sinal de garantia de qualidade. O nível Standard não oferecem este nível de SLA.

Para aqueles que querem saber mais, há uma extensa comparação e documentação dos dois níveis no site do Google Cloud. Eles até mesmo fornecem um gráfico útil para ajudá-lo a determinar mais facilmente qual nível de rede você deve usar:

Árvore de decisão Network Service Tiers
Árvore de decisão Network Service Tiers. (fonte: Google Cloud Platform)
Quer saber o que está fazendo da Rede do Google Cloud uma das pilhas mais rápidas disponíveis atualmente? Veja detalhadamente a nossa comparação de níveis Premium vs Standard. 🚀☁️ #google cloud networkClick to Tweet

Resumo

Durante anos, o Google investiu na criação de uma infraestrutura de rede global, implementando os seus próprios protocolos e pilhas de rede personalizadas de hardware e software. Em tempos em que a lei de Moore parece se tornar mais fraca ano após ano, a infraestrutura do Google permite que a empresa acompanhe a crescente demanda por recursos de nuvem.

Embora em termos de participação de mercado ainda esteja atrás da Amazon Cloud e da Microsoft Azure Cloud, o Google ganhou alguma vantagem crucial tanto para a fibra que possui, quanto para as soluções de hardware e software de ponta que seus engenheiros implantaram.

Podemos esperar que o Google desempenhe um papel fundamental na tecnologia da IoT, cidades inteligentes, carros sem condutor e a procura de computação de ponta continua a crescer.

A rede de nível Premium do Google Cloud é o primeiro produto a utilizar os resultados de rede inovadores do Google. Permite que os clientes tirem partido da rede do Google e de toda a pilha para fornecerem conteúdos a uma velocidade superior. Com as garantias do Google em relação à latência.

Kinsta é dedicado em fornecer o melhor desempenho de hospedagem gerenciada WordPress em uma escala global. É por isso que Kinsta é alimentado com Google Cloud para hospedagem WordPress e usamos a Rede de nível Premium do Google para todos os nossos planos de hospedagem.


Economize tempo, custos e otimize o desempenho do seu site com:

  • Ajuda instantânea de especialistas em hospedagem do WordPress, 24/7.
  • Integração do Cloudflare Enterprise.
  • Alcance global com 35 centros de dados em todo o mundo.
  • Otimização com nosso monitoramento integrado de desempenho de aplicativos.

Tudo isso e muito mais em um plano sem contratos de longo prazo, migrações assistidas e uma garantia de 30 dias de devolução do dinheiro. Confira nossos planos ou entre em contato com as vendas com as vendas para encontrar o plano certo para você.