Large File Optimization (LFO) provides better performance and reliability for delivering large files. It fetches target files in fragments only as needed rather than downloading the entire file to serve a small portion.

Features and options

Option	What it does
Enable	Set this slider to On to enable LFO.
LFO Type	Set the implementation type: Create partial objects (use with NetStorage always). Select this to cache partial objects, also referred to as chunks. When caching partial objects, there is some risk of content corruption if the chunks come from a different version of the same file, for example, from different servers containing different versions. See Requirements and best practices for additional requirements. The size of the object to be cached can't be greater than 32 GB. Cache whole objects only. As the name describes, the entire object is used and included in edge server caches. The size of the object to be cached can't be greater than 1800 MB. 📘 NetStorage automatically applies partial object caching when serving large objects.
Minimum Filesize	Use optimization only on files larger than the specified value. Expressed as a number suffixed with a unit string such as MB or GB.
Maximum Filesize	The maximum size of files to be optimized. Expressed as a number suffixed with a unit string such as MB or GB. The size of a file can't be greater than 323 GB. If you need to optimize a larger file, contact Akamai Professional Services for help.
Filename Policy	You need to select a filename policy for use with caching. This tells Akamai what to look for to maintain caching of files used with LFO: Files renamed when changed. This applies if you rename (version) files on your origin when you change them. Files not renamed when changed. This applies if you need to perform in-place updates of large files and will be keeping the existing file name.

Requirements and best practices

Before you add this behavior, consider the points below. End users may receive an error if any of these conditions is not met.

LFO is configured differently with Download Delivery. If you're using Download Delivery, don't add this behavior. Instead, use the Origin Object Size settings in the Content Characteristics behavior.
Clients need to use the GET method to request content from your origin server. According to the RFC 2733 standard, only GET supports the Range header, which is required to use LFO.
LFO requires specific headers. Your origin needs to support Etag, Range, Content-Range, and Last-Modified headers and accept byte range requests.
- An Entity Tag (ETag) is an HTTP header used for cache validation and conditional requests from a client for an object. Your origin server needs to include these in responses to a request. The returned Etag can't be weak. You can optionally include the Validate Entity Tag (ETag) behavior in your rule to validate Etags.
- Clients may send a Range HTTP header in their requests. Make sure the origin server responds with 206 status code to requests made with the Range header.
- A Content-Range HTTP response header indicates where a partial message belongs in a full body message. Your origin server needs to include this header with a properly formatted instance-length in a response to a request.
- A Last-Modified HTTP response header indicates when the resource was last updated. Your origin server needs to include this header in responses to a request.
- Byte-range requests occur when a client asks your origin for a portion of the requested file. Your origin server needs to include the Accept-Ranges: bytes header in a response to a request.

📘
If you're using NetStorage as your origin server, these are automatically supported.

LFO is best-suited for objects larger than 100 MB. In addition, LFO is required for files over 1.8 GB in size that you serve through Akamai. You could use NetStorage to help with these limits.
Apply LFO to the specific file content to be optimized. Add this behavior in a rule with the criteria set to match on specific File Extensions, for example, to .gz files. So, only those file formats will be targeted for LFO.

Use Files renamed when changed. You should set this as your Filename Policy and version or rename files when they change.
Ensure that all of your selected file types need LFO. If you specify a large file setting, but your origin never actually serves files in that size range, Akamai makes additional requests to the origin. This can affect performance. An edge server requests the first byte of each object to determine if the Minimum Filesize you've set here has been met. Once that check fails, the server simply re-requests the entire object from the origin. So, verify the size of your delivery objects on your origin, and select the appropriate size to ensure that LFO is is used properly.
Use LFO for on-demand media files, but not for live. Typically, on-demand format video files should use partial object caching because they tend to be larger, composite files. Live video tends to be distributed as smaller, individual segments, so it doesn't require partial object caching. This may not apply to all environments, so you should verify your media file size requirements.
The requested files need to be cacheable. Configure the Caching behavior for all resources you want to deliver with LFO. You can't use LFO with files that have no-store or bypass options applied. Also, make sure the origin server doesn't send any headers that affect cacheability, such as a Vary header.