https://en.wikipedia.org/wiki/Scalable_Vector_Graphics#Compression
SVG images, being XML, contain many repeated fragments of text, so they are well suited for lossless data compression algorithms. When an SVG image has been compressed with the industry standard gzip algorithm, it is referred to as an "SVGZ" image and uses the corresponding .svgz filename extension. Conforming SVG 1.1 viewers will display compressed images.[8] An SVGZ file is typically 20 to 50 percent of the original size.[9] W3C provides SVGZ files to test for conformance.[10]
Every web browser that supports SVG supports SVGZ as it is just a standard gzip HTTP encoding.
Having this in core means that every contrib developer can have confidence that SVGZ will work.
Problem/Motivation
Drupal is not serving SVGZ files with the correct encoding.
Proposed resolution
All that is required is for these two lines to be added to .htaccess as described here: http://kaioa.com/node/45
AddType image/svg+xml svg svgz
AddEncoding gzip svgz
nginx can also be configured to serve SVGZ correctly. At my request, Pantheon have already updated their nginx configuration to support it and I have confirmed that it works.
I have also modified web.config for IIS as described here: http://forums.iis.net/t/1175276.aspx and confirmed that it works.
Remaining tasks
none
Beta phase evaluation
Issue category | Bug because Drupal is not serving SVGZ correctly by default. This means contrib developers cannot have confidence that SVGZ will work. |
---|---|
Issue priority | Normal because only one piece of functionality is affected. |
Prioritized changes | This is prioritized because it is a bug fix and because it needs to be backported to Drupal 7. |
Disruption | This issue is not disruptive at all. |
Comment | File | Size | Author |
---|---|---|---|
#43 | d7-svgz_isn_t_served_with-2092245-43.patch | 810 bytes | vinmassaro |
#37 | svgz.patch | 1006 bytes | jbrown |
#34 | interdiff.txt | 540 bytes | jbrown |
#34 | svgz.patch | 4.33 KB | jbrown |
Comments
Comment #1
OostieI tried to apply the patch, but it failt applying on core/modules/system/css/system.theme.css and core/modules/toolbar/css/toolbar.icons.css because of some changes in the css files.
There also have been added some new svg files that need to be converted to svgz:
Comment #2
jbrown CreditAttribution: jbrown commentedThanks Oostie!
Here's a reroll.
Comment #3
naxoc CreditAttribution: naxoc commentedThis looks good to me. It would be great to have this in drupal.
The only thing I am not sure about is the web.config. I can't really test that in any way, so it would be great if someone with a Windows machine could test that.
Comment #4
jbrown CreditAttribution: jbrown commented@jessebeach requested that the SVGs be left in the repository. This patch fixes that.
Comment #5
naxoc CreditAttribution: naxoc commentedTagging to see if someone with a windows machine will take a look. Patch still looks good to me.
Comment #5.0
naxoc CreditAttribution: naxoc commentedUpdate pantheon info.
Comment #6
jbrown CreditAttribution: jbrown commentedThere were some new SVGs in core/modules/edit/css/edit.icons.css
Comment #6.0
jbrown CreditAttribution: jbrown commentedFix IIS weblink.
Comment #7
jurgenhaasSounds good to me, just wondering if providing two static files with the same content (svg and svgz) is the best approach or if we shouldn't include a process to generate the compressed versions on the fly. That way this would be done dynamically even if anyone added more SVG files further down the road - either in core or in contrib.
Comment #8
mherchelThat patch screws up IIS pretty bad.
I downloaded the latest d8 via git. Installed, and tested. Worked fine.
Then I applied the patch. Now, the HTML gets generated, but all assets get 500 Internal Server Errors. This includes css, js, and images.
Let me know if there's anything you want me to try, or any more info I can get you. :)
Also, this was tested under IIS 7.5 running PHP 5.4 on Windows Server 2008R2 SP1.
Screenshots below:
Drupal 8 working before patch:
After patch:
Comment #9
mherchelI found the issue. The problem was that the patch was redeclaring the svg mime type (which isn't allowed).
Removing the
<mimeMap fileExtension=".svg" mimeType="image/svg+xml" />
line fixes the problem.So, the web.config should read:
Removing that line fixes the issue, and I successfully tested with Chrome, FF, and IE.
Comment #10
jbrown CreditAttribution: jbrown commentedThanks so much @mherchel!!
I have updated the patch with the change you recommended.
@jurgenhaas in theory SVGZ could be generated on the fly by Assetic, but this is a separate issue.
Comment #11
mherchelConfirmed that patch in #10 applies and works perfectly for IIS.
Let me know if there's anything else. :)
Comment #12
jbrown CreditAttribution: jbrown commentedan RTBC? ;-)
Comment #13
jbrown CreditAttribution: jbrown commented#10: svgz.patch queued for re-testing.
Comment #13.0
jbrown CreditAttribution: jbrown commentedUse summary template
Comment #13.1
jbrown CreditAttribution: jbrown commentedno remaining tests
Comment #13.2
jbrown CreditAttribution: jbrown commentedIIS has been tested
Comment #14
jbrown CreditAttribution: jbrown commented10: svgz.patch queued for re-testing.
Comment #15
kbell CreditAttribution: kbell commentedOn a related note, I have just confirmed with Support at Pantheon that SVG compression itself is not currently supported on Pantheon. It IS on the near-term roadmap for new features, but it is NOT yet in production (or even being beta tested). The SVGZ support in the OP IS present, just not any SVG compression.
I have added a request that it be added (one more person requesting can't hurt). If this feature is important to you and you're a Pantheon client (as I am), please let them know this feature is really important to you, and maybe they'll bump it up the queue?
Cheers,
Kelly Bell
Comment #16
jbrown CreditAttribution: jbrown commentedkbell: Are you talking about live compression of SVG files by the webserver? That is not what this issue is about.
Comment #17
jhedstromComment #18
rpayanmComment #20
rpayanmLet me try again.
Comment #22
jbrown CreditAttribution: jbrown commentedTesting...
Comment #23
jbrown CreditAttribution: jbrown commentedComment #24
jbrown CreditAttribution: jbrown commentedComment #25
Wim LeersThese are clear wins, because they ensure the web server supports commonly used file formats. They also don't affect the TX.
(And same for many other SVG files.)
These aren't clear wins.
I'm all for improving front-end performance, but it feels like this might be too intrusive for the TX.
It's easy enough: rename a SVGZ file to "SVG.GZ", then it's extractable like any gzip file (on OS X), and you get the original SVG to work with.
But why do we have to ship with this? Why can't it be up to the web server to do this?
Finally: this part of the patch does not match the issue title/IS.
Please consider doing only the "support SVGZ" bit in this patch, then it can go in easily. Converting Drupal core's SVGs can be a follow-up issue.
Comment #26
jbrown CreditAttribution: jbrown commentedThanks Wim.
I'll re-roll with just the SVGZ support.
There is another issue to zip the SVG files on the fly, but this will cause increased CPU load: #2448387: Ensure that anything not already compressed is compressed on the fly
Comment #27
jbrown CreditAttribution: jbrown commentedComment #28
Wim LeersThanks!
Only thing preventing me from RTBC'ing this: a beta evaluation. Please add that to the IS, then this is RTBC!
Comment #29
Wim LeersFor #28.
Comment #30
jbrown CreditAttribution: jbrown commentedI wrote a test. Will update summary.
Comment #31
jbrown CreditAttribution: jbrown commentedComment #32
jbrown CreditAttribution: jbrown commentedComment #33
Wim LeersThanks for the beta evaluation!
Super nitpicky nitpick that can be fixed upon commit:
We put a newline after the last method.
Comment #34
jbrown CreditAttribution: jbrown commentedAdded the blank line.
Comment #35
alexpottThis issue is a normal bug fix, and doesn't include any disruptive changes, so it is allowed per https://www.drupal.org/core/beta-changes. Committed 84c2ccf and pushed to 8.0.x. Thanks!
Comment #37
jbrown CreditAttribution: jbrown commentedSorry - my bad. I left out the web.config changes from @mherchel
Comment #38
Wim Leers@jbrown: I'm afraid you'll have to file a new issue.
Comment #39
Wim LeersComment #40
ChaseOnTheWebDoes this still need porting to 7.x per #35?
Comment #41
xjmComment #42
jbrown CreditAttribution: jbrown commentedHere's the issue to fix it on IIS: #2467437: SVGZ isn't served with correct encoding by IIS
Comment #43
vinmassaro CreditAttribution: vinmassaro commentedHere's a patch for D7.
Comment #44
osopolarPatch in #43 works for me, thanks.
Comment #50
juankvillegas CreditAttribution: juankvillegas commentedThis should be included in Drupal 7 too. Patch #43 do the work.