Enable text compression

[marimeireles]

I was running some profilers and PageSpeed gave me this result:

I've already wrote a little bit about how to do that on my proposal. It might be a good thing to start from these sources.

If PageSpeed is telling the true than we can get huge improvements for mobile users. As big as the ones removing markdown-it will do.

This is somewhat related to #2747 because there are some alternatives of doing this on the server side.

[karlcow]

It seems related to #2751

[marimeireles]

Our currently gzip settings are:

##
# Gzip Settings
##

gzip on;
gzip_disable "msie6";

gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_buffers 16 8k;
gzip_http_version 1.0;

# Turn on gzip for all content types that should benefit from it.
gzip_types application/ecmascript;
gzip_types application/javascript;
gzip_types application/json;
gzip_types application/pdf;
gzip_types application/postscript;
gzip_types application/x-javascript;
gzip_types image/svg+xml;
gzip_types text/css;
gzip_types text/csv;
# "gzip_types text/html" is assumed.
gzip_types text/javascript;
gzip_types text/plain;
gzip_types text/xml;

We're not doing anything specific to the fonts.
According to my research there are many different ways to improve font loading and I'll use this issue to record my results. I'll do a few different tests to see what will work best for us.

The #2751 was specifically to add gzip compression to the server.

[marimeireles]

Running this tool will probably help.
Fonts done right on nginx.

When I add the fonts to the server I should use preload on the html to the detriment of preloading on the server, since we'll probably be using http2_push_preload on; on nginx now.

[marimeireles]

I was inspecting the fonts we use in webcompat.com and I found that we make two requests to get sourcesanpro webfont. https://fonts.googleapis.com/css?family=Open+Sans:400,600|Source+Sans+Pro:300,400|PT+Mono
It's the same request duplicated:

I think something similar is happening to the requests to get opensans:

I'll try to find out what's causing this.

P.S.: I can reproduce this in a clean profile on Chrome & also Firefox Nightly.

[karlcow]

home page. no cache. clean profile.

so I see a request to:

• https://fonts.gstatic.com/s/sourcesanspro/v11/6xKydSBYKcSV-LCoeQqfX1RYOo3ik4zwlxdu3cOWxw.woff2
  made by Referer: https://fonts.googleapis.com/css?family=Open+Sans:400,600|Source+Sans+Pro:300,400|PT+Mono
• https://fonts.gstatic.com/s/opensans/v15/mem8YaGs126MiZpBA-UFVZ0bf8pkAg.woff2
  made by Referer: https://fonts.googleapis.com/css?family=Open+Sans:400,600|Source+Sans+Pro:300,400|PT+Mono
• https://fonts.gstatic.com/s/sourcesanspro/v11/6xK3dSBYKcSV-LCoeQqfX1RYOo3qOK7lujVj9w.woff2
  made by Referer: https://fonts.googleapis.com/css?family=Open+Sans:400,600|Source+Sans+Pro:300,400|PT+Mono

So This is what is being asked:

family=Open+Sans:400,600|Source+Sans+Pro:300,400|PT+Mono

which is

• Open+Sans:400,600
• Source+Sans+Pro:300,400
• PT+Mono

This is coming from

webcompat.com/webcompat/templates/layout.html

Line 33 in 0133d3d

<link href="https://fonts.googleapis.com/css?family=Open+Sans:400,600|Source+Sans+Pro:300,400|PT+Mono" rel="stylesheet">

Let's check the blame.

This was done here
#1889

ah and in this commit there is a TODO.
a3c0624#diff-4072869350953c01f0252c7b0f5839a3R31

<!-- TODO: Remove me once refactoring is done! These are temporary, directly hotlinked to make refactoring work easie. -->

[karlcow]

And the Todo was removed in this commit.
6ace3b5#diff-4072869350953c01f0252c7b0f5839a3L33

[karlcow]

btw the 3 requests seem to be different links.

[marimeireles]

btw the 3 requests seem to be different links.

Yeah. They are different. But the content at least from the two pairs I posted seem to be the same.
I didn't find any tool to compare the content of .woff, though.

But here is an issue: you have three requests in your devtools while I have four.

Here are the four font requests on my Chrome clean profile:

