fontsdropboxwoffpingdom

@import-ing fonts: Dropbox vs. Home Server, Unexpected Discrepencies


I host from home, using my home internet connection (Apache on OS X), it's not a business line or anything like that. Still, I manage to get around 20ms ping, 55mbps down and 12mbps up, just so we're clear this isn't some cut-rate DSL connection :P

Anyway, using Pingdom's Website Speed Test, I'm able to test the load times of the various files involved with a website, including HTML, CSS, Js, and .woff files.

The .woff files are for a custom font for the website, and they are hosted both on the server with the rest of the website files and Dropbox.

When I specify in the CSS file to fetch the .woffs from Dropbox, rather than the home server, Pingdom reports a generous performance increase in the website's load time. In fact it goes from about 3s down to just over 1 second to load everything, .woffs included of course.

Of course this isn't surprising because Dropbox does this for a metaphorical living, and therefore we can expect server response time and download speeds to be much better than a home server. Still, what's interesting is that Pingdom reports the .woffs to be a LOT smaller when they come from Dropbox- as much as 95% smaller. All this, when the link to Dropbox is SSL, too.

I tried finding more info on how Dropbox converts or compresses uploaded files, but I'm not finding much. Additionally, when the font is re-downloaded from Dropbox, it is at its original, much larger size.

Does anyone know anything about this? Does Dropbox automatically optimize .woff files for @import-ing? Seems a little magical... Also, it seems like it's taking the home server quite a while to deliver the .woff files, perhaps this is just standard for a home-grade internet connection, but it strikes me as excessively-slow. Each .woff is about 100kB.

I'd love to post a picture, but.... Anyway, here's a link to the screenshot- https://www.dropbox.com/s/qasp9r7s6n8n7ba/Home%20v.%20Dropbox.png (Dropbox is cutting off the bottom for me, so you may opt to download the image and view it locally)


Solution

  • As smarx said, affixing either ?raw=1 or ?dl=1 to the end of a Dropbox link will make the link download directly, no "lobby" page with a download button on Dropbox's website.

    This enables one's CSS file to fetch font files and such from Dropbox via @import for example.

    In brief testing, it appeared that neither query parameter (?raw=1 or ?dl=1) offered superior performance to the other, and in fact each Dropbox-hosted file takes two requests to load on a website. As a result, it actually appears that it is more efficient (read: faster) to keep the .woff files in my case on the home server rather than Dropbox's "superfast" download servers.