Matt Miklic 7:33 pm on November 11, 2013
Tags: 3.8 ( 31 ), fonts ( 2 ), open sans

Open Sans, bundling vs. linking

In Wednesday’s 3.8 planning meeting we discussed hotlinking vs bundling Open Sans. MP6 followed Twenty Twelve’s example by linking to Google Webfonts, but the consensus from Wednesday’s chat was that bundling would be preferable.

I began experimenting with this last week; first determining which font formats were necessary to include. I settled on WOFF and SVG as the two formats that would cover every browser we’re aiming to support. I left out TTF and EOT as they add only marginal browser support (IE8), but would add significant weight to the WordPress download. We do include TTF and EOT versions of Dashicons, since loading those icons is essential to usability in a way that loading Open Sans is not.

The bundled Open Sans webfonts come from FontSquirrel. The Western Latin and Basic Latin subsets are small and include enough characters for English language support. Those subsets do not include a full set of glyphs for other languages, however (they’re available as separate downloads). There is a non-subsetted version of the font available which includes all necessary glyphs, but it’s 2x–2.5x the file size of the subsetted fonts, which add significant overhead to the pageload and can actually crash some mobile browsers. The Western Latin and Basic Latin subsets can cause missing characters (spaces or boxes) to appear in text using accented characters, which is a significant usability concern.

Google Webfonts solves both the character set and the font format problems by intelligently loading the font format and the character subset that’s needed for a particular browser and a particular website, and nothing more. For us to bundle Open Sans with WordPress, we need a way to accomplish that without adding significant heft to the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. WP download. I’m starting this P2P2 A free theme for WordPress, known for front-end posting, used by WordPress for development updates and project management. See our main development blog and other workgroup blogs. thread to open up the discussion on how we might do that.

#3-8, #fonts, #open-sans

Matt Mullenweg 7:43 pm on November 11, 2013

It’s also worth noting if we can solve this in a standalone way (the script not loading any of the rest of WP) we avoid licensing issues and also solve a general problem many people across the web have.

Also keep in mind if this takes longer than a few days the right answer for 3.8 might be linking in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and releasing a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party for people that bundles for people that don’t like Google.
- Piet 4:28 am on November 12, 2013
  
  I think it doesn’t have so much to do with liking or not liking Google. There are certain countries where Google is blocked and that includes loading their fonts. For all sites I built (I live in China), I bundle fonts, because only then I can be sure that these fonts load.
  That might be another argument pro-bundling 🙂
  - krembo99 6:03 am on December 22, 2013
    
    I am with Piet – Have the same problems in china ( and elsewhere – granted – all totalitarian regimes, but still .. ). Google services work only sporadically . Fonts , jQuery CDN , Maps etc. Linking those resources makes the page time-out .
Doug Wollison 8:41 pm on November 11, 2013

Regarding the missing characters, don’t just about all browsers fallback to the next font in the font-family list for those characters?
- Matt Thomas 8:43 pm on November 11, 2013
  
  Most do, but unfortunately not all — including some important ones like Android Browser as late as version 4.3.
  - Doug Wollison 9:22 pm on November 11, 2013
    
    That actually doesn’t surprise me in the least now that I think about it.
mindctrl 8:46 pm on November 11, 2013

Relying on a third party for fonts in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. doesn’t make me want to do cartwheels. It’s a backdoor analytics of sorts, and a privacy concern. The increased file size is the lesser of two evils. Neither option is ideal.

I love Open Sans, but given the two options, I’d rather see Arial. *runs for cover*. I just tested swapping out Open Sans for Arial in trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision., and it’s really not that bad. Theming the WP adminadmin (and super admin)/MP6 via plugins would be a great way for people to opt into hosted font solutions.
- Doug Wollison 9:21 pm on November 11, 2013
  
  Or, the better compromise; Helvetica (Neue if possible), finally falling back to Arial if things get desperate.
  - mindctrl 9:26 pm on November 11, 2013
    
    I thought the same thing originally. Helvetica Neue isn’t that bad, but it’s also not standard on a number of platforms. Neither is Helvetica. This was news to me. I don’t know of a definitive list online, but this one from MailChimp is helpful, and the reason I said and tried Arial. http://templates.mailchimp.com/design/typography
    - mindctrl 9:27 pm on November 11, 2013
      
      Sorry, actually standard Helvetica is.
      - jwarren 11:09 am on November 13, 2013
        
        If we’re going with system fonts, it should probably just be standard ‘san-serif’, which will be Helvetica on OSX, Arial on Windows, and whatever has been deemed appropriate on the Linux distro of choice. It also allows people and browsers to override that easily for their own purposes – perhaps a different language, perhaps extra visual clarity, perhaps an unusual display technologo… who knows?
