Cachorro gordo deitado.

A crise de obesidade dos sites


12/4/16 às 21h04

Nota do editor: Este texto é a adaptação de uma palestra de Maciej Cegłowski realizada em 29 de outubro de 2015. Maciej é um programador que vive em San Francisco, escreve o blog Idle Words, tem um perfil divertidíssimo no Twitter e é fundador e único funcionário do Pinboard, um serviço de favoritos na web.


Deixe-me começar dizendo que sites bonitos existem nos mais diversos formatos e tamanhos. Eu adoro grandes sites cheios de imagens. Eu adoro vídeos em alta resolução. Eu adoro experimentos de JavaScript dispersos ou webapps bem desenhados.

Este artigo não é sobre nenhum deles. Ele é sobre sites com predominância de texto que, por razões inexplicáveis, estão ficando mais pesados a cada ano que passa.

Embora eu use alguns exemplos para evitar que isso fique muito abstrato, não estou aqui para constranger ninguém, exceto algumas empresas (Medium) que deveriam ter uma noção melhor das coisas e estão intencionalmente quebrando a web.

A crise

O que eu quero dizer por uma crise de obesidade dos sites?

Artigo do GigaOm de 2012.

Acima temos uma notícia no GigaOm, de 2012, intitulada “A crescente epidemia de inchaço das páginas”. Ele alerta que uma página na web tem, em média, mais de um megabyte de tamanho.

A notícia em si tem 1,8 megabyte.

Artigo do GigaOm de 2014.

Aqui temos outra notícia quase idêntica, do mesmo site, publicada dois anos depois. O título é “A internet com sobrepeso”. Ela alerta que o tamanho médio das páginas web está se aproximando dos dois megabytes.

A notícia tem três megabytes.

Se essa tendência continuar, existe uma chance real de que as notícias alertando sobre o inchaço das páginas web excederão os cinco megabytes em 2020.

O problema de selecionar qualquer tamanho específico como um limite é que o site notoriamente inchado de hoje se torna a página típica de amanhã e o elegante design enxuto do ano que vem.

Gostaria de ancorar a discussão em algo mais atemporal.

Para repetir uma sugestão que fiz no Twitter, sugiro que sites baseados em texto não devam exceder em tamanho as maiores obras da literatura russa.

Crime e Castigo, de Dostoiévski.

Trata-se de um critério generoso. Eu poderia ter escolhido a literatura francesa, cheia de livros curtinhos, mas intencionalmente escolhi os romances russos e sua reputação de livros pesados. No Oblomov de Goncharov, por exemplo, o personagem que dá nome ao livro gasta as cem primeiras páginas apenas para sair da cama.

Se você abrir aquele tweet num navegador, verá que a página pesa 900 KB. Isso é quase 100 KB a mais que o texto completo de O Mestre e a Margarida, o romance divertido e enigmático de Bulgakov sobre o demônio que visita Moscou com seu séquito (acompanhado por um gato gigante!) durante o Grande Expurgo de 1937, intercalado com uma visão curiosa das vidas de Poncio Pilatos, Jesus Cristo e o devoto, mas não confiável apóstolo Mateus.

Por um único tweet.

Ou considere este artigo do Medium de 400 palavras sobre o inchaço da web, que inclui a frase:

“Equipes que não entendem para quem estão construindo, e por que, tendem a criar produtos inchados.”

A equipe do Medium fez este pedaço de pensamento demandar 1,2 megabyte.

Isso é maior que Crime e Castigo, o suspense psicológico de Dostoiévski sobre um estudante empobrecido que enche sua cabeça com pensamentos sobre Napoleão e se convence a matar uma agiota já idosa. Atormentado pela culpa, tão confuso por seu crime que ele até mesmo se esquece de pegar o dinheiro, Raskolnikov se vê perseguido em um jogo de gato-e-rato por um investigador astuto e encontra a redenção no improvável amor de uma santa prostituta.

Dostoiévski escreveu tudo isso à mão, sob a luz de velas, com uma maldita pena.

Aqui temos um artigo recente chamado “Uma (não tão) breve história do inchaço das páginas web”. Ensaiando os motivos mais comuns pelos quais o inchaço é ruim, ele inclui a frase “páginas pesadas tendem a ser páginas lentas, e páginas lentas significam usuários insatisfeitos”.

Essa frase deve te trazer à mente a famosa frase inicial de Anna Karenina:

“Todas as famílias felizes se parecem, cada família infeliz é infeliz à sua maneira.”

Mas a não tão breve história do inchaço é muito maior que Anna Karenina.  Na verdade, é maior que Guerra e Paz, a exploração de Tolstói sobre se homens e mulheres podem determinar grandes eventos da história ou se somos simplesmente arrastados pelo irresistível curso da inevitabilidade histórica.

Aqui está um artigo do Yorkshire Evening Post parecido com outros milhares de sites de notícias locais. Ele não explora a relação entre história e a vontade individual de forma nenhuma: “Administração do Hospital de Leeds pede desculpas após servir curry e compota no mesmo prato”.

Notícia sobre comidas que se tocaram no hospital em Leeds.

A comovente história de duas comidas se tocando num prato de hospital quase poderia ter sido escrita por Marcel Proust, para quem o ato de mergulhar um pedaço de biscoito em uma xícara de chá era o início de uma crescente espiral de memórias vívidas, culminando na realização, nove volumes e três megabytes de prosa escrita depois, de que o tempo e a memória por si são apenas ilusões.

Sozinho, o JavaScript de “Administração do Hospital de Leeds pede desculpas após servir curry e compota no mesmo prato” é maior que Em Busca do Tempo Perdido.

Eu poderia continuar fazendo isso. E eu vou, porque é divertido!

Artigo do Tutsplus sobre otimização de páginas web.

Aqui temos um artigo de instruções das “Melhores práticas para aumentar o desempenho online” que pesa 3,1 MB. O artigo menciona que o Google conseguiu aumentar o engajamento dos usuários no Google Maps ao reduzir o peso de sua página de 100 KB para 80 KB.

Lembra quando o Google Maps, o webapp mais sofisticado de seu tempo, era 35 vezes menor do que uma notícia moderna?

A obesidade da web pode atacar nos lugares mais surpreendentes.

Tim Kadlec, por exemplo, é um excelente escritor do assunto desempenho. Seu site pessoal é um modelo de parcimônia. Ele é cheio de sabedoria sobre o assunto redução do inchaço. Mas os slides da sua recente palestra sobre desempenho só estão disponíveis como uma página de nove megabytes ou um PDF de 14 megabytes.

