https://bugzilla.wikimedia.org/show_bug.cgi?id=17577
Summary: Images can't have far future expires
Product: MediaWiki
Version: unspecified
Platform: All
URL: http://performance.webpagetest.org:8080/result/090218_13
2826127ab7f254499631e3e688b24b/
OS/Version: All
Status: NEW
Keywords: patch
Severity: minor
Priority: Normal
Component: Images
AssignedTo: [email protected]
ReportedBy: [email protected]
Created an attachment (id=5833)
--> (https://bugzilla.wikimedia.org/attachment.cgi?id=5833)
Image URL with timestamp patch
I'm optimizing performance of MediaWiki instances and one of the issues I came
across is that images in MediaWiki don't change their URLs over time as they
change so it's impossible to set far future expires headers for them to keep
them firmly in browsers caches.
Here's the link explaining this particular issue:
http://developer.yahoo.com/performance/rules.html#expires
You can see this issue in action here:
http://performance.webpagetest.org:8080/result/090218_132826127ab7f254499631e3e688b24b/
(simple two-run test of http://en.wikipedia.org/wiki/Hilary_Clinton page) -
notice that on repeat run all image requests are sent again even though images
didn't change so we get 55 extra requests with 304 responses which requires 4
more connections to the commons server (see "Connection View" section below)
all of which could be avoided. This might get even worse if we'll test
consequent views with pages sharing only some images - in this case loading
images after the ones that were already requested will be blocked.
I didn't try to calculate traffic savings (can be significant even though it's
only headers that are being sent), but it can be done based on some statistics.
The good news is that MediaWiki already has control over the versioning of
uploaded files (which is most important for images) so the solution would be to
just make unique query string for each version of the image.
It looks like solutions for local file store and remote stores might be
different, but I created a patch that relies on getTimestamp to be implemented
accordingly in each subclass (LocalFile.php / ForeignAPIFile.php and so on).
Another, much "cleaner", approach would be to use file revision number instead
of timestamp, but it'll require more knowledge of file store implementation
which I lack. It might be heavier on CPU though as it'll require getting
history from the database.
Anyway, I'm attaching a patch that already works for local file repository
where timestamp implementation works fine.
You can see result of this patch here:
http://performance.webpagetest.org:8080/result/090219_289bbf4e150b039459abe3ba3d3ce148/
(notice, that on second run only the page is requested).
If it all sounds right, I can apply this patch to the tree.
Sergey
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
