What do you mean about "image range requests"? Is it downloading an image or what? Couldn't find the exact place in code. Thanks for assistance. 

This place - https://code.google.com/p/chromium/codesearch#chromium/src/components/data_reduction_proxy/core/browser/data_reduction_proxy_network_delegate.cc&sq=package:chromium&type=cs&l=185 - handles the further calculations, let's say. Am I right?

I plan to aggregate the data savings from image range requests into the currently recorded general savings metrics, and create analogous histograms for daily content lengths, etc. for image range request optimization. At this point, it's worth considering tracking client-side vs server-side optimizations in aggregate savings, but I don't think it is worth adding that now.

This is blocked on adding the image range requests optimization.

Changing this bug to be blocked on the image range requests bug, not blocking it.

I'm taking ownership of this.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/afaa2a65a0d50a88e08fd595507668538cb6689e

commit afaa2a65a0d50a88e08fd595507668538cb6689e
Author: sclittle <sclittle@chromium.org>
Date: Thu May 11 06:41:52 2017

Record Data Savings for Client-Side LoFi

This CL causes Chrome to record data savings for Client LoFi when it is
used, according to the Content-Range header if it's present (e.g.
"Content-Range: bytes 0-2047/10000" implies that the original resource
was 10000 bytes). This CL also adds a new PreviewsState bit field,
CLIENT_LOFI_AUTO_RELOAD, that is set when a Client LoFi image is auto
reloaded because of a decoding error, so that the browser process can
count the data used for the reload against the savings.

See design doc for more info:
https://docs.google.com/document/d/1CoZfTswPq67VaHKsr0OrkpPbWT87dhhvPq9hylOxrlU/edit

BUG= 605347 

Review-Url: https://codereview.chromium.org/2873793002
Cr-Commit-Position: refs/heads/master@{#470850}

[modify] https://crrev.com/afaa2a65a0d50a88e08fd595507668538cb6689e/components/data_reduction_proxy/content/browser/content_lofi_decider.cc
[modify] https://crrev.com/afaa2a65a0d50a88e08fd595507668538cb6689e/components/data_reduction_proxy/content/browser/content_lofi_decider.h
[modify] https://crrev.com/afaa2a65a0d50a88e08fd595507668538cb6689e/components/data_reduction_proxy/content/browser/content_lofi_decider_unittest.cc
[modify] https://crrev.com/afaa2a65a0d50a88e08fd595507668538cb6689e/components/data_reduction_proxy/core/browser/data_reduction_proxy_network_delegate.cc
[modify] https://crrev.com/afaa2a65a0d50a88e08fd595507668538cb6689e/components/data_reduction_proxy/core/browser/data_reduction_proxy_network_delegate_unittest.cc
[modify] https://crrev.com/afaa2a65a0d50a88e08fd595507668538cb6689e/components/data_reduction_proxy/core/common/lofi_decider.h
[modify] https://crrev.com/afaa2a65a0d50a88e08fd595507668538cb6689e/content/public/common/previews_state.h
[modify] https://crrev.com/afaa2a65a0d50a88e08fd595507668538cb6689e/third_party/WebKit/Source/core/loader/resource/ImageResource.cpp
[modify] https://crrev.com/afaa2a65a0d50a88e08fd595507668538cb6689e/third_party/WebKit/Source/core/loader/resource/ImageResourceTest.cpp
[modify] https://crrev.com/afaa2a65a0d50a88e08fd595507668538cb6689e/third_party/WebKit/Source/platform/loader/fetch/Resource.cpp
[modify] https://crrev.com/afaa2a65a0d50a88e08fd595507668538cb6689e/third_party/WebKit/Source/platform/loader/fetch/Resource.h
[modify] https://crrev.com/afaa2a65a0d50a88e08fd595507668538cb6689e/third_party/WebKit/public/platform/WebURLRequest.h

Is this fixed?

This is fixed. The data savings uses the existing DRP original vs actual framework. I'll mark it as such since sclittle is OOO and I reviewed it.