Otimização da imagem do sítio Web

A otimização das imagens é um dos aspectos mais “compensadores” do desempenho do WordPress: para a mesma estrutura de página e tema, desde que o tamanho, as dimensões, a formatação e a entrega da imagem estejam corretos, a experiência de carregamento melhorará imediatamente.

Mas a otimização de imagens é também a forma mais fácil de fazer confusão, não porque seja tecnicamente demasiado difícil, mas porque a informação está demasiado fragmentada:
Lê-se alguns artigos, sabe-se que “compressão”, “WebP/AVIF”, “lazy loading”, e depois olha-se para a introdução do plugin e diz-se “grátis todos os meses! 100 créditos por mês”, “Gratuito 20MB”, “1 crédito por imagem”, mas quanto mais leio, mais confuso fico... O facto de ser gratuito é suficiente? Como deduzir a taxa? Entendeu mal “a mesma coisa”? E o mais importante:O efeito foi realmente sentido depois de o ter feito ou não?

Este artigo faz apenas três coisas:

1. Dar-lhe um executávelroteiro (também fig.)(O que fazer primeiro, o que fazer depois)
2. Seja claro quanto à opção que está a escolher (qual é a diferença entre gratuito/pago e para quem cada um é adequado)
3. Escreva antecipadamente os problemas mais comuns (para não ter de andar à procura de soluções quando terminar)

1. o resultado final: o que o WordPress traz e o que não traz

Se não descobrir primeiro o que o núcleo do WordPress já faz, é fácil fazer uma de duas coisas:

• Em vez de utilizar a “capacidade livre” de que deveria usufruir, gasta tempo/paga dinheiro para construir a roda vezes sem conta.
• Pensei que o WordPress iria “converter automaticamente todas as imagens antigas para WebP/AVIF”, mas acontece que não o faz!

O núcleo do WordPress tem estas capacidades fundamentais incorporadas:

• Imagens responsivas (srcset/tamanhos): A partir do WordPress 4.4, o núcleo produzirá imagens para o srcset 与 sizese utiliza as imagens de várias dimensões geradas durante o carregamento para permitir que o navegador escolha um recurso mais adequado para carregar em função das condições do ecrã.
• Carregamento preguiçoso nativoO WordPress 5.5 em diante permite o carregamento preguiçoso nativo de imagens por padrão, usando padrões HTML. loading implementação do atributo.
• Suporte para carregamento de WebPDesde o WordPress 5.8, é possível carregar e utilizar WebP como JPEG/PNG (desde que o seu ambiente de alojamento suporte WebP).
• Suporte para carregamento de AVIFWordPress 6.5 em diante pode carregar e utilizar AVIF como JPEG/PNG (também depende do suporte do alojamento).

Mas presta atenção:
“Suporte para carregamento/utilização” ≠ “Conversão automática/entrega automática”.
Ou seja: mesmo que já esteja no WP 6.5, os JPG/PNGs na sua biblioteca multimédia não se transformarão em WebP/AVIF por si só; não obterá automaticamente o link completo “output AVIF/WebP according to the browser's capabilities and fallback to the original image for unsupported browsers”! --Esta parte normalmente precisa de ser corrigida por um plugin ou serviço.

2. roteiro: otimização de imagens em 5 etapas

O que fazer, porquê, o que fazer para se qualificar e o que é uma box típica.

2.1 Começar por acertar no “tamanho” (o mais negligenciado, mas o mais compensador)

Muitas estações são lentas não porque a compressão não é feita, mas porque aDescarregou uma imagem grande que se estende muito para além da área de visualização：
Por exemplo, se a página tiver apenas 900 px de largura e pedir ao visitante que descarregue a imagem original de 3000 px, o browser “descarrega-a e depois encolhe-a”. Isto desperdiça largura de banda, aumenta o tempo de descodificação e torna mais lento o primeiro ecrã.

WordPress 4.4+Mecanismo de imagem responsivo（srcset/sizes) foi concebido para resolver esta questão.

Fazer o que conta como um passe:

• Ao abrir uma página num telemóvel, o tamanho da imagem descarregada deve ser significativamente menor do que no computador
• A mesma imagem é carregada com diferentes tamanhos de recursos em diferentes dispositivos (em vez de descarregar sempre a imagem original)

As armadilhas mais comuns:

• Existem temas/construtores que tratam os diagramas como imagens de fundo CSS, ou que os produzem de uma forma personalizada que pode contornar o srcsetO resultado foi uma grande imagem do
• Utiliza camas de imagem ligadas externamente, blocos de imagem de terceiros e pode também contornar o sistema multi-tamanho gerado pela biblioteca multimédia

---

2.2 Compressão (reduzir o KB, mas não “esmagar” a qualidade)

O cerne da compressão não é “quanto mais pequeno melhor”, mas sim “a diferença é pouco visível a olho nu, mas a queda de volume é óbvia”.

As regras são as seguintes:

• Fotografias/retratos ao vivo (pessoas, produtos, paisagens)Compressão com perdas prioritária (ganho máximo)
• Capturas de ecrã da interface / imagens com muito texto: A compressão deve ser mais conservadora para evitar texto difuso
• Logótipo/IconeSVG prioritário ou discreto sem perdas (com perdas é fácil de colar nos bordos)

Fazer o que conta como um passe:

• Redução significativa do tamanho da imagem na maioria das páginas
• Sem ruído visível, margens turvas, quebras de blocos de cor, texto esbatido

---

2.3 WebP / AVIF (estratégia de formato: mais pequeno para igual definição)

O WordPress já suporta o carregamento de ficheiros WebP (5,8) vs. AVIF (6,5)。
Mas para que o formato Next Generation funcione efetivamente, é necessário resolver dois aspectos:

1. Como converter em lote bibliotecas multimédia históricas(Caso contrário, estará apenas a otimizar para “novas imagens carregadas mais tarde”)
2. Se se pretende gerar uma cópia ou substituir a imagem original(Esta é uma bacia hidrográfica arriscada; centrar-nos-emos na opção “Substituir e eliminar a imagem original” do Plus WebP mais tarde)

Estilo de escrita recomendado:

• WebP: geralmente preferido como predefinição (compatibilidade mais estável)
• AVIF: uma outra direção de compressão, adequada para imagens grandes/imagens grandes do primeiro ecrã/imagens de álbum (mas maisDependência de apoio ambiental）

---

2.4 O carregamento preguiçoso deve ser utilizado corretamente (não é uma solução única para todos)

WordPress 5.5 em dianteCarregamento lento por defeitoImagem.
Reduz a utilização da largura de banda durante a renderização inicial:

• Carregamento lento para “recursos fora do ecrã”
• A imagem de grandes dimensões mais crítica no primeiro ecrã (e, em muitos casos, a imagem-chave no primeiro ecrã) é frequentemente inadequada para o carregamento diferido

---

2.5 Camada de entrega: CDN / Imagem CDN

A compressão, o dimensionamento e a formatação resolvem o problema dos “ficheiros mais pequenos que cabem”.
No entanto, se as imagens forem sempre obtidas a partir de uma distância da fonte, a latência da rede continuará a afetar significativamente a experiência. É aqui que entra a solução de “camada de entrega” (CDN/Image CDN).

Duas direcções típicas:

• Polaco da Cloudflare：Documentação da CloudflareSão apresentados os métodos de compressão polacos (lossless/lossy/WebP) e é referido que a compressão com o format=auto É permitido o formato WebP/AVIF.
• Acelerador de Sites Jetpack：Documentação do JetpackExplicar que irá otimizar as imagens e distribuí-las através da sua rede juntamente com recursos estáticos.

A otimização das imagens é responsável por torná-las mais pequenas e mais adequadas.O CDN é responsável por proporcionar uma maior proximidade e estabilidade

3) Seleção: apenas dois itinerários principais

A falha mais comum na otimização de imagens não é “não ter plugins”, mas sim demasiados plugins que levam a um processamento duplicado:
A está a comprimir, B está a comprimir, A está a converter para WebP/AVIF, B está a converter, A está a alterar URLs, B está a reescrever - nem sequer se consegue perceber o que se passa na estação.

Regras:

Só há um caminho a seguir: ou tudo local gratuito ou compressão em nuvem dos três.

• Percurso A (todos os locais gratuitos):Mais WebP ou AVIF + EWWWW Image Optimizer(ou apenas um)
• Rota B (opção tripla de compressão na nuvem):ShortPixel / Imagify / TinyPNG

---

3.1 Rota A: Local totalmente gratuito (mais WebP ou AVIF ou EWWWW)

Este itinerário caracteriza-se por:

• Não depende de serviços de compressão de terceiros “por mês/por folha” (embora algumas funcionalidades possam ser oferecidas como serviços opcionais).
• O custo: o processamento em lote pode exigir mais do servidor no CPU/IO, o que obriga a prestar mais atenção à “estratégia e ao risco”.”

3.1.1 Mais WebP ou AVIFO núcleo é “gerar/substituir”, não é a tradicional “ferramenta de compressão”.”

• Ao gerar imagens de volume total:A ID do ficheiro de imagem original é substituída por WebP/AVIF, o ficheiro original é eliminado e o URL no conteúdo é substituído.。
• O plugin fornece comandos WP-CLI e lembra: WP-CLI é mais fiável quando há muitos ficheiros.

Isto significa que, em vez de “gerar silenciosamente um WebP para si”, pode ser umMigração de activos(Especialmente se ativar a opção “Substituir e apagar a imagem original”).

Diferenças entre os dois modelos

Modo 1: Manter a imagem original + gerar uma cópia WebP/AVIF (mais estável)

• Prós: Mais fácil de recorrer em caso de problemas de compatibilidade
• Custo: A utilização do disco aumentará (imagem original + novo formato + miniaturas de várias dimensões)

Modo 2: Substituir e apagar a imagem original (mais agressivo)

• Prós: os discos não se expandem tão rapidamente; as referências das estações vão diretamente para o novo formato
• Risco: Está a “mudar os activos + mudar as referências”, o que torna mais dispendiosa a resolução de problemas de compatibilidade (especialmente se alguns sistemas externos ou lógicas de temas dependerem do nome de ficheiro/caminho/formato original).

Armadilhas típicas do Plus WebP ou AVIF

1. Após a substituição de toda a biblioteca, algumas imagens de página são apresentadas de forma anómala.
   Normalmente, a razão não é o facto de a imagem estar “estragada”, mas sim o facto de algum elo na cadeia de substituição de URL, armazenamento em cache, política de miniaturas, etc. não estar correto.
2. Quanto maior for o número de miniaturas, maior será o âmbito da alteração
   O carregamento de uma imagem pelo WordPress gera vários tamanhos; os temas/plugins também podem adicionar mais tamanhos. A substituição total significa que pode estar a alterar uma coleção muito grande de ficheiros.
3. O simples facto de efetuar uma migração de formato não significa necessariamente que o volume seja sempre o mais pequeno
   O WebP/AVIF é geralmente mais pequeno, mas a “estratégia de tamanho” e a “estratégia de compressão” continuam a ser fundamentais. Não pense no Plus WebP como “um clique mais rápido”.

---

3.1.2 Optimizador de imagens EWWW: representante da compressão local livre

A página do plugin EWWW está muito bem posicionada:

• Pode ser optimizado no seu servidor utilizando uma série de ferramentas (jpegtran, optipng, pngout, pngquant, gifsicle, cwebp, etc.)
• Pode também descarregar o processamento que consome CPU para o seu servidor (opcional) se necessitar de uma maior compressão ou de uma maior poupança de CPU.

Que papel deve a EWWW assumir na Rota A?

Se estiver a utilizar o Plus WebP como uma “estratégia de migração/substituição de formatos”, então o EWWWW é mais adequado:

• Compressão e otimização de volume(especialmente a redução de peso de recursos brutos, como JPG/PNG)
• Otimização em lote da biblioteca histórica de média(tendo como objetivo a “redução do volume” em vez da “substituição do URL”)

Fosso típico de EWWW

1. Carga elevada do servidor durante a otimização de lotes
   Como a compressão local consome CPU/IO, a solução não é “não a utilizar”, mas sim “lote, pico baixo, opção de descarregamento/nuvem, se necessário”.
2. “É gerado um WebP” não significa que o frontend tem de estar a produzir um WebP.
   Muitos plug-ins sofrem deste mal-entendido: a geração é uma coisa, as estratégias de entrega (reescrita, etiquetas de imagem, acessos à cache, etc.) são outra.
3. Fazer a mesma coisa várias vezes com outros plugins
   Se optar pela via A, tente não sobrepor o tipo de compressão de nuvem ShortPixel/Imagify/TinyPNG; se optar pela via B, não active a lógica de substituição Plus WebP. Princípio fundamental:Um caminho para o fim.

---

3.2 Rota B: Escolha tripla de compressão na nuvem (ShortPixel / Imagify / TinyPNG)

Esta via é adequada para pessoas que “querem poupar recursos do servidor, querem fazer lotes com menos esforço e aceitam faturação por crédito/por volume”.
Mas o ponto mais enganador sobre a compressão na nuvem é:Os créditos gratuitos não são tão simples como as “folhas gratuitas”!.. O número de tamanhos de miniaturas, o facto de ser ou não gerado WebP/AVIF e o facto de ser ou não repetidamente pressurizado podem afetar significativamente o consumo.

O que se segue explica: o que se passa com a gratuitidade/tarifa, como é que os créditos são deduzidos, quais são as armadilhas mais prováveis de serem pisadas e que tipos de sítios são adequados.

---

3.2.1 ShortPixel100 créditos gratuitos/mês, mas os créditos são consumidos por miniaturas e ampliações WebP/AVIF.

O que se passa com o gratuito/pago

A descrição do plug-in ShortPixel indica claramente:

• 100 créditos gratuitos por mês
• Existem também “Créditos mensais ilimitados extra” (a página da ficha dá informações sobre os preços correspondentes)
• Também disponível como “pacotes de créditos únicos que nunca expiram” (com informações sobre o preço inicial)

Dica:

• Gratuito: conceder uma determinada quantidade de créditos por mês para sítios ligeiros ou testes
• Pacotes descartáveis: adequados para sítios com grandes bibliotecas multimédia que pretendam liquidar o seu stock de uma só vez (compre uma vez e utilize-o, normalmente não expira).
• Mensal/Ilimitado: adequado para sítios com imagens continuamente actualizadas e otimização estável a longo prazo

A KB oficial do ShortPixel também deu uma atualização sobre “One Time Pack vs Unlimited Monthly”.explicação explícitaO Unlimited Monthly é um pagamento mensal (ou anual) que oferece créditos ilimitados com uma atribuição fixa de CDN; créditos únicos que não expiram, dando-lhe mais controlo sobre a sua utilização a pedido.

Conclusão: como são calculados os créditos ShortPixel?

Documentação oficial do ShortPixel KB foi muito direto:

• O WordPress gera várias miniaturas quando carrega uma imagem;
• Cada otimização de miniaturas conta como um crédito；
• Se optar por gerar um WebP ou AVIF, oCada versão WebP/AVIF da imagem original e da miniatura consome um crédito adicional.；
• Pode excluir determinadas miniaturas de serem optimizadas para reduzir o consumo de créditos.

Exemplo de créditos：

Digamos que carrega 1 imagem e o tema/plugin gera 8 miniaturas:

• Otimizar apenas a imagem original + miniaturas: 1 (original) + 8 (miniaturas) = 9 créditos
• Se também quiser gerar WebP/AVIF: mais uma versão da próxima geração para cada um dos 9 acima → +9 créditos.
  Por outras palavras, o que pensa ser “1 imagem” pode na realidade consumir perto de “créditos de 2 dígitos”.

Então:“100 créditos gratuitos” não é o mesmo que “100 imagens gratuitas”.

As armadilhas mais comuns do ShortPixel

1. Os 100 créditos gratuitos esgotam-se rapidamente
   Causa principal: muitas miniaturas + créditos extra para gerar WebP/AVIF.
   sugestão：

• Avaliar primeiro o número de miniaturas do sítio
• Excluir tamanhos de miniaturas desnecessários (otimizar apenas os tamanhos que serão realmente utilizados)
• Determinar a estratégia de compressão antes de executar em massa para evitar o consumo repetido de tentativas e erros

2. Empilhar outros plug-ins de conversor ao mesmo tempo
   Se tiver substituições Plus WebP e ShortPixel a gerar/inserir etiquetas da próxima geração, a lógica acumula-se e torna-se mais difícil de resolver. Para a rota B, deixe o ShortPixel fazer isso sozinho.
3. Pensei que, se o instalasse, seria “WebP/AVIF em primeiro plano”.”
   Página do plugin ShortPixelMencionou que converte WebP/AVIF e pode adicionar imagens da próxima geração à página inicial (por exemplo, através de etiquetas).
   No entanto, continua a ser importante verificar os resultados depois de o fazer.

---

3.2.2 ImaginarGratuito: 20MB/mês; quota deduzida de acordo com o “tamanho da imagem original + número de miniaturas”, dedução repetida em caso de pressão intensa.

Quantidade e posicionamento livres

Página oficial de preços da ImagifyA escrita é clara:Conta gratuita Conta mensal 20MB Quota。
A sua página de plug-ins também deixa claro que pode comprimir, redimensionar e converter WebP/AVIF.

Como é deduzida a quota?

Documentação oficial da Imagify “A secção ”Como é calculada a utilização dos contingentes?" explica muito claramente o mecanismo de dedução:

• O número de miniaturas afecta o consumoPor exemplo, se tiver 10 tamanhos de miniaturas, otimizar 1 imagem torna-se otimizar 11 imagens (original + 10 miniaturas), o que contribui para o consumo da quota.
• Dedução da quota em função do tamanho do documento originalPor exemplo, se enviar uma imagem de 100KB para a Imagify, 100KB serão deduzidos da quota.
• Alterar o nível de compressão e voltar a otimizar consumirá novamente a quota。
• A mesma chave de API pode ser utilizada para vários sites, mas as quotas são partilhadas entre eles.

Esta é a “forma central de compreensão” da Imagify:
É mais como um pacote de tráfego: deduz tanto quanto envia; quanto mais miniaturas tiver, mais deduz; e repetirá a dedução se voltar a carregar repetidamente.

Exemplo de quota do Imagify fácil de ler

Digamos que carrega uma imagem original de 800 KB e o sítio gera 8 miniaturas.

• O Imagify optimiza para incluir a “imagem original + 8 miniaturas” (se optar por otimizar todas elas), o que significa que esta única ação consome uma quota próxima do “tamanho original de todos estes ficheiros combinados”.
  É por isso que alguns sítios sentem que o “20MB se esgota rapidamente”: não é que o Imagify não seja suficiente, é que está a carregar demasiadas imagens de cada vez, demasiadas miniaturas e, provavelmente, está a tentar níveis de compressão vezes sem conta.

As armadilhas mais comuns da Imagify

1. Gratuito 20MB Não é suficiente para fazer um “inventário completo do historial do sítio”
   O 20MB é normalmente mais adequado para testes com actualizações ligeiras; se a sua biblioteca multimédia já for grande, é provável que uma limpeza única exija uma atualização.
2. O ajustamento repetido dos níveis de compressão resulta na duplicação do consumo de quotas
   A Imagify esclarece queUma nova otimização consumirá novamente a quota.
   Sugiro que a “estratégia” seja clara nesta página:

• Comece com um pequeno número de imagens para determinar o nível de compressão e o aspeto
• Determinar a estratégia e depois executar em massa
  Evitar repetidas tentativas e erros na biblioteca completa