Robert Dall 9:41 pm on November 11, 2013

I have never really like relying on a third party service to do what could be done internally.

Also what if you are developing locally without access to the internet?

Regardless of who provides the free service. One day Google (or Adobe who just started there own free font embedding service) “could” turn around and say. “Ya were not going to do that free font thing anymore”

Now it would be easy to swap it out but why rely on something like that anyways.
- Matt Thomas 9:50 pm on November 11, 2013
  
  To be clear, we’re talking about linking to Google Fonts for Open Sans just until we can solve this in a standalone way, as @matt mentioned above.
  
  If you’re working locally with no internet connection, the fonts will just fall back to the browser-defined “sans-serif” font (Helvetica on OS X, Arial on Windows by default).
Ryan Hellyer 10:04 pm on November 11, 2013

I suspect that bundling scripts into WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. will create privacy concerns for many people. The ability to perform analytics via them will disturb a small segment of the user-base.

It may even be illegal in some countries. Germany springs to mind in regards to that. They’re already super ticked off about being spied on at the moment, so I think it might be best if WordPress doesn’t join the party too.

And yes, you can install a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party to force them to be self-hosted, but many people will just unwittingly hit the “update” button without ever realising that they’re opening themselves up to privacy issues.
- Doug Wollison 10:10 pm on November 11, 2013
  
  What if we take a progressive enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. approach? By default, we wouldn’t actually load Open Sans from anywhere, and instead just falls back to whatever font it can. Then we offer plugins (or packaged right in the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.) options for self hosted or google hosted.
- daveshine (David Decker) 11:49 pm on November 11, 2013
  
  Almost any modern theme loads Google Fonts already, including some of the default themes, plugins not counted…
  
  I have absolutely nothing against loading Open Sans from Google, and find it a rather good option to do so.
  
  Yes, there are lot of issues with privacy that should be done better – in my opinion this topic here falls not amongst them…. just my personal view.
  
  Thanks, Dave from Germany 🙂
Dion Hulse 11:14 pm on November 11, 2013
There is a non-subsetted version of the font available which includes all necessary glyphs, but it’s 2x–2.5x the file size of the subsetted fonts, which add significant overhead to the pageload and can actually crash some mobile browsers.

If we actually want to use Open Sans for WordPress, this is unfortunately what we have to do.
- Open Sans (WOFF+SVG for Italic, Regular, SemiBold, and SemIbold+Italic) weighs in at 576K uncompressed (92K WOFF, 484K SVG), 174K compressed.
- Open Sans (WOFF+SVG for Italic, Regular, SemiBold, and SemIbold+Italic w/ full charset support ) weighs in at 4.5MB uncompressed (345K WOFF, 4.2MB SVG), 826K compressed.
The SVG’s will compress well as they’re just text, WOFF is already compressed. We could have a light-weight PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher script that served compressed documents intelligently depending upon the client (selectively adding Charsets based on WPLANG / browser UA), but this has caching issues amongst other things.

If we actually look at what the fonts are for though…
- WOFF is the primary font, it’s supported by most browsers.
- SVG is included for iOSiOS The operating system used on iPhones and iPads. 3.2-4.3 support, and for Android Browser 4.0-4.3.
Given the significant size of SVG fonts, it makes me question if we should be using them at all, it doesn’t add much extra browser support.