Nove megabytes por alguns slides.

Deixe-me fechar com um adorável artigo do Techtimes alertando que o Google passará a rotular páginas enormes como “lentas” na interface móvel do buscador.

O artigo, de alguma forma, consegue pesar 18 megabytes, incluindo (na página que mensurei) um vídeo de três megabytes de KY, um “lubrificante íntimo”.

Artigo pesado do Techtimes alertando sobre riscos de páginas pesadas na web.

É necessário muito lubrificante íntimo, hoje, para navegar na web sem filtros.

O que raios está acontecendo?

Falsas soluções

Todo mundo admite que há um problema. Essas páginas já são bem ruins no meu notebook (meu cooler trabalhou ininterruptamente nas três semanas inteiras em que preparei esse texto), mas elas são um inferno em dispositivos móveis. Por isso, as publicações estão se mexendo.

Em maio de 2015, o Facebook apresentou os “Instant Articles”, um formato especial para notícias projetado para ser mostrado dentro do próprio app do Facebook e carregar quase instantaneamente.

O Facebook fez este anúncio em uma página de 6,8 megabytes, dominada por uma foto enorme do rosto de um cara. Ele nem trabalha para o Facebook, é só o editor de fotografia da National Geographic.

Mais abaixo na página você encontra um vídeo de 41 megabytes, a única forma de descobrir mais sobre o projeto. No vídeo, esse editor descreve com entusiasmo os não-recursos do novo formato instantâneo, como o de inclinar o celular para visualizar imagens, o que significa que se você não segurá-lo direito as fotos vão balançar como um documentário do Ken Burns.

O Facebook também lançou o Internet.org, um esforço para expandir o acesso à Internet. A surpreendente página inicial inclui histórias de pessoas de vários países em desenvolvimento e o que o acesso à Internet tem significado para elas.

Você sabe o que vem a seguir. Larguei a página inicial do Internet.org aberta no Chrome durante o almoço e, quando eu voltei, descobri que ela havia transferido mais de um quarto de gigabyte de dados.

Página inicial do Internet.org do Facebook.

Certamente, você dirá, não tem como o globo no fundo de uma página sobre fornecer acesso universal à Internet ser um arquivo gigante de vídeo? Mas aqui estou para dizer-lhe que, sim, é isso mesmo. Eles carregam um vídeo enorme apenas para que o globo possa girar.

Esta é a mensagem do Facebook para o mundo: “A Internet é lenta. Espere sentado.”

E nem é como se conexão ruim fosse um problema apenas do terceiro mundo! Já viajei o suficiente aqui na Austrália para saber que, em regiões rurais como a Tasmânia e Queensland, comerciantes tratam o Wi-Fi como conhaque de cem anos de idade, ou seja, você é bem-vindo para comprar o quanto você quiser dele, mas custa uma fortuna e vem em porções minúsculas. E após a terceira ou quarta compra, as pessoas começam a te encarar de um jeito engraçado.

Mesmo em lugares bem conectados como Sydney, todos nós já tivemos a experiência de ter conexão ruim e quase nenhuma bateria, enquanto esperávamos um site com ares de grande produção carregar para extrair uma micro informação como o endereço de um restaurante.

Os designers responsáveis pela masturbação sem sentido como essa página do Facebook merecem a pena capital: eles deveriam ser forçados a usar o mouse em forma de disco de hóquei da Apple pelo resto das suas vidas profissionais. [Gritos de horror do público.]

O Google lançou um competidor para os Instant Articles, que chamam de Accelerated Mobile Pages. O AMP é um subgrupo do HTML criado para ser mais rápido em dispositivos móveis.

Por que não usar HTML comum sem lotar a página de porcarias inúteis? A questão continua sem resposta.

O projeto AMP é ostensivamente de código aberto e várias publicações já se inscreveram. E como prova do seu amor infinito pela Internet móvel, o Google se voluntariou para cuidar da infraestrutura, especialmente as partes que se encarregam de monitorar o usuário.

Página de apresentação do projeto AMP.

Jeremy Keith me mostrou que a página descrevendo o AMP (acima) é tecnicamente infinita no tamanho. Se você a abrir no Chrome, ela irá baixar continuamente o mesmo vídeo de 3,4 megabytes em loop, para sempre. Se você a abre no Safari, onde o loop está quebrado, a página ainda consegue ocupar quatro megabytes.

Essas páginas comicamente enormes para projetos destinados a tornar a Internet mais rápida são o equivalente a assistir um vídeo de exercícios físicos onde o apresentador só fica lá, parado, comendo pizza e biscoitos.

As maiores empresas de tecnologia do mundo não conseguem sequer tornar esses sites de textos minúsculos, que descrevem seus projetos de ponta para reduzir o inchaço das páginas web, leves e rápidos numa conexão móvel.

Não consigo pensar em uma admissão de derrota mais completa.

O líder do projeto AMP do Google foi legal o suficiente para conversar conosco no Twitter. Ele reconheceu o problema do inchaço, mas explicou que o Google estava com “recursos apertados” e precisou terceirizar esse projeto.

Tal admissão me comoveu profundamente, porque eu não tinha ideia que o Google estava mal das pernas. Então gastei algumas horas do meu próprio tempo criando uma versão estática da página do AMP.

Teste de Taft.

Comecei substituindo os carrosséis de imagens por fotos de William Howard Taft, o maior presidente dos Estados Unidos em volume. Acho que isso representou uma grande melhora em relação às animações gratuitas da página original. Ao cortar os excessos, consegui reduzir o tamanho da página para meio megabyte em uma tarde de trabalho. Isto é oito vezes menor que a página original.

Ofereci minhas mudanças ao Google de graça, mas eles estão evidentemente com os recursos limitados demais até mesmo para arranjar alguém com tempo para fazer um copiar e colar.

Este projeto me levou à propôr o “Teste de Taft”: o design da sua página melhora quando você substitui todas as imagens dele pelas de William Howard Taft?

Se sim, então talvez todas aquelas imagens não estejam acrescentando muito ao seu artigo. No mínimo, deixe o Taft lá! Admita, ele fica mais bonito desse jeito.

William Howard Taft falando ao telefone.

Gostaria de compartilhar com vocês meu segredo simples, de dois passos, para melhorar o desempenho de qualquer site:

  1. Certifique-se de que os elementos mais importantes da página sejam baixados e renderizados por primeiro.
  2. Pare aí.

