Improving LinkedIn Publish Performance by Caching Images Server-Side

The devlog-ist/landing project focuses on creating landing pages. Recently, we tackled a performance bottleneck during the LinkedIn publishing process. The issue arose from sending large base64 encoded images directly within the publish request, leading to 413 errors from Nginx due to exceeding the maximum request size.

The Problem

LinkedIn's API has limits on request size. Sending a 1-2MB+ base64 image as part of the publish payload frequently resulted in exceeding this limit, causing the publish to fail with a 413 error. This negatively impacted the user experience, as content couldn't be reliably shared.

The Solution

To address this, we implemented a server-side image caching mechanism. Instead of including the full base64 image in each publish request, the image is now cached server-side during the generation phase. A unique key is then generated and associated with the cached image. The publish request now only includes this key, significantly reducing the payload size.

Here's a simplified illustration of the process:

1. Image is generated on the server.
2. Image is cached server-side with a unique key.
3. Publish request sends the key instead of the full image.
4. LinkedIn retrieves the image using the key.

This approach effectively shifts the burden of handling the large image data to the server, which is better equipped to manage it. It also significantly reduces the size of the requests sent to LinkedIn, resolving the 413 errors.

Benefits

• Reduced request size, preventing 413 errors.
• Improved reliability of LinkedIn publishing.
• Potentially faster publishing times due to smaller request payloads.

Takeaway

When dealing with external APIs, be mindful of payload size limitations. Server-side caching and referencing large assets by key is an effective strategy to overcome these limitations and improve the overall performance and reliability of your application.