Image Prioritizer causes 502 Bad Gateway due to oversized Link response headers (Nginx reverse proxy)

[ttwrpz]

Bug Description

The Image Prioritizer module in the Performance Lab plugin can generate extremely large HTTP Link: rel=preload; as=image response headers on uncached pages (e.g. when users are logged in).

When pages contain responsive images (srcset, sizes) with long or non-ASCII filenames (e.g. UTF-8 / URL-encoded filenames), the resulting response headers may exceed common reverse-proxy limits (such as Nginx proxy buffer limits).

When this occurs, Nginx logs:

• upstream sent too big header while reading response header from upstream

And Apache may log:

• AH01068: Got bogus version

This results in intermittent HTTP 502 Bad Gateway errors for logged-in users.

Full Response Headers (example with UTF-8 / URL-encoded filename)

cache-control: no-cache, must-revalidate, max-age=0, no-store, private
content-encoding: br
content-type: text/html; charset=UTF-8
date: Wed, 17 Dec 2025 13:48:35 GMT
expires: Wed, 11 Jan 1984 05:00:00 GMT
link: <https://www.example.com/wp-content/uploads/2025/12/favicon.png>; rel="preload"; fetchpriority="high"; as="image"; imagesrcset="https://www.example.com/wp-content/uploads/2025/12/favicon.png 1024w, https://www.example.com/wp-content/uploads/2025/12/favicon-300x300.png 300w, https://www.example.com/wp-content/uploads/2025/12/favicon-150x150.png 150w, https://www.example.com/wp-content/uploads/2025/12/favicon-768x768.png 768w"; imagesizes="(width <= 480px) 48px, (600px < width <= 782px) 48px, (782px < width) 48px, (max-width: 48px) 100vw, 48px"; media="screen and (600px < width <= 782px)", <https://www.example.com/wp-content/uploads/2025/12/%E0%B8%9B%E0%B8%A3%E0%B8%B0%E0%B8%81%E0%B8%B2%E0%B8%A8%E0%B8%AA%E0%B8%96%E0%B8%B2%E0%B8%9B%E0%B8%99%E0%B8%B2%E0%B8%AA%E0%B8%A1%E0%B9%80%E0%B8%94%E0%B9%87%E0%B8%88%E0%B8%9E%E0%B8%A3%E0%B8%B0%E0%B9%80%E0%B8%88%E0%B9%89%E0%B8%B2%E0%B8%9A%E0%B8%A3%E0%B8%A1%E0%B9%80%E0%B8%98%E0%B8%AD-%E0%B9%80%E0%B8%88%E0%B9%89%E0%B8%B2%E0%B8%9F%E0%B9%89%E0%B8%B2%E0%B8%81_Page_2.png>; rel="preload"; fetchpriority="high"; as="image"; imagesrcset="https://www.example.com/wp-content/uploads/2025/12/%E0%B8%9B%E0%B8%A3%E0%B8%B0%E0%B8%81%E0%B8%B2%E0%B8%A8%E0%B8%AA%E0%B8%96%E0%B8%B2%E0%B8%9B%E0%B8%99%E0%B8%B2%E0%B8%AA%E0%B8%A1%E0%B9%80%E0%B8%94%E0%B9%87%E0%B8%88%E0%B8%9E%E0%B8%A3%E0%B8%B0%E0%B9%80%E0%B8%88%E0%B9%89%E0%B8%B2%E0%B8%9A%E0%B8%A3%E0%B8%A1%E0%B9%80%E0%B8%98%E0%B8%AD-%E0%B9%80%E0%B8%88%E0%B9%89%E0%B8%B2%E0%B8%9F%E0%B9%89%E0%B8%B2%E0%B8%81_Page_2.png 1654w, https://www.example.com/wp-content/uploads/2025/12/%E0%B8%9B%E0%B8%A3%E0%B8%B0%E0%B8%81%E0%B8%B2%E0%B8%A8%E0%B8%AA%E0%B8%96%E0%B8%B2%E0%B8%9B%E0%B8%99%E0%B8%B2%E0%B8%AA%E0%B8%A1%E0%B9%80%E0%B8%94%E0%B9%87%E0%B8%88%E0%B8%9E%E0%B8%A3%E0%B8%B0%E0%B9%80%E0%B8%88%E0%B9%89%E0%B8%B2%E0%B8%9A%E0%B8%A3%E0%B8%A1%E0%B9%80%E0%B8%98%E0%B8%AD-%E0%B9%80%E0%B8%88%E0%B9%89%E0%B8%B2%E0%B8%9F%E0%B9%89%E0%B8%B2%E0%B8%81_Page_2-212x300.png 212w, https://www.example.com/wp-content/uploads/2025/12/%E0%B8%9B%E0%B8%A3%E0%B8%B0%E0%B8%81%E0%B8%B2%E0%B8%A8%E0%B8%AA%E0%B8%96%E0%B8%B2%E0%B8%9B%E0%B8%99%E0%B8%B2%E0%B8%AA%E0%B8%A1%E0%B9%80%E0%B8%94%E0%B9%87%E0%B8%88%E0%B8%9E%E0%B8%A3%E0%B8%B0%E0%B9%80%E0%B8%88%E0%B9%89%E0%B8%B2%E0%B8%9A%E0%B8%A3%E0%B8%A1%E0%B9%80%E0%B8%98%E0%B8%AD-%E0%B9%80%E0%B8%88%E0%B9%89%E0%B8%B2%E0%B8%9F%E0%B9%89%E0%B8%B2%E0%B8%81_Page_2-724x1024.png 724w, https://www.example.com/wp-content/uploads/2025/12/%E0%B8%9B%E0%B8%A3%E0%B8%B0%E0%B8%81%E0%B8%B2%E0%B8%A8%E0%B8%AA%E0%B8%96%E0%B8%B2%E0%B8%9B%E0%B8%99%E0%B8%B2%E0%B8%AA%E0%B8%A1%E0%B9%80%E0%B8%94%E0%B9%87%E0%B8%88%E0%B8%9E%E0%B8%A3%E0%B8%B0%E0%B9%80%E0%B8%88%E0%B9%89%E0%B8%B2%E0%B8%9A%E0%B8%A3%E0%B8%A1%E0%B9%80%E0%B8%98%E0%B8%AD-%E0%B9%80%E0%B8%88%E0%B9%89%E0%B8%B2%E0%B8%9F%E0%B9%89%E0%B8%B2%E0%B8%81_Page_2-768x1086.png 768w, https://www.example.com/wp-content/uploads/2025/12/%E0%B8%9B%E0%B8%A3%E0%B8%B0%E0%B8%81%E0%B8%B2%E0%B8%A8%E0%B8%AA%E0%B8%96%E0%B8%B2%E0%B8%9B%E0%B8%99%E0%B8%B2%E0%B8%AA%E0%B8%A1%E0%B9%80%E0%B8%94%E0%B9%87%E0%B8%88%E0%B8%9E%E0%B8%A3%E0%B8%B0%E0%B9%80%E0%B8%88%E0%B9%89%E0%B8%B2%E0%B8%9A%E0%B8%A3%E0%B8%A1%E0%B9%80%E0%B8%98%E0%B8%AD-%E0%B9%80%E0%B8%88%E0%B9%89%E0%B8%B2%E0%B8%9F%E0%B9%89%E0%B8%B2%E0%B8%81_Page_2-1086x1536.png 1086w, https://www.example.com/wp-content/uploads/2025/12/%E0%B8%9B%E0%B8%A3%E0%B8%B0%E0%B8%81%E0%B8%B2%E0%B8%A8%E0%B8%AA%E0%B8%96%E0%B8%B2%E0%B8%9B%E0%B8%99%E0%B8%B2%E0%B8%AA%E0%B8%A1%E0%B9%80%E0%B8%94%E0%B9%87%E0%B8%88%E0%B8%9E%E0%B8%A3%E0%B8%B0%E0%B9%80%E0%B8%88%E0%B9%89%E0%B8%B2%E0%B8%9A%E0%B8%A3%E0%B8%A1%E0%B9%80%E0%B8%98%E0%B8%AD-%E0%B9%80%E0%B8%88%E0%B9%89%E0%B8%B2%E0%B8%9F%E0%B9%89%E0%B8%B2%E0%B8%81_Page_2-1448x2048.png 1448w"; imagesizes="(width <= 480px) 150px, (600px < width <= 782px) 331px, (782px < width) 542px, (max-width: 1654px) 100vw, 1654px"; media="screen and (782px < width)"
server: nginx
server-timing: wp-before-template;dur=160.05
wpo-cache-message: WordPress login cookies were detected
wpo-cache-status: not cached
x-cache-status: BYPASS

Additional Link: rel=preload headers for other images were present in the same response, further increasing total header size.

Steps to reproduce

1. Install WordPress on a server using Nginx as a reverse proxy (for example, the default Plesk setup).
2. Install and activate the Performance Lab plugin.
3. Enable the Image Prioritizer module.
4. Create or visit a page containing large images with srcset (default WordPress behavior).
5. Use image filenames that are long or contain non-ASCII characters.
6. Log in as an administrator.
7. Visit the page while logged in.
8. In some cases, observe a 502 Bad Gateway error and the Nginx log entry: upstream sent too big header.

Screenshots

No screenshots are available because the behavior appears to be intermittent and was no longer reproducible at the time of reporting.

Additional Context

• PHP Version: 8.1
• OS: Linux
• Web Server: Nginx (reverse proxy) + Apache
• Browser: Chrome
• Plugin Version: Performance Lab 4.0.0 & Image Prioritizer 1.0.0-beta2
• Device: Desktop

• When the issue occurred, response headers contained very large Link preload entries including full srcset and sizes attributes.
• Increasing Nginx proxy buffer sizes mitigated the issue, indicating that the failure was related to excessive response header size.
• The behavior appears to be conditional and may depend on viewport size, page content, or prioritization heuristics.
• Disabling the Image Prioritizer module immediately resolved the issue.