Você não precisa de toda a porcaria restante. Seja corajoso no seu minimalismo.

Exemplo de construção simples com HTML e um pouco de CSS.

Para copiar um famoso palestrante motivacional, eu poderia sair hoje, com os materiais que já temos, e reescrever todos os sites que eu mostrei no começo do texto para fazê-los carregar em menos de um segundo. Em duas horas.

Você consegue? Consegue?

É claro que consegue! Não é difícil! Nós sabíamos como fazer páginas web pequenas em 2002. Não é como se o segredo tivesse se perdido na história, como o fogo grego ou a liga de Damasco. Mas nós sofremos pressão para deixar esses sites inchados.

Eu aposto que se você fosse a um cliente e apresentasse um template de site de 200 kilobytes, você seria demitido. Ainda que ele parecesse ótimo e incluísse todo o rastreamento e as propagandas e as porcarias de mídia social que eles insistem em colocar. É apenas muito fora do imaginável neste ponto.

Se você já batalhou para perder peso, sabe que há truques que as pessoas usam para se enganar e acharem que estão mais magras. Você murcha a barriga, usa uma camisa apertada, fica de um certo lado da balança.

A mesma situação acontece com testes de desempenho. As pessoas inventaram métricas malucas para persuadirem a si mesmas no sentido de que seus sites cheios de bobagens carregam rapidamente.

O Google tem um teste de performance popular chamado SpeedIndex. (Você sabe que é do Google porque eles casualmente jogam um símbolo de integral na definição.) O SpeedIndex é baseado na ideia de que o que conta é o quão rápido a parte visível do site carrega. Não importa o que está acontecendo nas outras partes da página. Não importa se a rede está saturada e o smartphone começa a esquentar. Não importa se a bateria está visivelmente sendo drenada. Está tudo bem enquanto a parte visível do site parece saltar à vista imediatamente.

Explicação gráfica do SpeedIndex.

É claro, não importa o quão rápido o site parece carregar se a primeira coisa que a página faz é te mostrar um anúncio intersticial. Ou se, como muitos usuários, você começar imediatamente a rolar a página para baixo e pega a parte não-otimizada com as calças arriadas.

Só há uma medida honesta da desempenho para páginas web: o tempo entre você clicar no link e terminar de pular a última propaganda. Todo o resto é bobagem.

Em conversas com os defensores de desempenho da web, às vezes me sinto como um hippie falando para os donos de SUVs sobre economia de combustível. Eles têm todos os tipos de truques estranhamente específicos para melhorar a quilometragem. Desinflar o pneu frontal da esquerda um pouquinho. Colocar um ímã no tampão de combustível. Recolher os retrovisores laterais.

A maior parte das conversas sobre desempenho na web é similarmente técnica, envolvendo compressão, carregamento assíncrono, sequenciamento de componentes, agrupamento de requisições de HTTP, pipelining e minimização.

Tudo isso obscurece uma solução simples: se você só vai à loja da esquina, vá de bicicleta.

Se você está apenas mostrando cinco frases de texto, use HTML puro. Droga, use um arquivo de texto! Assim você não precisará de truques de compressão, símbolos de integral ou gráficos de Gantt mostrando quais componentes são carregados em qual ordem.

Navegadores são muito, muito bons em renderizar HTML puro.

Nós temos a tecnologia.

Nutricionistas costumavam ser grandes entusiastas desse conceito de pirâmide alimentar. Acho que precisamos de uma para a web, para nos lembrar de como um site sadio deve se parecer.

Aqui está o que eu recomendo para um site balanceado em 2015:

  • Uma base sólida de texto que vale a pena ler, formatado com uma dose saudável de linguagem de marcação;
  • Algumas imagens, com moderação, para ilustrar e melhorar o visual;
  • CSS a gosto;
  • E então, sem exageros e só se você precisar, JavaScript.

Pirâmide alimentar da web saudável.

Em vez disso, esta é a pirâmide da web como a observamos por aí:

  • Uma camada base de HTML;
  • Uma enorme pilha de porcaria;
  • No topo de tudo isso, uma bagunça de scripts de vigilância e monitoramento.

Pirâmide alimentar da web atual.

Anúncios gordos

Web designers! Nem tudo é culpa de vocês.

Vocês trabalham muito para criar um site legal, otimizado para desempenho. Vocês gastam o processo do design tentando antecipar as necessidades do usuário e indicar o caminho deles com pétalas de rosa.

Então, depois de todo esse esforço, seu cliente faz você cagar em seu trabalho duro adicionando scripts de rastreamento e anúncios sobre os quais você não tem controle algum, de que a origem e o conteúdo serão decididos no momento que a página carregar no navegador do usuário, e que têm como propósito quebrar seu design e distrair o usuário de qualquer que seja o que ele veio fazer no site.

A experiência de usuário do seu site é dominada por elementos hostis fora do seu controle.

Veja este artigo da NPR discutindo o crescente uso de bloqueadores de anúncios. A página tem 12 megabytes em um navegador padrão. O mesmo artigo com um bloqueio básico de anúncios ligado pesa um megabyte. Não é um modelo de parcimônia, mas, ainda assim, que diferença faz um plugin.

Se você olhar o que a versão desbloqueada te empurra, não são apenas vídeos e banners de anunciantes, mas arquivo atrás de arquivo de JavaScript. Cada beacon, rastreador e botão de compartilhamento tem sua própria coleção de scripts que precisa ser trazida de outro servidor. Cada requisição vem repleta de cookies.

Mais cookies é a última coisa de que seu site com sobrepeso precisa.

Esses scripts são trazidos sabe-se lá de onde e são o vetor perfeito para malwares.

Publicitários dirão que precisa ser dessa forma, mas ao lidar com publicitários você deve ter em mente que eles são mentirosos profissionais. Não digo isso para ofender; digo isso como uma descrição de emprego. O trabalho de um publicitário é te convencer a fazer coisas que você de outra forma não faria. A missão deles ao conversar com web designers é persuadi-los de que a única forma de apresentar os anúncios é incluindo montanhas de porcarias e códigos de rastreamento de terceiros. O inchaço, o desempenho e a péssima segurança, eles dizem, é o preço que os leitores pagam pelo conteúdo gratuito.

Deparei-me com esses diagramas do “ecossistema de adtech”, que eu adoro. Eles comunicam a sordidez da publicidade de um jeito que meros números jamais poderiam.