3. Vários sítios que partilham a chave API conduzem a uma “redução inexplicável da quota”.”
   Se utilizar a mesma chave de API para mais do que uma estação, a quota é partilhada.
   Assim, em cenários de equipas/multi-estações, é melhor ser claro: quais as estações que são partilhadas e quais as que são utilizadas individualmente para evitar orçamentos incontroláveis.

---

3.2.3 TinyPNG(Tiny Compress Images): 500 créditos/mês gratuitos; a mudança para WebP/AVIF “deduzirá 1 crédito por tamanho”.”

Créditos gratuitos e as suas ideias de faturação

A página do plugin TinyPNG para WordPress é muito clara:

• 500 créditos por mês gratuitamente
• Na “Instalação geral do WordPress”, pode provavelmente comprimir o ficheiro Aprox. 100 imagens/mês
• No entanto, se a conversão AVIF ou WebP estiver activada:Cada tamanho de imagem consome um crédito adicionalAssim, presumivelmente, só pode ser comprimido e convertido Aprox. 50 imagens/mês(dependendo do número de tamanhos de miniaturas que tiver).

Entretanto, a Tinify (os criadores do TinyPNG/TinyJPG) também fez o seu Página de preços da APIDescrição: Registe-se e receba 500 compressões gratuitas por mês; depois disso, será cobrado pelo número de compressões bem sucedidas, sem subscrição obrigatória.

Resuma a forma como o TinyPNG é entendido numa frase:
Conta os créditos; quanto mais tamanhos de miniaturas tiver e quanto mais WebP/AVIF tiver ativado, mais rapidamente os créditos são consumidos.

Exemplos fáceis de ler de créditos TinyPNG

Suponha que o seu sítio gera 8 tamanhos de miniaturas para cada imagem:

• Apenas compressão: original + 8 miniaturas → 9 créditos necessários
• Se a conversão WebP/AVIF estiver activada: um crédito extra por tamanho → provavelmente quase o dobro!
  Isto corresponde à descrição na página do plugin: depois de ativado, o montante gratuito muda de aproximadamente “100 cartões/mês” para “50 cartões/mês”.

As armadilhas mais comuns do TinyPNG

1. Pensamento 500 créditos = 500 imagens
   Não é o caso. É consumido por “tamanho da imagem/variante”. A página do plugin avisa claramente que “as conversões deduzem 1 crédito adicional por cada tamanho de imagem”.
2. Os temas/plugins de comércio eletrónico estão a gerar demasiados tamanhos e os créditos gratuitos estão a diminuir significativamente
   Quanto maior for o número de tamanhos, mais facilmente os créditos podem ser aumentados e consumidos.
3. Depois de ativar a conversão, verifica que os créditos ficam subitamente inutilizados.
   Não é um erro, é o seu mecanismo de faturação.
   Conselhos de estratégia:

• Se a fase gratuita for utilizada principalmente para compressão e redução de peso, pode começar apenas com a compressão e depois ativar a conversão quando tiver a certeza de que a estrutura do seu sítio é estável e de que precisa realmente da próxima geração.

4. recomendação de sub-cenários: como escolher diferentes tipos de sítios

Também o WordPress, os sítios de conteúdos, os sítios de comércio eletrónico, os portefólios e os sítios de membros não têm os mesmos “pontos de pressão” para as imagens.

4.1 Sítios de conteúdos/blogues (muitos artigos gráficos, frequência média de actualizações)

Recomendações prioritárias:

1. Estratégia de dimensionamento (Etapa 1)
2. Compressão (Passo 2)
3. WebP (Passo 3)

Uma via mais adequada:

• Pretende guardar: Rota B Tripla Escolha (ShortPixel / Imagify / TinyPNG)
• Se pretender ser livre: Rota A (Plus WebP + EWWW), mas recomenda-se que comece com o “modo conservador (sem apagar a imagem original)” para avaliar o risco.

Fosso típico:

• A primeira imagem da página do artigo é muito grande, estratégia de carregamento preguiçoso incorrectaO primeiro ecrã fica mais lento

4.2 Sítio de comércio eletrónico/produtos (muitas miniaturas, muitas variantes de imagem, estabilidade em primeiro lugar)

O mais provável é que o problema do comércio eletrónico não seja “o efeito de compressão não é bom”, mas sim “a otimização de algumas dimensões não é correta, faltam miniaturas, os componentes frontais não conseguem ver a imagem”.

Recomendações prioritárias:

1. Estabilidade em primeiro lugar: estratégia de compressão conservadora, não fazer uma substituição completa da biblioteca de imediato
2. Avaliar os tamanhos das miniaturas: os temas de comércio eletrónico geram normalmente mais tamanhos, e o consumo de quantidade é ampliado (ShortPixel/TinyPNG é particularmente notório)
3. Fazer a validação em pequena escala antes do lote (muito importante)

Uma via mais adequada:

• O itinerário B tende a ser mais simples: ShortPixel/Imagify/TinyPNG podem ser todos em lote, e é essencial que compreenda o mecanismo de quotas e avalie o custo antecipadamente
• A rota A é boa, mas tenha mais cuidado com o comportamento “substituir IDs/apagar imagens originais/substituir URLs” do Plus WebP: trata-se de uma migração de activos e não é recomendável substituir tudo logo à partida.

4.3 Portfólio/estação fotográfica (qualidade de imagem única sensível, imagens de grandes dimensões, exigências elevadas em termos de visualização)

Recomendações prioritárias:

1. Política de tamanho (controlo da área de visualização)
2. Estratégia de compressão (é melhor ser maior do que esmagar os pormenores)
3. WebP/AVIF (os ganhos de cena em grande plano são óbvios, mas verifique a vista)

Uma via mais adequada:

• ImaginarDeduzir a quota de acordo com o “tamanho da imagem original”, este tipo de sítio é mais fácil de fazer “orçamento-controlável” (sabe quanto deduzir por cada imagem grande), mas evita repressões repetidas.
• ShortPixelSe o tamanho da miniatura não for muito grande, os créditos também são muito intuitivos; mas se gerar muitos tamanhos +next-gen, o consumo de créditos será maior e terá de planear com antecedência.

5) Comparação entre quotas e faturação: pôr em perspetiva o “grátis não é suficiente

Qual deles é o melhor negócio e quanto tempo durará a gratuitidade?

5.1 Três modelos de chargeback

• ShortPixel(créditos)Créditos baseados na “imagem original + número de miniaturas”; serão deduzidos créditos adicionais por cada versão correspondente de WebP/AVIF gerada.
• Imaginar(quota de MB)Deduzir a quota de acordo com o “tamanho do ficheiro original”; quanto mais miniaturas, mais deduções; voltar a imprimir deduzirá novamente.
• TinyPNG(créditos)Crédito de conversão: 500 créditos por mês; a ativação da conversão WebP/AVIF deduz créditos adicionais por cada tamanho de imagem.

5.2 Métodos de estimativa rápida

O cálculo pode ser feito da seguinte forma:

1. Procure uma “imagem original que carrega frequentemente” ao acaso e veja o seu tamanho (por exemplo, 300KB / 1MB / 3MB).
2. Dependendo do número de tamanhos de miniaturas que o seu sítio gera (por exemplo, 5 / 10 / 20)
3. Decidir se pretende gerar WebP/AVIF (sim/não)

Em seguida, utilize a seguinte “matemática mental” para compreender o consumo:

• ShortPixel≈ (1 + número de miniaturas) créditos por imagem; se estiver a gerar WebP/AVIF, ≈ duplica novamente (uma vez que a versão de última geração também recebe créditos)
• Imaginar: cada imagem ≈ (tamanho original + tamanho de cada miniatura) deduz a quota; alterar o nível de compressão e recomprimir irá deduzir novamente!
• TinyPNG: 500 créditos gratuitos; se o seu sítio gerar muitos tamanhos por imagem e a conversão estiver activada, o número de créditos gratuitos diminui significativamente (a página do plugin dá uma expetativa visual de “~100 créditos/mês” vs. “~50 créditos/mês”)

6) Alertas de risco

Risco 1: Não deixar que vários plugins façam a mesma coisa vezes sem conta

É a “fonte de desastre” mais comum.”

• Rota A:Mais WebP ou AVIF + EWWWW(Dividir a mão de obra entre os dois, não efetuar conversões e entregas iguais ao mesmo tempo, ou instalar apenas um deles)
• Rota B: ShortPixel / Imagify / TinyPNG escolher três(escolher um para compressão e próxima geração)

Risco 2: Além disso, a opção “Substituir ID / Apagar imagem original / Substituir URL” do WebP é uma migração de activos.

Ênfase acrescentada:Mais WebP A descrição indica claramente que a geração completa substitui o ID da imagem original, elimina o ficheiro original e substitui o URL do conteúdo.
Isto significa que não se trata de um “pequeno ajuste que pode ser retirado a qualquer momento”, mas sim de uma mudança ao nível do ativo.

A estratégia sugerida deve ser:

• Primeiro um pequeno teste (algumas dezenas a algumas centenas)
• Confirme se a apresentação do frontend, as miniaturas e as actualizações da cache estão a funcionar corretamente
• Reconsiderar o processamento completo da biblioteca

Risco 3: O consumo real de “créditos gratuitos” de compressão na nuvem depende do número de miniaturas e da seleção da próxima geração.

• ShortPixel: As miniaturas e a próxima geração afectam significativamente os créditos.
• TinyPNG: A ativação de WebP/AVIF deduz um crédito adicional por cada tamanho de imagem.
• Imaginar: deduzido de acordo com o tamanho da imagem original, quanto mais miniaturas forem deduzidas, maior será a pressão exercida para repetir a dedução!

Risco 4: “WebP/AVIF gerado” não significa que “WebP/AVIF está a ser entregue pelo front office”

Muitas pessoas sentem que “não é mais rápido” após a conversão porque o frontend ainda está a produzir JPG/PNG (o armazenamento em cache/gravação/identificação/negociação com o browser não está no sítio certo).

7. como verificar se produziu efeitos depois de ter sido efectuada

4 pontos de validação muito simples:

1. Se a mesma página é actualizada uma segunda vez e carrega de forma mais consistente e rápida(Armazenamento em cache e otimização do sentido físico do funcionamento)
2. Os tamanhos das imagens carregadas em telemóveis e computadores de secretária são significativamente diferentes?(responsivo) srcset/sizes (quer funcionem ou não)
3. Verificação pontual de algumas imagens: se estão presentes ficheiros/recursos WebP ou AVIF(O site está realmente a utilizar próxima geração）
4. Verificar algumas imagens: aumentar o zoom para ver se estão visivelmente enlameadas, se o texto está desfocado(a massa comprimida não é excessiva)

Se todos os quatro corresponderem, o percurso que escolheu foi efectuado. A seguir. CDN “Camada de distribuição”O conjunto será mais estável.

8) Recomendações de ação

1. Escolha primeiro a sua rota:

• Estou a tentar ser o mais livre possível.: Mais WebP ou AVIF + EWWWW (ou apenas um deles)
• Quer poupar recursos do servidor, pague por crédito para ter mais tranquilidade: ShortPixel / Imagify / TinyPNG - escolha um!

2. Fazer primeiro um pequeno teste (algumas dúzias)
3. Certifica-te de que está tudo bem antes de começares
4. São necessárias mais melhorias na estabilidade da entrega:ler CDN Aceleração

problemas comuns

1) Quantos plug-ins tenho de instalar? Posso instalá-los todos?

Tentar seguir apenas um caminho.

• Percurso A: Mais WebP ou AVIF + EWWWW Image Optimizer (ou apenas um deles)
• Rota B: ShortPixel / Imagify / TinyPNG - escolha uma!
  Na mesma estação, ao mesmo tempo, vários plug-ins podem fazer “compressão / transferência WebP / AVIF / alteração de URL / reescrita de entrega”, o que é mais provável que se torne cada vez mais caótico, mas também o mais difícil de verificar.

2) O WordPress não é já compatível com WebP/AVIF? Continuo a precisar de um plugin?

Tem de ser separado:
“Suporte para carregamento/utilização” ≠ “Conversão automática/entrega automática”.
O WordPress 6.5 também não converte automaticamente em lote JPG/PNGs antigos para WebP/AVIF, nem faz automaticamente toda a parte de “exportar AVIF/WebP para o browser capaz e fallback” por si. Normalmente, é necessário um plugin ou um serviço para que a biblioteca histórica de média funcione.

3) Qual é a etapa mais “gratificante” na otimização da imagem?

Normalmente é Primeiro, acerte os “tamanhos” (srcset/sizes).。
Muitos sítios são lentos não por não terem compressão, mas porque a página tem apenas 900 px e é pedido ao utilizador que descarregue uma imagem de 3000 px. A compressão poupa KBs, mas o “tamanho errado” fará com que o utilizador descarregue várias vezes mais dados para nada.

4) Como posso ter a certeza de que estou a carregar a “imagem mais pequena” e não a imagem original para sempre?

Veja dois fenómenos:

• Ao abrir uma página num telemóvel, o tamanho da imagem descarregada é visivelmente mais pequeno do que no ambiente de trabalho
• A mesma imagem é carregada com diferentes tamanhos de recursos em diferentes dispositivos
  Se a imagem original for descarregada para sempre, uma razão comum é o facto de o tema/construtor tratar a imagem como uma imagem de fundo CSS ou uma saída personalizada, ignorando o redimensionamento múltiplo da biblioteca multimédia com srcset.

5) “WebP/AVIF generated” significa que o frontend tem de estar a produzir WebP/AVIF?

Não é igual.
A geração é apenas a “camada de ficheiro” feita; se o frontend fornece efetivamente WebP/AVIF depende das reescritas, das políticas de marcação de imagens, dos acessos à cache, da negociação do navegador em vigor, etc. Quando terminares, não te esqueças de “verificar algumas imagens quanto aos tipos de recursos”.

6. mais O que há de tão perigoso em WebP ou AVIF? Posso executar toda a biblioteca com um só clique?

O seu ponto de risco não é a “compressão”, éAlterações nos níveis de migração de activos：

• A geração completa pode substituir o ID do ficheiro de imagem original, apagar o ficheiro original e substituir o URL no conteúdo.
  a razão pela qualNão se recomenda a substituição de toda a biblioteca logo à partidaTeste em pequena escala (dezenas a centenas) + tenha backups disponíveis antes de considerar o processamento completo da biblioteca.

7) Qual é a escolha entre os dois modos de Plus WebP: manter a imagem original vs. substituir e apagar a imagem original?

Simples de compreender:

• Modo 1: Manter a imagem original + gerar uma cópia WebP/AVIF (mais estável)Imagem original + novo formato + miniaturas de vários tamanhos: É conveniente para reversões, mas o disco aumenta (imagem original + novo formato + miniaturas de vários tamanhos).
• Modo 2: Substituir e apagar a imagem original (mais agressivo)Os discos são menos propensos ao inchaço, mas está a “mudar activos + mudar referências”, o que torna mais dispendiosa a resolução de problemas de compatibilidade.
  Quanto mais complexo for o sítio (comércio eletrónico/multi-plugin/multi-size), mais recomendável é começar com um modelo mais estável.

8) A compressão local gratuita do EWWW Image Optimizer é suficiente? Irá sobrecarregar o servidor?

O EWWW é mais um “compressor local”: consome CPU/IO.
É comum que a carga aumente durante a otimização em lote, o que não significa que “não funcione”, mas sim que a estratégia deve ser correta: lote, picos baixos e opções de descarregamento/nuvem, se necessário.
Se estiver à procura de poupanças ou se tiver poucos recursos no servidor, a Rota B é mais amiga do servidor.

9. 100 créditos gratuitos/mês do ShortPixel, porque é que tenho a sensação de que desapareceram em poucas fotografias?

por causa de créditos não é “número de imagens”.”A próxima geração será ampliada por uma miniatura com a próxima geração:

• A imagem original + cada miniatura conta como crédito
• Se for gerado um WebP/AVIF, é consumido um crédito adicional por cada versão correspondente.
  Assim, o que pensa ser “1 imagem” pode na realidade consumir perto de “créditos de 2 dígitos”. shortPixel

10) O 20MB/mês gratuito da Imagify, porque é que também se esgota rapidamente?

A Imagify é mais como um “pacote de tráfego”:

• Tal como o enviou.Tamanho do ficheiro originaldedução de quotas
• Quanto mais miniaturas tiver, mais consome
• Alterar o nível de compressão para voltar a otimizar irá consumir a quota novamente
• Mesma chave API para vários sites, partilha de quotas
  Assim, “20MB esgotar-se-á em breve” é frequentemente causado por imagens demasiado grandes, demasiadas miniaturas ou repetidas tentativas e erros.

11. o TinyPNG é gratuito para 500 créditos/mês, porque é que o plugin diz que são apenas cerca de 100 créditos/mês e depois 50 créditos/mês com WebP/AVIF?

Porque os créditos TinyPNG também são ampliados por “size/variant”:

• Uma instalação normal do WordPress comprime provavelmente cerca de 100 folhas/mês.
• Ativar a conversão AVIF ou WebP:Cada tamanho de imagem consome um crédito adicionalAssim, provavelmente só pode comprimir e converter cerca de 50 imagens por mês (dependendo do número de tamanhos de miniaturas).
  Portanto, 500 créditos ≠ 500 imagens.

12. quantas miniaturas existem no meu sítio? Porque é que isso é tão importante?

O WordPress gera vários tamanhos para carregar uma imagem; os temas/plugins (especialmente o comércio eletrónico) podem adicionar mais tamanhos.
Os créditos/quotas de compressão na nuvem são normalmente “original + miniaturas em conjunto”, pelo que quanto mais miniaturas tiver, menos créditos gratuitos tem para utilizar.

13. o carregamento lento é sempre mais rápido? Porque é que algumas pessoas dizem que o carregamento preguiçoso torna as coisas mais lentas?

O carregamento lento é adequado para “recursos fora do ecrã”.
Se o primeiro ecrã da imagem de grandes dimensões mais crítica também tiver um carregamento atrasado, pode tornar a experiência do primeiro ecrã mais lenta. O WordPress 5.5, uma vez que o carregamento preguiçoso predefinido é bom, mas não é “um tamanho único”.

14) Estou a viajar na rota A ou B. Quando é que preciso do CDN / Imagem CDN?

A compressão, o dimensionamento e a formatação resolvem o problema dos “ficheiros mais pequenos que cabem”;
O CDN resolve o problema de proporcionar uma maior proximidade e estabilidade。
Quando as imagens são obtidas a partir de uma distância do sítio de origem, o que resulta numa latência significativa, a suplementação de CDN/imagens com CDN (por exemplo, Cloudflare Polish / Jetpack Site Accelerator) será mais estável em geral, leia-se Aceleração do WordPress CDN。

15) Qual é a forma mais fácil de verificar se “funciona mesmo” quando terminar?

O método de verificação mais eficiente em termos de tempo:

• Se a mesma página é actualizada uma segunda vez e carrega de forma mais consistente e rápida
• Os tamanhos das imagens carregadas em telemóveis e computadores de secretária são visivelmente diferentes (o srcset/tamanho entra em jogo)?
• Verificação pontual de algumas imagens: se estão presentes ficheiros/recursos WebP ou AVIF
• Verificar algumas imagens: aumentar o zoom para ver se estão visivelmente enlameadas, se o texto está desfocado