Wikimedia Bugzilla is closed!

Created attachment 8632 [details]
Sample of JSON data for WebFonts as stuffed into every page's HTML

To illustrate, this entire structure gets pumped out in the body of every page on my test wiki with WebFonts enabled. It's pretty huge!

Every font lists three or four distinct URLs for eot, ttf, woff, and svg files, which are almost entirely identical to each other.

It would be a lot more efficient to combine some data, for instance instead of:

fonts: {
  RufScript: {
    eot: "/trunk/extensions/WebFonts/fonts/en/Rufscript.eot"
    ttf: "/trunk/extensions/WebFonts/fonts/en/Rufscript.ttf"
    woff: "/trunk/extensions/WebFonts/fonts/en/Rufscript.woff"
  },
  Perizia: {
    eot: "/trunk/extensions/WebFonts/fonts/en/Perizia.eot"
    ttf: "/trunk/extensions/WebFonts/fonts/en/Perizia.ttf"
    woff: "/trunk/extensions/WebFonts/fonts/en/Perizia.woff"
  }
}

we could have:

base: "/trunk/extensions/WebFonts/fonts",
fonts: {
  RufScript: {
    file: "RufScript",
    formats: ["eot", "ttf", "woff"],
  },
  Perizia: {
    file: "Perizia",
    formats: ["eot", "ttf", "woff"],
  },
}

or heck, you could eliminate more data for common cases: if the filename's the same as the font name, leave it out! Collapse the format lists to a string:

base: "/trunk/extensions/WebFonts/fonts",
fonts: {
  RufScript: {
    as: ["etw"],
  },
  Perizia: {
    as: ["etw"],
  },
}

Of course if adding other fonts not from the default set, or for those that need additional metrics, more info needs to go in as well.

There may also be a benefit to moving this data to a ResourceLoader module and loading it separately... as it is we have all the downsides of having to wait for core modules to get loaded, plus the downside of putting JavaScript into every page so it balloons up our data size.

Putting the font info into page HTML also means that new fonts won't be picked up on cached page views.

Fixed in r95840 and r95842. I didn't pursue optimizing the every last byte out - I think this is good enough.