Aqui está uma visão do ecossistema de adtech em 2011, quando existiam 100 empresas do tipo:

100 empresas "adtech" em 2011.
Clique para ampliar.

Aqui é como estavam as coisas em 2012, quando existiam 350 delas:

350 empresas "adtech" em 2012.
Clique para ampliar.

Em 2014, éramos abençoados com 947:

946 empresas "adtech" em 2014.
Clique para ampliar.

E em 2015 nós tínhamos 1876 dessas coisas. Elas estão todas competindo pela mesma pequena fatia dos seus gastos online:

1876 empresas "adtech" em 2015.
Clique para ampliar.

Essa indústria em ascenção é muito complexa — e eu creio que isso seja intencional.

Quando você está tentando entender um sistema complexo, pode ser útil se afastar um pouco e dar uma olhada no fluxo geral das coisas. Por exemplo, aqui está um diagrama alemão mostrando a reserva de energia da Terra:

Diagrama alemão mostrando a reserva de energia da Terra.

Todo tipo de coisas complicadas acontecem com a luz do Sol quando ela ilumina plantas ou água, mas você pode ignorá-las completamente e apenas mensurar a energia total que entra e que sai.

Seguindo o mesmo espírito, deixe-me desenhar o jeito que o dinheiro está fluindo pela bolha da publicidade.

No começo, você tem o consumidor. Em uma tentativa mal orientada de sensibilidade cultural, escolhi representar os consumidores com um canguru1. Consumidores dão dinheiro para vendedores em troca de bens e serviços. Aqui a seta vermelha representa o dinheiro fluindo para o vendedor, ou como vocês dizem na Austrália, “dólares”.

Consumidores dão dinheiro a vendedores em troca de bens e serviços.

Uma porção desse dinheiro é desviada para pagar pelos anúncios. Pense nisso como uma pequena taxa de consumo em cada coisa que você compra.

Parte do dinheiro vai para anunciantes.

Esse dinheiro quica entre os intermediários do mundo da publicidade até que finalmente flui de algum lugar para o bolso de alguém. Atualmente vão para os bolsos de operadores de redes de anúncios bem sucedidos como Facebook, Yahoo e Google.

Parte da parte vai para o bolso de alguém.

Você vai notar que há mais dinheiro saindo desse sistema do que entrando. Há um limite no quanto de dinheiro está disponível para as empresas de publicidade que vem apenas dos consumidores. Pense em quantos anúncios são exibidos para você em um dia comparado ao número de compras que você realmente faz.

Graças a Deus os investidores existem! Agora mesmo eles estão preenchendo a lacuna despejando seus investimentos nesse mercado tão aquecido. A esperança é de que eles vão pegar uma dessas poucas empresas que acabam por alcançar o sucesso.

Entram em cena os investidores.

Todavia, em algum ponto os investidores que estão despejando dinheiro vão desejar mudar para o lado direito do diagrama. E eles vão querer ainda mais dinheiro do que investiram.

Investidores demandam retorno.

Quando isso acontece, e eu acredito que está acontecendo neste momento, alguém precisa ceder. Ou nós começamos a comprar mais ou uma porção ainda maior das nossas compras vai para o pagamento dos anúncios. Ou a bolha vai estourar.

BOOM!

E assim que ela estourar as startups de anúncios ficarão desesperadas. Elas vão buscar por maneiras de se destacar do bando com formas inovadoras de vigilância. Veremos uma onda de consolidações, fusões, novas formas agressivas de rastreamento e a completa destruição do que restou da privacidade online.

É por isso que eu propus regularmos agora essa bagunça.

Acho que precisamos banir o rastreamento de terceiros e direcionamento de anúncios de terceiros. Os anúncios se tornariam burros2 novamente e seriam entregues pelo próprio site onde eles aparecem.

A prática mais aceita atualmente é a do espaço de anúncio ser leiloado durante o tempo de carregamento da página. Os anúncios verdadeiros (com toda a sua estrutura de vigilância em JavaScript) são posicionados pelo navegador depois dos elementos de conteúdo já estarem em seus lugares. Em termos de experiência de usuário, é como um vendedor chegando em uma festa depois que ela já começou, exigindo que a música seja desligada, e montando o seu pequeno estande de vasilhas de plástico para assediar seus convidados. Isso estraga o clima.

Imagine o que o layout de anúncios feito pelo servidor significaria para os designers. Você poderia carregar os componentes em uma ordem que faça sentido. Você poderia evitar a distribuição de malwares aleatórios.

Animações gigantes não iriam mais aumentar em muito o tempo de carregamento da página, destruindo o seu layout e fazendo os usuários te odiarem.

Na verdade, sejamos ainda mais audaciosos em nosso raciocínio. Eu não estou convencido de que publicações online precisam ser suportadas por anúncios de forma alguma.

As pessoas descartam a ideia de micropagamentos, ignorando a realidade de que já temos um sistema de micropagamentos de fato que está funcionando bem. Esta tabela do New York Times mostra quanto você gasta por carregamento de página numa rede de celular americana com base na largura de banda utilizada. Por exemplo, custa 30 centavos de dólar abrir uma página do Boston.com num plano de dados comum.

Tabela com o custo de acesso a sites via redes móveis.

Isto é nada mais do que um micropagamento às empresas de telecomunicações. E eu tenho certeza que essa receita é maior do que aquela que o Boston.com recebe das impressões de anúncios em sua página. Estamos nessa situação estúpida em que os anúncios geram enormes receitas para as operadoras e as redes de publicidade à custa de todo mundo.

Publicitários vão relutar a qualquer tentativa de fazê-los voltar ao modelo de anúncios burros, mas não há evidência de que os anúncios burros sejam piores do que os inteligentes. Por anos e anos anúncios sem muita segmentação trouxeram dinheiro o bastante para financiar estúdios de televisão inteiros, shows de rádio e todo tipo de entretenimento popular. Anúncios burros pagaram pelo Batmóvel.

Custa muito menos pagar por alguns jornalistas freelancer e um web designer do que custa filmar uma sitcom. Então por que é impensável forçar todos a voltarem a um modelo de financiamento de sucesso que não viole a privacidade?

É claro, os publicitários nos dirão o quão melhor a televisão poderia ter sido nos velhos tempos se eles tivessem podido colocar uma câmera no topo de cada aparelho.

Mas nós já demos ouvidos demais a eles.

Anúncios burros significarão menos receita publicitária porque boa parte dos gastos com anúncios online é alimentada pelas promessas extravagantes sobre as possibilidades das tecnologias de vigilância. Mas o mercado de publicidade online vai implodir de qualquer forma quando a atual bolha estourar.

A única pergunta para as publicações é se elas se adiantarão a isso e colherão os benefícios ou se irão ralo abaixo com todas as demais.

Componentes gordos

Vamos falar de uma causa diferente para a obesidade da web: componentes gordos!

Este tem sido um problema desde sempre, mas na medida em que as redes se tornam mais rápidas e o fluxo de trabalho das publicações, mais complicado, fica mais fácil postar arquivos imensos no seu site.

Exemplos!

Aqui temos um blogueiro presunçoso que gosta de criticar os outros por terem sites inchados. E ainda assim há uma imagem gratuita de três megabytes no topo do seu post mais recente.

Imagem gratuita num post de blog.

Presumivelmente, este é um simples caso de esquecimento na hora de redimensionar uma imagem. Sem carregá-la numa conexão lenta, é difícil notar o erro. Tornar a conexão mais rápida piora o problema.

É uma situação análoga à daqueles um engarrafamentos gigantescos na China, com 50 faixas abarrotadas de carros. Adicionar a 51º não melhoria as coisas.

Da mesma forma, ampliar a capacidade da rede não vai convencer as pessoas a colocar menos coisas em seus sites.

Considere este artigo da Vice sobre botnets. No topo do artigo há uma fotografia inútil de um par de fones de ouvido que ocupa três megabytes. Essa página não passa no Teste de Taft.

Foto dos fones de ouvido gigantesca em post da Vice.

Isso é parte de uma lamentável tendência, tornada possível pelas redes mais rápidas, de ter “hero images”, imagens que têm por único objetivo dar algo para as pessoas rolarem a tela. Nesse caso não adianta culpar o autor. Algo na cadeia de publicação falhou em minimizar aquela imagem enorme.

Mas o problema maior é que redes mais rápidas estimulam as pessoas a incluir esse tipo de encheção de linguiça visual.

Quanto mais confiamos em truques de compressão, minimização, caching e configurações de servidor, mais difíceis de detectar e potencialmente mais caros os erros se tornam.

Aqui temos outro exemplo, interessante por dois motivos:

Artigo com foto horrível ao fundo no Fusion.

Primeiro, a qualidade da imagem original é terrível. A imagem parece ter sido fotografada com uma batata porque é uma captura de tela de um programa de TV.

Entretanto, a imagem é enorme. Se você carrega essa página no Safari, ela pesa vários megabytes. Se você a carrega no Chrome ela tem 100 kilobytes, porque o Chrome suporta um formato de compressão instantânea que o Safari não suporta.

Com esse procedimento de otimização complexos, é difícil se certificar de que você está vendo a mesma coisa que seu público.

Bônus: se rolar até o fim da página, você verá que um pequeno GIF animado na parte do layout da página que os designers chamam de “chum” tem mais de um megabyte. É um clickbait inútil, mas que contribui massivamente para o peso total da página.

Print do site da Apple exibindo iPhone 6s.

Ninguém tem componentes mais pesados que a Apple. O site dela é risivelmente inchado. Acho que deve ser algum truque de marketing. “Essas imagens carregam muito devagar nessa porcaria de smartphone Android, mal posso esperar para ter um desses aparelhos da Apple!”

Vejamos a página no site da Apple que explica o iOS no iPad Pro. O quão grande você acha que ela é? Você acredita que ela é maior do que toda a capacidade de memória do icônico iMac (32 MB)?

Na verdade, dá também para colocar o conteúdo do computador principal do ônibus espacial. Não de apenas um deles, mas de toda a frota (5 MB)…

…e ainda sobraria espaço para um Macintosh SE modificado… (5 MB)

…e a coletânea dos trabalhos de Shakespeare… (5 MB)

…e ainda teríamos espaço sobrando. A página pesa 51 megabytes.

Cabe todas essas coisas no espaço que o site da Apple consome para ser carregado.

Minimalismo covarde

Esses sites da Apple exemplificam o que eu chamo de minimalismo covarde. É a estética de design dominante da web atual.

Eu escrevi um artigo sobre isso no Medium. Como este texto já está enorme mesmo, por favor leia o meu artigo transcrito aqui na íntegra:

“Minimalismo covarde

A ilusão de simplicidade embasada por megabytes de porcaria.”

Eu já comentei sobre o quanto os artigos do Medium são inchados. Esse artigo de uma frase passa facilmente de um megabyte.

Artigo de uma frase no Medium.

Não é apenas por causa de JavaScript (inútil). Há também uma grande imagem no rodapé da página. Por meu artigo ser tão pequeno, é literalmente impossível rolar para baixo para vê-la por inteiro, mas com as ferramentas de desenvolvedor do navegador eu posso meio que compreender o que é: um tipo de pessoas em trajes espaciais com tablets e celulares.

Que pesa 900 kilobytes.

Esta imagem pesa 900 KB.

Temos aqui outro exemplo de minimalismo covarde: a página inicial do programa Google Contributor. Ela é um deserto vasto e azul, dois megabytes de tamanho, que requer três cliques para ler três frases.

A última frase vai lhe dizer que o programa não está disponível aqui na Austrália.

Página inicial do Google Contributor.

Outra: a página inicial da cervejaria Tatamagouche Brewing Company. A única coisa nela é uma deliciosa cerveja. Toda a navegação foi expremida num menu de hambúrguer. Espremer coisas em menus não é o jeito de consertar sua interface flácida.

Empresas de design adoram esse antipadrão de hambúrguer invisível. Veja, por exemplo, a página de três megabytes de uma empresa chamada POLLEN. Você mal pode ver o hambúrguer ali no topo.

Review do Apple Watch no The Verge: pesado e imprevisível.

Para o exemplo definitivo de estética covarde, olhe o review do Apple Watch do The Verge. (Mas, por favor, não abra ele nos seus smartphones se estiver no 3G porque ele consumirá toda a sua franquia de dados.)

O review do The Verge é uma abominação que desvirtua completamente o mecanismo de rolagem do seu navegador. Quando você tenta rolar pra baixo, coisas estranhas acontecem.

Elementos de interface aparecem da esquerda.

Elementos de interface aparecem da direita.

Elementos de interface que você não via desde o Ensino Fundamental te chamam inesperadamente no meio da noite.

