I get the full suite for $45 a month and Typekit is included. You have to have an adobe subscription and I am not sure what the minimum for that is. You have to specify which urls can use your kit which should include Hubspot's preview and sandbox staging url. Typekit from Adobe allows you to create importable font kits, similar to how google font works, and I believe they have more fonts. Google fonts is the easiest but has the least amount of fonts because it is free and open to use. These approaches may be a good starting point if, in the future, we want to use Source Han Sans, the Source font version for Chinese, Japanese and Korean character sets.Are a couple of methods for adding fonts to your site. Note: The Myriad typeface is not a system font, but comes bundled with Adobe Reader 7.0 and higher. I propose we change to a font stack based on humanist sans-serifs, SSP's typeface classification:įont-family: 'Source Sans Pro', 'Myriad Pro', 'Myriad Web Pro', 'Lucida Grande', 'Lucida Sans Unicode', 'Lucida Sans', 'Segoe UI', Calibri, sans-serif Currently we are using a font stack based on neo-grotesque sans-serifs. So I took a look at the font stack being used at GitLab to see if this issue could be mitigated when those “missing” characters were visible. If we would be loading only the Latin subset for these browsers, other character subsets won't use the custom webfont. What Google does is serve those browsers a single WOFF file with only the Latin subset - I wasn't able to replicate this functionality in my POC, but it should be doable through server-side conditional content (?). Those browsers partially ignore the rule and download all webfonts, no matter if they are being used on the page or not. The unicode-range rule is not properly supported in Safari, IE and Edge. Test it yourself: įor the POC, I'm using the JS detailed on this blog post, but I've also found another alternative (maybe better). Testing on my browser (Chrome / Mac OS X 10.11.6) the browser cache was 93% slower than localStorage. There has been some discussion about this, but overall it seems there are real speed improvements: We can take advantage of localStorage in order to speed up consequent visits, instead of relying on the good old cache. As written before, the Latin subset composes most (if not all) of the words in GitLab's UI. We can achieve another optimization if we rely on localStorage for the Latin subset webfonts. That's 83% of file size savings when compared to the current setup. On a regular day at, a user will only have to download 43 KB for the Latin characters of the SSP font in all three weights. Note: The subsetted fonts contain fewer characters than the current font (full) because not all characters are usually used (e.g. WOFF2 file sizes after subsetting and compression: Version/subsetĬomparing the WOFF2 file sizes: Current (1,936 chars) They are also used by Google to subset the webfonts used at various Google services and websites. They are used by Google to subset webfonts and deliver them through the Google Web Fonts service. Each 'namelist' file contains a list of unicode characters for a specific character set/encoding. In the POC, I took SSP's latest version files and split into seven characters subsets, using Google's 'namelist' files, tools and dependencies. Modern browsers take advantage of this rule to only download the webfont files that pertain to the characters visible on the page. This approach takes advantage of the unicode-range CSS rule, where each declaration is associated with a specific set of unicode characters. This is how Google is delivering the Roboto webfont at Google Plus. My proposal is to split SSP into several smaller webfont files, one for each character subset (this is called subsetting). The only character subset that is used for certain is the Latin subset, for GitLab's UI (English). I think it's safe to assume that most of these characters go unused/unseen by a GitLab user. To support all possible languages and scripts at GitLab, we are currently loading the complete version of SSP (1,936 characters), which includes Cyrillic, Greek, and Vietnamese character subsets. I've made a proof-of-concept (POC) of the proposal: Character subsets There are two parts to my proposal: character subsets and localStorage. On subsequent visits, the webfont files are cached. On Chrome, GitLab CE project page total size is 759 KB, of which 253 KB (33.3%) is going to Source Sans Pro (regular, semibold and bold WOFF2 files). ProblemĪs reported on, Source Sans Pro (SSP GitLab's custom webfont) is taking a big chunk of page size on the first visit. This comes as a consequence of the discussion held at, about ditching custom webfonts (specifically Source Sans Pro) and relying only on system fonts.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |