Closed Bug 1133409 Opened 7 years ago Closed 6 years ago

Fira fonts served with the wrong MIME type

Categories

(Websites :: wiki.mozilla.org, defect)

Production
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: GPHemsley, Unassigned)

References

Details

It seems we are loading our Fira fonts 4 times per page, and they are being served as text/plain. They are significantly dragging down the load time of each page (when logged in, at least), and I'm surprised they're even rendering.
I believe this is a server config issue. 

Adding the following entries to the apache config should fix it:

AddType application/vnd.ms-fontobject  eot
AddType application/x-font-ttf         ttf ttc
AddType font/opentype                  otf
AddType application/x-font-woff        woff

Here's a PR to address conf of sandbox and localdev:
https://github.com/mozilla/wiki.mozilla.org/pull/17
Whiteboard: [dev=2015-02-26]
Whiteboard: [dev=2015-02-26]
Changes applied to dev
Assignee: nobody → jcrowe
Whiteboard: [kanban:https://webops.kanbanize.com/ctrl_board/2/634]
So far I am only able to reproduce this in Firefox. Chrome and Safari do not show multiple requests for the same font file.

Changing the mime type of the returned font seems to have no effect. 

I've also tried a configuration where the fira.css is included directly by the Sandstone extension and not with an @import statement. No effect with this change either.
Here are some webpagetest results:

IE9: http://www.webpagetest.org/result/150226_TA_1DKB/1/details/

And even more puzzling, here's the Firefox one:
http://www.webpagetest.org/result/150227_KA_67/1/details/
Also worth noting this is happening on other Mozilla sites so this may not be mediawiki specific:
https://marketplace.firefox.com/
Possibly related to bug 1060767?
Depends on: 1060767
Based on comment 6, comment 7, and bug 1060767, it seems like this may have been identified as a Firefox issue rather than a webserver issue.

:ckoehler, should we keep this bug open for further investigation on the servers? Should we rollback the dev changes or proceed to stage/prod with them regardless of their lack of help?
Flags: needinfo?(ckoehler)
(In reply to Richard Soderberg [:atoll] from comment #7)
> Based on comment 6, comment 7, and bug 1060767, it seems like this may have
> been identified as a Firefox issue rather than a webserver issue.
> 
> :ckoehler, should we keep this bug open for further investigation on the
> servers? Should we rollback the dev changes or proceed to stage/prod with
> them regardless of their lack of help?

The truth is, this bug actually covers two issues: The problem with the MIME types of the fonts, and the browser bug that for some reason downloads them four times.

The changes that have already made it into our pipeline are still needed changes, and we should let them proceed.

And I'm OK if we let bug 1060767 be the sole tracker of the browser bug.
Flags: needinfo?(ckoehler)
Summary: Problems with Fira fonts → Fira fonts served with the wrong MIME type
(In reply to Christie Koehler [:ckoehler] from comment #1)
> I believe this is a server config issue. 
> 
> Adding the following entries to the apache config should fix it:
> 
> AddType application/vnd.ms-fontobject  eot
> AddType application/x-font-ttf         ttf ttc
> AddType font/opentype                  otf
> AddType application/x-font-woff        woff
> 
> Here's a PR to address conf of sandbox and localdev:
> https://github.com/mozilla/wiki.mozilla.org/pull/17

OTF should use 'application/font-sfnt'.
(In reply to Gordon P. Hemsley [:GPHemsley] from comment #9)
> (In reply to Christie Koehler [:ckoehler] from comment #1)
> > I believe this is a server config issue. 
> > 
> > Adding the following entries to the apache config should fix it:
> > 
> > AddType application/vnd.ms-fontobject  eot
> > AddType application/x-font-ttf         ttf ttc
> > AddType font/opentype                  otf
> > AddType application/x-font-woff        woff
> > 
> > Here's a PR to address conf of sandbox and localdev:
> > https://github.com/mozilla/wiki.mozilla.org/pull/17
> 
> OTF should use 'application/font-sfnt'.

On second thought, it looks like there is a valid proposal for the 'font' type now:

http://dev.w3.org/webfonts/WOFF2/spec/#IMT

We should discuss this further.
(In reply to Gordon P. Hemsley [:GPHemsley] from comment #8)
> (In reply to Richard Soderberg [:atoll] from comment #7)
> > Based on comment 6, comment 7, and bug 1060767, it seems like this may have
> > been identified as a Firefox issue rather than a webserver issue.
> > 
> > :ckoehler, should we keep this bug open for further investigation on the
> > servers? Should we rollback the dev changes or proceed to stage/prod with
> > them regardless of their lack of help?
> 
> The truth is, this bug actually covers two issues: The problem with the MIME
> types of the fonts, and the browser bug that for some reason downloads them
> four times.
> 
> The changes that have already made it into our pipeline are still needed
> changes, and we should let them proceed.
> 
> And I'm OK if we let bug 1060767 be the sole tracker of the browser bug.

Okay, that works for me. But the question remains outstanding: how can Webops be of further assistance to you at this time? If there's nothing we can currently do to be of assistance here, I'd like to close this bug.

Comment 2 applied certain mime/type changes to the dev server, but there's no indication that they were applied to stage/prod, so I'd like to bring stage/prod into sync with dev again.

Should we be preparing to ship the dev changes to stage/prod, or should we revert the dev changes, or should we apply a new set of changes to dev?
Whiteboard: [kanban:https://webops.kanbanize.com/ctrl_board/2/634]
Whiteboard: [kanban:https://webops.kanbanize.com/ctrl_board/2/933]
Whiteboard: [kanban:https://webops.kanbanize.com/ctrl_board/2/933]
Whiteboard: [kanban:https://webops.kanbanize.com/ctrl_board/2/935]
Sorry for the noise.
Whiteboard: [kanban:https://webops.kanbanize.com/ctrl_board/2/935]
Assignee: jcrowe → nobody
So, what I can discern above, everything is working perfectly now (Firefox only requests once, verified in latest stable waterfall) no matter what the mime/type, and there's nothing we can do in the Mediawiki theme to enforce the mimetype. We could alter it for absolute preciseness on wikimo, but there's no apparent value in spending further time on this, so I'm going to INCOMPLETE it.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.