WordPress 7.0 still falls short on **missing modern AVIF-first optimization** because core support is not the same as a complete image delivery strategy. WordPress officially added AVIF upload support in 6.5, along with developer hooks for output conversion, but its own documentation stops at format support rather than a default AVIF-first workflow with robust fallbacks, automation, and editorial controls (WordPress Core dev note). For site owners comparing what core does versus what modern performance stacks expect, the gap shows up in automation, markup, and consistency.
Quick Shortlist Of What Core Still Misses
| Area | What WordPress 7.0 Does | What Is Still Missing | Best Fit |
|---|---|---|---|
| AVIF Upload Support | Accepts AVIF when server libraries support it | No default AVIF-first generation strategy | Teams already producing AVIF assets manually |
| Derivative Generation | Can convert via filters in custom code | No built-in UI-led AVIF generation from legacy uploads | Developer-managed builds |
| Fallback Delivery | Responsive images still work for a single format | No native `<picture>`-style AVIF fallback orchestration | Sites needing broad compatibility control |
| Editor Controls | Basic media workflow remains familiar | No clear editorial controls for AVIF policy, quality, or exceptions | Small teams with technical oversight |
| Performance Governance | Core includes lazy loading and fetch priority behavior | No built-in AVIF-first reporting or rollout guidance | Sites using external performance tooling |
Missing Default AVIF-First Generation
The biggest weakness is simple: WordPress 7.0 does not behave like an AVIF-first image pipeline out of the box.
Core can accept AVIF uploads, and developers can map formats with the `image_editor_output_format` filter. That is useful, but it is not the same as native default behavior. A modern AVIF-first setup usually does at least three things automatically:
- generates AVIF versions from common source formats
- preserves sensible fallbacks for browsers or edge cases
- applies the policy consistently across image sizes and templates
WordPress leaves most of that to custom development, hosting configuration, or third-party tooling. That means publishers do not really get AVIF-first optimization by upgrading alone. They get a technical opening, not a finished system.
Best-Fit Use Case
This approach is acceptable for teams with a developer who already controls image preprocessing or deployment. It is weak for editorial teams expecting core to make the fast path the default path.
No Native Fallback-Oriented Delivery Layer
A second gap is delivery markup. Modern image optimization often uses `<picture>` with AVIF, WebP, or JPEG fallbacks depending on browser support and business needs. WordPress responsive image markup is useful, but it does not natively give publishers an AVIF-first fallback stack as a default content strategy.
That matters because AVIF support in browsers is only one part of the problem. Real-world deployments also care about:
- email clients and embeds
- social previews
- third-party crawlers
- asset portability across themes and plugins
- avoiding broken assumptions in older rendering environments
Without a native fallback-oriented layer, site owners often have to choose between manual AVIF use and a more complete solution built elsewhere in the stack. In practice, that means a CDN, image optimization service, or custom theme logic often becomes the real image engine.
Best-Fit Use Case
If your site serves modern browsers almost exclusively and your theme output is tightly controlled, core support may be enough. If you need graceful format negotiation at scale, it usually is not.
Hosting Dependency Still Blocks Consistent Adoption
WordPress also pushes a critical part of AVIF support down to the hosting layer. The official guidance is clear that AVIF depends on server-side image processing support in Imagick or LibGD. That is technically reasonable, but operationally messy.
For publishers, this creates several limitations:
- one host may support AVIF while another does not
- staging and production can behave differently
- migrations can silently change image capabilities
- troubleshooting lands on site owners instead of core defaults
This is one of the more frustrating parts of missing modern AVIF-first optimization. A feature that looks available in release notes can still be unavailable in the real media workflow because the environment is not ready.
Best-Fit Use Case
This model works for managed enterprise stacks that validate media libraries during deployment. It is much less friendly for smaller teams on commodity hosting.
Editorial Controls Are Still Too Thin
Even when AVIF support works, WordPress 7.0 does not offer a mature editorial control surface for it. There is no obvious built-in interface for deciding:
- when AVIF should be preferred
- which source formats should be converted
- what quality policy should apply by format
- when fallback formats should be preserved
- which image classes should be excluded
Developers can solve parts of this with hooks, but that keeps an image policy in code rather than in a workflow the content team can understand. For many sites, that creates friction between performance goals and publishing speed.
Best-Fit Use Case
Technical teams that treat media handling as infrastructure can live with this. Content-heavy organizations with many editors usually need something more visible and governed.
Measurement And Rollout Are Not Built Into Core
Another weakness is the lack of a first-class rollout model. WordPress gives site owners image support, not an optimization program. That distinction matters.
A strong AVIF-first system usually includes:
- format generation rules
- fallback rules
- quality tuning
- audit visibility
- rollback options
Core does not provide a native dashboard for comparing image weight, tracking format adoption, or flagging where older assets remain unoptimized. So even if a site enables AVIF, it can be difficult to answer the practical questions that matter:
- Are hero images actually smaller?
- Are thumbnails being converted as expected?
- Did Largest Contentful Paint improve?
- Which templates still emit legacy-heavy media?
Without that visibility, AVIF support becomes a partial technical capability rather than a managed performance outcome.
Where Core Is Actually Strong
To be fair, WordPress 7.0 is not failing everywhere on images. Its strengths are still meaningful:
- AVIF is supported as an upload format when the environment allows it
- responsive image behavior remains useful for size selection
- lazy loading and fetch priority improvements still help delivery
- developers have hooks to customize output behavior
Those are solid building blocks. The problem is that building blocks are not the same as a modern default.
Practical Options For Site Owners
If WordPress 7.0 is your baseline, the right path depends on how much control you have.
Option 1: Manual AVIF Asset Production
Use AVIF as a source format before upload.
Pros:
- low complexity inside WordPress
- predictable file output
- no dependency on runtime conversion rules
Cons:
- editorial burden increases
- fallbacks remain your responsibility
- older media libraries stay mixed
Option 2: Custom Filter-Based Conversion
Use WordPress hooks such as `image_editor_output_format` and quality filters.
Pros:
- stays close to core capabilities
- supports policy-based conversion
- fits custom themes and engineering-led stacks
Cons:
- requires development work
- no friendly non-technical controls
- testing burden shifts to your team
Option 3: External Optimization Layer
Handle negotiation and modern formats through a CDN or dedicated image optimization service.
Pros:
- strongest path for automatic format delivery
- easier fallbacks and browser targeting
- often better reporting and rollback
Cons:
- added cost or platform dependency
- more moving parts outside core
- can complicate troubleshooting
Recommendation Logic
For most publishers, the real answer is not that WordPress 7.0 lacks AVIF support. It is that WordPress 7.0 lacks a complete opinionated system for **missing modern AVIF-first optimization**.
The clearest recommendation logic looks like this:
- use core alone if you manually create AVIF files and have simple compatibility needs
- use custom filters if you have developer support and want tighter control without adding another platform layer
- use an external image optimization stack if your goal is truly automated AVIF-first delivery with fallbacks, reporting, and scale
WordPress 7.0 has moved past total AVIF absence, which is good progress. But for sites that want modern image performance as a default behavior rather than a custom project, core still stops one step too early.