Muito de vez em quando, a página realmente rola pra baixo.

E o que acontece principalmente, caso esteja acessando o review em um notebook, é o cooler dele girar como se a sua vida dependesse disso.

Eu tentei capturar um filme de mim mesmo percorrendo o review Apple Watch do The Verge, mas não consegui. A placa de vídeo do meu antigo notebook da Apple literalmente não conseguiu lidar com o trabalho.

Expansão da interface

Algum tipo de parasita cerebral infectou os designers quando o iPad foi lançado e eles ainda não se recuperaram. Tudo agora precisa se parecer com uma tela sensível a toques.

Página inicial da Wired britânica.

Esta é a edição britânica da Wired, outro site que declarou guerra à rolagem de página. Você pode tentar rolá-la para baixo, mas ele irá obstinadamente te mover apenas para a direita em vez disso. Os títulos de artigos aparecem como gigantes quadros de porcaria comedora de tela.

Outro marco do iPad chic são aqueles elegantes infográficos em uma fonte finíssima, branca e ilegível em um plano de fundo de tela claro.

Reserve um vôo na Virgin America e você encontrará essa coluna de botões gigantes flutuando num oceano vermelho.

Registrando um voo na Virgin America.

Essa interface pode parecer limpa em um smartphone, mas em uma tela maior ela é apenas medonha.

O botão “Reservar” naquela tela te leva para uma terra de vastos campos de entrada de dados. Há um marcante ecossistema de fontes gigantes, fontes minúsculas e fontes extremamente pálidas.

Rótulos de preços minúsculos no site da Virgin America.

Após decidir aonde você vai, o site te leva a esse widget de calendário. Ele tem botões igualmente enormes, mas a única informação na qual estou interessado — o preço do vôo em cada dia — aparece em uma fonte microscópica sob a data.

Minha bronca com essa estética de design é a perda na densidade de informações. Eu sou um ser humano adulto sentado diante de uma tela grande, com um mouse e um teclado. Eu mereço algo melhor. Nem toda interface precisa ser desenhada para alguém que está navegando na Internet no banheiro, sentado na privada.

Isto é como o site do PayPal costumava ser:

Site antigo do PayPal, com muita informação condensada.

Eu nunca me ajoelhei para agradecer a Deus por me dar o provilégio da visão para que eu pudesse apreciar a beleza da antiga interface do PayPal, mas ela cumpria sua função.

Isto é como o site do PayPal é hoje:

Novo layout do PayPal.

O maior elemento da página é um ícone me castigando por eu não ter dito ao PayPal como eu me pareço. Logo ao lado há uma oferta inútil para eu “baixar o app” e, ao lado, uma oferta de um cartão de crédito.

Não consigo mais alterar a ordem das transações, não há mais ferramentas de filtros e você tem muito menos entradas visíveis antes de ter que rolar a página.

Print do painel de controle do Google.

Este é o “painel de controle” do Google que te permite configurar suas “preferências de anúncios”. Ele é similarmente infantil e visualmente inchado.

É como se acordássemos numa manhã em 2008 e descobríssemos que nosso Lego inteiro se transformou em Duplo. Sites que costumavam mostrar dados úteis agora se parecem com desenhos animados. Elementos de interface são grandes e volumosos. Qualquer pista de complexidade foi empurrada profundamente para baixo de um sub-menu de hambúrguer.

Sites miram usuários novatos em telas de toque ao custo de todo o resto das pessoas.

Outro exemplo desse inchaço de interface: a página inicial do Docker. Ela consiste em um texto leve separado por grandes pedaços de nada. Eu não deveria precisar de um trenó movido a cães e ração para navegar em seu design.

Páginas de busca são onde a dor é mais forte. Letras gigantes e botões gordos substituem a única coisa que qualquer um precisa ver — uma lista dos resultados da busca.

Aqui temos um design onde há espaço para apenas um resultado, novamente num monitor gigante de alta resolução:

Print de uma página de resultados de busca com apenas um resultado.

Eu odeio fazer isso, mas preciso chamar a atenção ao design responsivo.

Todo mundo reconhece que é desafiador construir um site que fica bom em todos os tamanhos de tela, mas a ênfase no tamanho da tela obscureceu uma importante diferença em como as pessoas interagem com os elementos de interface.

Em um telefone as pessoas estão tocando uma tela pequena com as canetas stylus de carne que saem das suas mãos (também conhecidas como “dedos”). Nesse cenário faz sentido termos botões grandes.

Em uma tela grande, onde temos hectares de espaço e um dispositivo apontador especialmente sensível, a mesma interface é enlouquecedora.

Deve haver um jeito de dividir a diferença. Eu sinto como se os designers estivessem apenas esperando todos nós pararmos de usar notebooks.

Elementos incongruentes em site de receitas.

Este é um típico site de receitas batalhando contra seu problema de UI (interface de usuário). Eu não quero implicar com isso, porque ele está tentando com muito esforço. Porém note como alguns elementos são minúsculos e outros são gigantes. Metade da página está na linguagem das interfaces de toque e ela inteira é difícil de ler.

Artigo no site da Forbes.

Aqui está a página inicial da Forbes, como vista com o menu de hambúrguer à esquerda expandido. Ela se parece com um pedaço aleatório da memória que foi renderizada acidentalmente pela placa de vídeo. Ela tem múltiplos itens de compartilhamento em redes sociais, setas para cima, setas para baixo, uma orgia de fontes. E, confiante, no topo de tudo isso, há um enorme e pesado banner, com suas próprias ideias sobre tipografia e layout.

Isso não é jeito de viver. Nós não somos animais!

Nuvem pesada

Por fim, eu quero falar sobre nossos back-ends gigantes. Como podemos esperar que as nossas interfaces web sejam magras quando estamos dando um exemplo tão ruim no lado do servidor?

Tenho uma amiga que vive de fazer biscoitos. Como muitos padeiros caseiros, ela começou usando sua própria cozinha, em toda a sua capacidade, até que tudo estivesse coberto de farinha e seu apartamento, quente como um país tropical.

A certa altura ela percebeu que precisava comprar equipamentos industriais de padarias.

Ser bom em fazer biscoitos não te ensina nada sobre como comprar equipamentos profissionais de restaurantes.

Para um cozinheiro ocasional, é aterrorizante a ideia de ter que comprar um fogão industrial, suporte de arrefecimento, um mixer industrial e começar a comprar ingredientes em sacos de 50 quilos. É ainda mais amedrontador contratar funcionários, alugar um espaço com cozinha e conseguir a autorização da vigilância sanitária. Um erro pode fechar o seu negócio.