I also get four requests on my Firefox with a new profile:

[marimeireles]

I think I figured it out.
It's 4 different requests. We're requesting Open Sans 400, 600 and Source Sans Pro 300, 400.
I don't understand why your devtools only shows 3 requests.

[marimeireles]

Here are some changes I propose for our text rendering:

Following up from my project. I re-ran pagespeed on webcompat.com and this is the output I got:

1. Add @font-face

Searching more about how to make fonts visible I found some pretty good articles, like this. Here are some +pros and -cons to use @font-face:

• Very Simple: Only a single CSS descriptor added to your @font-face block.
• Good support over newer platforms: https://platform-status.mozilla.org/#css-font-display but not so good at older ones

I found out that the we should use font-display: optional to optimize our font rendering, mostly because I read this post.

2. Add rel=preload

I know it only works on Chrome, but I don't see why not to use it. It doesn't do anything bad for performance on Firefox and once we implement this feature again we'll be able to use it.
Here is what it does on Chrome:
(before)

(after)

3. Try to remove FIOT by using Font Face Observer. It's a 1.3kb(gzipped) lib that notifies you once a webfont has been completely loaded. The idea is to use a system font while the webfont is loading so we don't get the invisible frames.
   This problem is relevant while opening webcompat.com on mobiles with slow internet connection and I think that the extra 1.3kb are worth it. I'll implement it and run some tests and post the results here later.

[marimeireles]

Ok, so I've been running tests with Font face observer and the FOUT effect it produces it's displeasing me a lot.
@magsout do you think it's possible to decrease this effect to a point that's almost unnoticeable? Do you know any tool that might help me on this? Currently I'm just looking for a system font that looks like the fonts we're using.

[marimeireles]

This is what I got running tests on a Nexus 5 mobile with an internet speed of 300kbps (a slow 3G connection).

It took 4 seconds to load the real font since the first meaningful paint appeared, even longer since the user made the first request to our page. Pretty bad.

I've tested in my desktop and it doesn't matter much which internet speed I'm using. I've tested with 500kbps, 1500kbps, 5000kbps and the font only takes a few seconds to load. I think those are reasonable speeds to test the website because according to this rank of world internet speeds the slowest one is 3.73mbs on Desktop. So I think we cover a lot of internets with the range I tested.

While in mobile this is a relevant upgrade to our performance it doesn't mean so much for desktop users. I was thinking that it'd be simpler if I just made this change for mobile users and not for the desktop users.

It doesn't matter how hard I try the FOUT thing will still be perceivable and I don't think it's worth it to add this ugly thing to our website when we're only saving a couple of ms.

[magsout]

@marimeireles

@magsout do you think it's possible to decrease this effect to a point that's almost unnoticeable?

You mean about FOUT?

[marimeireles]

Yes @magsout. What do you think?

[marimeireles]

Reminder: in case #2809 doesn't land I should subset our fonts because it significantly decrease the size of the font files vide #2809 (comment).

This is what we currently use: U+20,U+21,U+27,U+2A,U+2C-2E,U+30-32,U+34-36,U+38-3A,U+3F,U+41-4A,U+4C-59,U+61-7A,U+2014,U+2019,U+1F389

[magsout]

@marimeireles the better way to decrease the FOUT effect is to improve the font download. I mean, the FOUT Flash Of Unstyled Text is the moment during the brower has not download yet the font. So if you can improve the download of the font you can descrease this effect.

[magsout]

@marimeireles it's exactly what you are doing there #2809

Sometimes, is better to host our font instead of Google (because of delivrability, latency etc..)

[marimeireles]

Sometimes, is better to host our font instead of Google (because of delivrability, latency etc..)

Good to know! That's what I'm testing now.

[marimeireles]

This is what we currently use: U+20,U+21,U+27,U+2A,U+2C-2E,U+30-32,U+34-36,U+38-3A,U+3F,U+41-4A,U+4C-59,U+61-7A,U+2014,U+2019,U+1F389

According to Karl this is an awful subset of things.
I'm not going to use this one. Also, apparently we don't want to subset fonts because we should be able to reproduce all kinds of chars not only Latin ones.