[westonruter]

@ttwrpz Thank you for reporting this. I've commonly seen this issue when too many cookies are present as well. As I understand, the limit is for all headers combined, not any single header. So we could potentially try to look at the headers queued for being sent in headers_list() and check to see if sending it would exceed 4KB. Gemini through this together:

function get_predicted_header_size() {
    $headers = headers_list();
    $status_line = "HTTP/1.1 200 OK"; // Default; WordPress might change this
    
    // Join headers with CRLF (standard HTTP separator)
    $header_string = $status_line . "\r\n";
    $header_string .= implode("\r\n", $headers);
    $header_string .= "\r\n\r\n"; // Headers end with a double CRLF
    
    return strlen($header_string);
}

// Usage in your WordPress performance fix:
if (get_predicted_header_size() > 3072) { // 3KB threshold
    // Skip adding the massive Link header to stay safe
}

For context, this is the code responsible for adding the preload link:

performance/plugins/image-prioritizer/class-image-prioritizer-img-tag-visitor.php

Lines 320 to 365 in ad798cf

	/**
	* Adds a LINK with the supplied attributes for each viewport group when the provided XPath is the LCP element.
	*
	* @since 0.3.0
	*
	* @param OD_Tag_Visitor_Context $context Tag visitor context.
	* @param string $xpath XPath of the element.
	* @param array<string, string|true|null> $attributes Attributes to add to the link.
	*/
	private function add_image_preload_link_for_lcp_element_groups( OD_Tag_Visitor_Context $context, string $xpath, array $attributes ): void {
	$attributes = array_filter(
	$attributes,
	static function ( $attribute_value ) {
	return is_string( $attribute_value ) && '' !== $attribute_value;
	}
	);
	/**
	* Link attributes.
	*
	* This type is needed because PHPStan isn't apparently aware of the new keys added after the array_merge().
	* Note that there is no type checking being done on the attributes above other than ensuring they are
	* non-empty-strings.
	*
	* @var LinkAttributes $attributes
	*/
	$attributes = array_merge(
	array(
	'rel' => 'preload',
	'fetchpriority' => 'high',
	'as' => 'image',
	),
	$attributes,
	array(
	'media' => 'screen',
	)
	);
	foreach ( $context->url_metric_group_collection->get_groups_by_lcp_element( $xpath ) as $group ) {
	$context->link_collection->add_link(
	$attributes,
	$group->get_minimum_viewport_width(),
	$group->get_maximum_viewport_width()
	);
	}
	}