Por anos a Internet funcionou da mesma forma. Você podia hospedar um site pequeno em um servidor barato e que já vinha configurado, mas se o seu projeto começasse a ganhar tração, você se veria falando ao telefone com uma vendedora robótica de voz aveludada sobre assinar contratos de equipamentos, banda e espaço físico de alocação.

Era fácil sair da sua área e cometer erros caros.

A Amazon Web Services mudou tudo. Eles oferecem ferramentas profissionais sob demanda, na hora, em escala. Você não precisava comprar equipamentos e você não estava mais preso à propriedade deles. Você pagava um preço alto pelo serviço, mas ele removia a maior parte dos riscos. É claro, você ainda tem que aprender a usar essas coisas. Mas essa parte era divertida, na verdade.

Mas sempre tinha uma pegadinha. Os queimadores do fogão eram meio pequenos. Os cabos iriam ocasionalmente soltar das frigideiras em momentos inesperados. E, para o crédito dela, a Amazon te avisava disso logo no primeiro momento e te dizia para preparar seus procedimentos tendo essas falhas em mente.

Algumas coisas estavam garantidas que nunca falhariam — os freezers, por exemplo, sempre estariam numa temperatura abaixo de congelante. Mas talvez você não pudesse destravar as portas por algumas horas num dia qualquer.

Assim que as pessoas começaram a migrar para a nuvem, isso as forçou a pensar em uma escala maior. Elas tiveram que pensar em termos de máquinas múltiplas e zonas de disponibilidade e isso significava pensar sobre redundância e tolerância a falhas.

Todas essas coisas são boas em escala, mas um exagero para muitos sites pequenos. Você não precisa de toda a equipe de um restaurante para fritar um ovo.

Na medida em que os sistemas cresceram, a Amazon começou a oferecer mais automação. Eles não iriam apenas alugar fornos gigantes, mas uma frota de robôs cozinheiros que você poderia programar para fazer todo tipo de tarefas mundanas para você. E, novamente, era muito mais divertido programar os robôs do que fazer você mesmo as tarefas mundanas.

Para muitas empresas de tecnologia, onde encontrar bons programadores é mais difícil do que encontrar dinheiro, fez sentido mudar completamente para os serviços na nuvem altamente automatizados.

Para programadores, a nuvem ofereceu uma chance de criar sistemas distribuídos por dezenas ou centenas de servidores no começo de suas carreiras. Era como conseguir as chaves de um 747 logo no primeiro dia da escola de aviação.

O trabalho da maioria das pessoas é bem rotineiro. Você conecta um banco de dados a um modelo e garante que ninguém tropeçará na tomada. Mas automação em escala? Isso é bem legal, e isso é difícil!

É como se você pegasse um tanto de contadores de pequenos negócios e os dissesse que eles iriam criar um paraíso fiscal de corporações multi-bilionárias nas Ilhas Seichelles.

De repente eles se sentem vivos, eles se sentem livres. Eles estão no topo da hierarquia de necessidades de Maslow, auto-realizados em todas as possibilidades. Eles não querem voltar.

É assim que se sente um programador, perdido na nuvem.

Complexidade é uma lâmpada de matar mosquitos para pessoas inteligentes. Não conseguimos resistir a ela, muito embora saibamos que é ruim para nós. Essas coisas são legais demais para não se trabalhar nelas.

O resultado é que grande parte da web é terrivelmente construída no exagero.

Tecnologias para operar em escala desenvolvidas por empresas que precisam delas terminam nas mão de pessoas que aspiram trabalhar nessas escalas. E não há ninguém para lhes dizer “não”.

Analisando jogos de xadrez no notebook.

Adam Drake escreveu um envolvente post sobre analisar dois milhões de jogos de xadrez. Em vez de usar um cluster no Hadoop, ele apenas reuniu algumas utilitários Unix em um notebook e conseguiu uma melhoria de performance 235 vezes maior do que a abordagem de “big data”.

O ponto não é que pessoas usando o cluster no Hadoop são estúpicas ou de que tudo pode ser feito em um notebook. É que a intuição de muitas pessoas sobre o que constitui um grande sistema não reflete a realidade do hardware de 2015.

Você consegue fazer muita coisa em um notebook ou num servidor web escalável se você pular as cinquenta camadas de despesas gerais (o “overhead”).

Deixe-me dar um exemplo concreto. Recentemente ouvi de um competidor, vamos chamá-lo de ACME Favoritos Co., que está querendo sair do mercado de favoritos na web e vender esse negócio3.

Tabela comparativa.

Embora a ACME tenha muito mais tráfego do que eu, descobri que eles só têm metade dos usuários ativos diariamente. Isso foi tranquilizador porque a parte difícil de escalar um serviço de favoritos na web é ter que lidar com as pessoas favoritando coisas.

Ambos temos o mesmo número de funcionários. Eles tem um estagiário trabalhando meio período no projeto, enquanto eu hesito por não saber o que fazer e viajo o mundo dando palestras. Digamos que temos metade de um funcionário em tempo integral para cada empresa.

Nós temos receitas similares por usuário ativo. Meu faturamento é de US$ 12 mil por mês e o deles, é US$ 5 mil.

Onde os projetos diferem radicalmente é no custo. A ACME hospeda seu serviço na Amazon Web Server e em um dado momento eles pagavam US$ 23 mil (!!) de despesas mensais. Com um esforço titânico, conseguiram reduzir isso para US$ 9 mil por mês.

Eu pago pouco mais de mil dólares por mês pela hospedagem, usando meu próprio equipamento. Esse número inclui o custo amortizado do meu hardware e os refrigerantes da máquina que fica no corredor.

Enquanto eu considero o serviço de favoritos na web como um negócio rentável, para eles é um ralo que suga US$ 4 mil por mês. Estou vivendo bem no mesmo fluxo de renda que está levando eles a vender os dados dos usuários para publicitários e a pular fora desse mercado.

O ponto é que suposições sobre complexidade vão ancorar suas expectativas e limitar o que você está tentando fazer. Se você pensa que um site “de verdade” tem que morar na nuvem e estar em uma dezena de máquinas, toda uma série de projetos parecerá inviável.

Da mesma forma, se você acha que precisa de um CMS de muitas camadas e um extensivo JavaScript personalizado para um negócio de publicação, a variedade de coisas que você vai tentar se torna muito limitada.