An alternative is shipping with WOFF+TTF fonts – that would add support for iOS 4.2-4.3 (iOS 3.2 misses out), and Android 2.2-4.3 (SVG only works for 4.0-4.3).
- Open Sans (WOFF+TTF for Italic, Regular, SemiBold, and SemIbold+Italic w/ full charset support ) weighs in at 1,000K uncompressed (345K WOFF, 661KB TTF), 689K compressed.
or.. just drop Open Sans for those mobile clients.. since it really doesn’t seem worth it.. WOFF supports most desktop browsers and modern mobile devices, and we should have a GOOD font fallback list for unsupported browsers (which we don’t currently have with MP6, but we did previously have in WP 3.6).
- Dion Hulse 11:22 pm on November 11, 2013
  
  I also missed that SVG is also for Mac Safari 3.2-5.0, not just for iOSiOS The operating system used on iPhones and iPads.. TTF is supported in Safari 3.1-5.0 as well.
  TTF/SVG is also needed for older Opera versions (desktop and mobile, and some gaming systems), but WOFF is supported for v11+ so that doesn’t seem like a deal breaker at all (coming from an Opera user..)
- Matt Thomas 11:48 pm on November 11, 2013
  I don’t recommend using the un-subsetted font for any solution because of the extra page weight that every user would incur. Intelligently loading the correct subset for the specified language is the best possible user experience, whether it’s linked to from Google fonts or we implement our own solution that accomplishes the same result. Just for comparison, this is the size difference for a single weight and style of Open Sans (we need four: regular, italic, semibold, and semibold italic).
  - English subset, WOFF: 13 KB
  - Czech subset, WOFF: 17 KB
  - Full charset, WOFF: 85 KB
  - English subset, SVG: 32 KB
  - Czech subset, SVG: 70 KB
  - Full charset, SVG: 1.1 MB
  - Dion Hulse 12:01 am on November 12, 2013
    
    So yes, I’d never suggest SVG for this.. ever..
    
    WOFF however, we can get away with including the full set, the extra page load isn’t significant once it’s in the cache.
    
    Most web services will get away with only loading one subset as they know what the characters on the page are, WordPress doesn’t really know the answer to this, French accented characters can appear in an English post, etc.. so relying upon WPLANG is a rather bad idea for this.
    
    One method would be to have JavascriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. detect the characters on the page and load the english by default, and optionally load the larger CSSCSS Cascading Style Sheets. if it spots any of those characters..
    
    Even Google Fonts requires you to specify which subsets you want to load, it can’t automatically guess what’s on the page.. so it’ll have the same page load issues (except that you gain benefit from their extra-special browser compression and CDN).
davelab6 5:30 am on November 12, 2013

Disclaimer: I consult for Google, Adobe and other companies on web fonts and libre fonts issues, but I represent only myself. This is my own personal opinion.

One day Google (or Adobe who just started there own free font embedding service) “could” turn around and say. “Ya were not going to do that free font thing anymore”

Anyone can see that Google uses the Fonts APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. for its own web apps and web pages. Since the fonts are libre licensed, if that day ever comes, switching is possible.

If you’re working locally with no internet connection, the fonts will just fall back to the browser-defined “sans-serif” font (Helvetica on OS X, Arial on Windows by default).

If you’re working locally, you can install the fonts, and if the CSSCSS Cascading Style Sheets. includes them with ‘local’ (as the Google Fonts API css does) then they’ll load 🙂

For WordPress to self host the fonts, in a way that matches the fonts served by Google’s Fonts API, you’ll want to subset them by language, and also have versions with the hinting removed to serve to browsers on platforms that don’t use hints, and perhaps also CFF versions for platforms with good CFF rendering. Since WordPress doesn’t have a dynamic font subsetter, you’ll need a set of language subsets and a set of hint subsets.

WOFF, SVG, TTF, EOT is needed for full browser support, in descending order of importance. If you leave out formats, you will leave out users. Maybe that matters, maybe it doesn’t.

By using the Google Fonts API you support all users on all platforms. The API doesn’t carry a cookie, so there aren’t the same privacy implications.
- Matt Thomas 4:15 pm on November 18, 2013
  
  Thanks Dave, this is good information to have. Aside from the font format issue — I think we could get by with WOFF and SVG or TTF, based on the browsers we have chosen to support (others would just fall back to browser-standard sans-serif as in 3.7). But hinting and internationalization are big issues that will be thorny to solve with a bundled solution.
jwarren 11:14 am on November 13, 2013

I would suggest that bundling would be ideal – who know what strange systems WordPress could be running on if/when Google eventually deprecates their fonts service? It also keeps the experience consistent for any isolated environments. Local development away from a consistent internet connection is not an infrequent occurrence, and the fewer 404s, the better.
thefuxia 3:17 am on November 17, 2013

