Font Mamae Que Nos Faz

Por que quase todo mundo erra na hora de aplicar fontes dinâmicas em templates antigos

O problema real não é baixar a fonte errada. O problema é que quem tá implementando template pra CMS legado não lê a documentação antes de subir pra produção. Eu vi cara com 8 anos de estrada chorando num fórum porque o layout quebrou quando alguém trocou a tipografia principal sem ajustar o kerning manual. O fonte mamae que nos faz é um bom exemplo de coisa que parece simples mas tem armadilha se você não prestar atenção em dois detalhes específicos. Você baixa o pacote, extrai, joga na pasta de assets e espera que o CSS carregue. Mas tem um passo intermediário que quase ninguém menciona nos tutoriais genéricos. O arquivo .woff2 precisa de um fallback para navegadores que ainda insistem em usar .ttf. Se você não declarar isso no @font-face, perde cerca de 23% do tráfego em dispositivos mais antigos, dependendo da base de usuários do projeto. A configuração básica é:

@font-face { font-family: 'MamaeQueNosFaz'; src: url('fonts/mamae-que-nos-faz.woff2') format('woff2'), url('fonts/mamae-que-nos-faz.ttf') format('truetype'); font-weight: 400; font-style: normal; } Repare que eu incluí o font-weight 400 explicitamente. Muita gente esquece e aí o navegador tenta adivinhar, fica carregando múltiplas variações e o FOIT (Flash of Invisible Text) aparece por 2 segundos antes de renderizar. Isso é pior que uma fonte padrão porque Quebra a percepção de performance.

O erro clássico que eu cometi em 2022

Estava configurando um site institucional com WordPress customizado. O cliente pediu pra usar o mamae que nos faz porque achava bonita. Baixei direto do repositório GitHub, segui o readme que vinha junto. Problema: o readme não mencionava que os arquivos de estilo incluídos vinham com paths relativos ao diretório original do projeto de demonstração, não ao diretório web final. O resultado foi um 404 em cada arquivo de fonte, FOIT de 3 segundos, e eu gastando 45 minutos debugando pensando que era cache do navegador. A solução foi abrir o arquivo CSS gerado, procurar por url() e substituir todos os paths por variáveis CSS que apontassem para o diretório correto. Depois disso carregou normalmente. Se você tá enfrentando esse problema agora, abre o DevTools, vai na aba Network, filtra por font e vê se os status são 200. Se for 404, o path tá errado. Se for 200 mas o texto continua sumindo, o font-display tá configurado como block e o navegador tá esperando o carregamento inteiro antes de renderizar. Troca para swap ou fallback.

Alternativas quando o mamae que nos faz não roda

Tem casos em que simplesmente não funciona. Se o projeto usa um build tool muito restrito tipo Webpack com configuração padrão de 2019, ele pode não reconhecer o formato woff2 sem plugin extra. Aí você gasta mais tempo configurando loaders do que implementando a fonte de verdade. Nesses cenários, vale a pena testar alternativas como Inter ou Plus Jakarta Sans, que são similares em peso visual e têm suporte amplamente documentado. Também tem o problema de licenciamento. O mamae que nos faz é open source mas alguns repositórios colocam restrições de uso comercial que não ficam óbvias no README. Sempre verifique o arquivo LICENSE dentro do pacote antes de usar em projeto pagante. Eu levei um aviso DMCA em 2021 por usar uma variação sem ler a licença direito. Não vale o risco.

Fontes similares ao mamae que nos faz que funcionam melhor em legacy

Se você tá travado num sistema que não suporta woff2 dinâmico, tentar soluções híbridas como carregar a fonte via Google Fonts API pode ser mais rápido do que brigar com configuração local. O trade-off é dependência de terceira parte e latência adicional no primeiro pedido, mas em média ganhas uns 300ms de TTFB porque o CDN já tem cache estabelecido. Pra projetos pequenos isso faz diferença prática. Pra sistemas internos com acesso controlado, manter tudo local é mais seguro.