Em vez de tentar fazer seu projeto exageradamente construído parecer simples, pergunte-se se ele não pode apenas ser simples.

Eu não quero ser muito duro com a nuvem. Alguns dos meus melhores amigos estão na nuvem. Em vez disso, quero lembrar a todos que há espaço suficiente na base. Desenvolvedores hoje trabalham em cima de muitas camadas para notar quão poderosa a tecnologia se tornou. É um problema da princesa e da ervilha, porém reverso.

A mesma coisa acontece no navegador. A tecnologia central é tão rápida e boa que nós temos sido capazes de empilhar porcaria em cima dos sites e ainda fazer com que eles funcionem toleravelmente bem.

Um jeito de fazer seu site brilhar é ter a coragem de deixar o navegador fazer aquilo que ele está otimizado para fazer. Não assuma que todos os seus frameworks e ferramentas estão te economizando tempo ou dinheiro.

Infelizmente, a compexidade se tornou motivo para contar vantagem. As pessoas se gabam umas com as outras sobre o que está em sua “pilha” e compartilham dicas sobre como gerenciar tudo isso.

“Pilha” é o equivalente de “polyfill” no back-end. Ambos são sinais de que você está complicando demais, radicalmente, o seu design.

Conclusão inspiradora

Há uma razão para se importar com isso além da estética e da eficiência.

Deixe-me usar uma analogia de um jogo de computador para expressar duas visões da web do futuro.

Print do Minecraft.

A primeira visão é a web como o Minecraft — um mundo aberto com peças simples que obedecem a regras simples. Os gráficos são meio desajeitados, mas esse não é o ponto, e ninguém se importa. Nesta visão você deve ser um participante ativo e espera-se que você crie coisas. Você terá mais diversão quando cooperar com os outros. As regras do jogo são simples e não te limitam muito.

As pessoas criam coisas incríveis no Minecraft. Aqui temos uma cidade cheia de arranha-céus:

Arranha-céus construídos no Minecraft.

Aqui estão alguns maníacos que construíram uma CPU funcional inteira, feita de Redstone. Se pudesse escalar até um tamanho razoável, ela poderia rodar Minecraft dentro do Minecraft, algo bem maluco de se pensar:

CPU construída dentro do Minecraft.

O jogo é fácil de aprender e te deixa sozinho com suas próprias ferramentas. A falta de polimento é parte do seu apelo.

A outra visão é a web como Call of Duty — um jogo primorosamente produzido, com uma experiência guiada meio que participativa (mas não de verdade), efeitos de tirar o fôlego e muitas oportunidade de fazer compras dentro do jogo.

Print do Call of Duty.

Criar esse tipo de web requer uma grande equipe de especialistas. Nenhuma pessoa poderá entender todo o processo — não se espera isso de ninguém. Mesmo se alguém conseguisse dominar todas as tecnologias em jogo, os custos de produção seriam proibitivos.

A experiência de usuário nesse tipo de web é aquela de ser guiado, com a ilusão do poder de escolha, por limites razoavelmente limitados. Há um caminho óbvio que você deve seguir e que desencoraja você a afastar-se dele. Como um bônus, o jogo codifica toda uma agenda política problemática. A única forma de rejeitá-la é não jogando.

Apesar dos luxuosos valores de produção, há uma estranha mesmice em tudo. Você está sempre na mesma zona de guerra marrom.

Com grande esforço e habilidade, você será capaz de fazer pequenas modificações no mundo do jogo. Mas a maioria das pessoas vai acabar jogando exatamente do jeito que os criadores queriam. É entretenimento passivo com um ocasional apertar de botões.

Tudo que fazemos para tornar mais difícil criar um site ou editar uma página na web, e que dificulta o aprendizado de código olhando o código-fonte, promove essa visão consumista da web.

Fingir que alguém precisa de uma equipe de profissionais para simplesmente colocar um artigo online se tornará uma profecia auto-realizável. Complicar desnecessariamente a web significa aumentar a escada que tornava possível para as pessoas serem auto-didatas e surpreender a todos com novas ideias inesperadas.

Aqui está a parte animadora do texto:

Vamos preservar a web como o meio de hipertexto que ela é, a única de seu tipo no mundo, e não transformá-la em outro meio de consumo de que já temos tantos exemplos.

Vamos nos comprometer com a ideia de que na medida em que os computadores se tornam mais rápidos e as redes se tornam mais rápidas, a web também deveria ficar mais veloz.

Não permitamos que os dinossauros em pânico das publicações online nos pisoteiem enquanto debandam em fuga do meteoro. Em vez disso, vamos nos esconder em nossos buracos e assistir a natureza tomar seu belo curso.

Mais importante, vamos acabar com o domínio da vigilância online que ameaça não apenas nossa subsistência, mas a nossa liberdade. Não só aqui na Austrália, mas na América, na Europa, no Reino Unido — em todos os países livres onde a ideia de vigilância total e permanente soava como ficção científica ruim até dez anos atrás.

A forma de evitar que essas empresas gigantes esterilizem a web é tornando seus sites irrelevantes. Se todas as coisas legais acontecerem em outros lugares, as pessoas vão seguir. Nós fizemos isso com a Aol e a Prodigy; nós podemos fazer de novo.

Para isso acontecer, é vital que a web continue participativa. Isso significa não apenas tornar os sites pequenos o suficiente que todo mundo possa visitá-los, mas também pequenos o suficiente que as pessoas possam aprender a construir seus próprios sites através do exemplo.

Eu não me importo com o inchaço porque ele é ineficiente. Eu me importo porque ele torna a web inacessível.

Manter a web simples a mantém sensacional.

Mantenha a web legal!

Tradução por Leon Cavalcanti Rocha.

  1. A palestra que serviu de base para esse texto foi realizada em Sydney, Austrália.
  2. “Burro”, aqui, no sentido de “dumb”, ou seja, o contrário de esperto/”smart”.
  3. Maciej, autor do texto, é o criador e único responsável pelo Pinboard, um serviço de favoritos na web.

Assine o Manual do Usuário

Ao acessar este blog, você não é rastreado ou monitorado por empresas como Google, Facebook e outras de publicidade digital. A sua privacidade é preservada. O Manual do Usuário tenta viabilizar-se por métodos alternativos e éticos. O principal é o financiamento coletivo. Colabore — custa a partir de R$ 9 por mês:

Assine no Catarse