But this probably isn't where we'd want to add the conditional logic. We'd probably want to add it here:

performance/plugins/optimization-detective/optimization.php

Lines 357 to 363 in ad798cf

	if ( count( $link_collection ) > 0 ) {
	$response_header_links = $link_collection->get_response_header();
	if ( ! is_null( $response_header_links ) && ! headers_sent() ) {
	header( $response_header_links, false );
	}
	$processor->append_head_html( $link_collection->get_html() );
	}

[ttwrpz]

Thanks for the detailed analysis. That makes sense.

I agree this appears to be a combined response header size issue, and in my case it only surfaced for logged-in users, which aligns with additional cookies increasing total header size.

I think a defensive guard here is reasonable, but I’m a bit wary of relying on headers_list() or a fixed byte threshold. In WordPress, headers (especially cookies) can still be added later by core or other plugins, so the predicted size may not be reliable.

From what I observed, the main contributor to header bloat is the inclusion of full imagesrcset and imagesizes attributes in response headers. These can become extremely large, especially with long or non-ASCII filenames and multiple responsive variants.

Here are a few approaches that may work better than estimating the total header size:

• Limiting response-header preloads to the single most likely LCP image
• Avoiding imagesrcset / imagesizes in response headers entirely and relying on HTML <link> output for responsive images
• Falling back to HTML-only preload output once the link collection exceeds some reasonable complexity or size threshold

Increasing Nginx proxy buffer sizes fully mitigated the issue on my end, and disabling Image Prioritizer immediately resolved it, which reinforces that the generated preload headers are the trigger.

[westonruter]

Limiting response-header preloads to the single most likely LCP image

I will say that this is already the case. Image Prioritizer should only be adding the preload for the LCP element image. But since different viewport sizes may have different LCP elements (e.g. on mobile vs desktop) then multiple Link response headers may be sent.

Maybe a good compromise is to only send the Link response header if there is a single entry. If there are others, then we fall back to only sending the preloads in HTML LINK tags. In reality, the performance impact will be minimal.

We could also introduce a filter for customizing the threshold. By default it could be 1, but if there is no buffer limit issue, then a site could increase it.

[westonruter]

The filter would actually be for Optimization Detective, and it would be integrated here:

performance/plugins/optimization-detective/optimization.php

Lines 357 to 363 in ad798cf

	if ( count( $link_collection ) > 0 ) {
	$response_header_links = $link_collection->get_response_header();
	if ( ! is_null( $response_header_links ) && ! headers_sent() ) {
	header( $response_header_links, false );
	}
	$processor->append_head_html( $link_collection->get_html() );
	}

[westonruter]

Related: If we do this, we should definitely move the LINK[rel=preload] tags to appear right after the META[charset] and TITLE. This will ensure the preload scanner is able to start preloading the resources in the first chunk of HTML being received. See LinkedIn post.

[westonruter]

@faisalahammad There is a significant new development here that changes the picture for what I think the best solution is. See this new warning on the web.dev Preload responsive images article. In short:

To avoid any issues, it is recommended to use <link rel="preload" href="..."> elements for responsive images rather than Link: <...>; rel="preload" HTTP response headers.

Implementing this would dramatically reduce the size of the Link response header, since the imagesrcset part is what contributes to the main bulk of the header. I think implementing this would eliminate the need to introduce a filter.

Additional context is in the webperformance Slack.

[faisalahammad]

@westonruter Updated PR #2572 to strip imagesrcset/imagesizes from the Link response header instead of capping its length. HTML <link rel="preload"> tags still carry the full responsive data, so preloading is unaffected, just moved fully to the HTML side for this data, matching the web.dev guidance you linked. The filter/cap from the previous approach is removed.