MIME types for fonts are not always set up properly on the web server. I just had such a case recently, where the browser showed garbage on first load because of that. The second load took the fonts from cache, and the browser applied the correct glyphs.
Louy Alakkad 2:25 pm on November 17, 2013

How about using the ‘open-sans’ fonts by default and giving the user three options in theme settings, first is open-sans, second is google fonts and third is downloading a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party that contains all the fonts needed?
Anderton 1:08 am on November 18, 2013

Also, Google is blocked in some countries (i could for example not use Google Fonts in China now and then). Now this is no issue with the bundling open san. But for reference: http://www.google.com/transparencyreport/traffic/disruptions/#expand=Y2013
Milan Dinić 4:50 pm on November 18, 2013
I vote for ditching Open Sans for reasons already mentioned in this thread:
- Why would we all of sudden rely on external service for essential part of WordPress that is adminadmin (and super admin) area? Then why don’t we also load jQuery from Google, at least that way there would be real benefit since it would save billions of request?
- Why would we decide which subset to use based just on WPLANG? What with those that use admin in English even though content is in other language? What for multilanguage? Some browsers don’t do proper fallback and we’ll end with squares and other garbage. If Open Sans gets in, all subsets should be included, that’s the price of using nonstandard font.
- Possible server issues.
mor10 7:41 pm on November 19, 2013

For the default theme any custom font needs to be bundled for a simple reason: Not every WordPress installation runs on a computer connected to the web. There are many scenarios in which the site is not connected to the web: It could be a standalone application entirely severed from any networknetwork (versus site, blog), it could be a site hosted on a secure intranet, the list goes on. As an external font library would result in a non-standard experience for these use scenarios I would encourage the inclusion of any custom font in the package itself. And for those same scenarios the inclusion of TTF and EOT might well be necessary since many of these users (European hospital intranets is one example) are stuck behind old system architecture that doesn’t support IE9 and above. Keep in mind that IE9 requires Windows 7, an update not yet undertaken by large parts of government and large industry landscapes.
Milan Dinić 5:11 pm on November 28, 2013

I have coded a simple plugin that disables loading of Open Sans from Google’s servers. If you have any comments about it (including its name), please share and I’ll submit it to repository in a few days.
mighty_mt 7:34 pm on December 10, 2013

So what’s the status here? I see in 3.8-RC2 (and also in MP6 2.2.1) that Open Sans is still loaded from Google. And to be honest, I don’t like that.
I also think that WordPress shouldn’t use web fonts for the adminadmin (and super admin) at all (especially not ones loaded from third party servers). Even though the new admin looks very pretty with Open Sans.
Alex Nguyen 1:48 am on December 15, 2013

Is there any way to disable Open Sans in the new 3.8 update? My blogblog (versus network, site) is in Vietnamese and Open Sans does not display Vietnamese characters properly.
- Sergey Biryukov 8:18 pm on December 21, 2013
  
  See Milan’s pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party mentioned above: https://wordpress.org/plugins/disable-google-fonts/.
Paul 8:36 pm on December 19, 2013

Would love to dequeue open sans, it was a lovely idea but on a unstable african ISP its making editing on a clients site an unbearable experience – and I’m fairly privileged – honestly a standard stack would suit me fine, or just ‘sans-serif as someone suggested above.’. I really don’t thing open sans looks that great to boot.
ElectricFeet 12:44 pm on February 19, 2014

If it must be linked and not bundled (and I defer to your expertise on that decision), the best option would be to have a simple checkbox in “Edit my profile”: Use Google fonts for adminadmin (and super admin) area?

Apart from privacy concerns, linking on local dev environments really slows things down.

(I’m using Milan’s pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party for now. Thatnks Milan!)
owcv 4:23 pm on February 24, 2014

I’m not happy with this kind of integration of Google on my WordPress Website. I don’t want big brother to watch my site. Open Sans should be included in WordPress but not linked to Google. At least there should be an option to deactivate for users in countries with certain information privacy policies. In the EU for example this could be a violation of actual law!

Comments are closed.

Welcome!

Communication

Open Sans, bundling vs. linking

Welcome!

Communication

Share this: