Introduction As far as mobile devices became more usable then desktops web faced the problem with slow applications. A lot of us test applications in Chrome and then ship. Not many developers try to test their applications on real devices and real networks. So, I tried to follow these rules (partly) and test Open Sourced documentation for framework — Vue.js https://vuejs.org/ Test setup Nexus 5 device emulation Device: 1.6 Mbps throttling Network: network url: http**://**localhost:4000/v2/guide Tools: Chrome DevTools pwmetrics timeline-viewer Problem: pwmetrics results for vue.js docs — FCP 3,5 sec — 4,6 sec FMP — 6,1 sec PSI — 6,1 sec TTFP — 6,1 sec TTC Read more about these metrics in . Performance metrics. What’s this all about?article There also some inconsistent behavior of (flash of invisible content) and (flash of unstyled content). FOIC FOUC Different browsers behave differently FOIC — Chrome, Firefox, Safari FOUC — Edge, IE FOIC FOUC It will be nice to show fallback font as soon as possible and add to the site. progressive enhancement strategy Deferring scripts But, first of all, scripts which are blocking First Paint should be managed. Old but gold about defer and async scripts behavior article FYI: ECMAScript6 modules are deferred by default Timeline trace So, adding attribute to all these scripts (except vue.js, we will manage it later) brought us to this results: defer pwmetrics results after deferring scripts for vue.js docs for and metrics not so impressive but it’s something. 100ms TTCI TTFI Adding defer to can save much more time: vue.js — 3,5 sec -> 1,9 sec FCP — 4,6 sec -> 3,4 sec FMP — 6,1 sec -> 4,9 sec PSI — 6,1 sec -> 4,9 sec TTFI — 6,1 sec -> 4,9 sec TTCI pwmetrics results after deferring vue.js Adding defer requires to warp example codes into DOM_ContentLoaded_ listener, but I think it can be easily done in scope of ` ` fork. hexo-renderer-marked Managing fonts Timeline trace Taking a look at it can be noticed that fonts are blocking just like scripts do. timeline trace FMP Hence, some techniques can be applied to handle it. Moving fonts into the body Since browsers repaint after loading resources founded in body fonts can be moved there. has really cool article about this behavior — . Jake Archibald The future of loading CSS Results pwmetrics results for fonts resources in body for vue.js docs , under ` ` FMP FCP 2 sec , , under ` ` TTCI TTCI PSI 5 sec demo FOIC FOUC Statistic results are good but user experience is not nice. Thirdparty library There are several libraries which can help monitor loading fonts: fontfaceobserver webfontloader fontfaceonload I tried by . fontafaceobserver Bram Stein So, results are: Timeline trace pwmetrcis results using vue.js docs fontafaceobserver for , under `2 sec`, still the same FMP FCP , , under `5,2 sec` instead of `4,8 sec` TTCI TTFI PSI In case supporting all browsers, ~ looks like good trade off. 400ms But. font-display Supported in Chrome and about to be supported in Firefox For this case ` was used font-display: swap` vue.js docs pwmetrics results using font-display: swap for demo FOIC Comparing results: | | before | fonfaceobserver | font-display ||:----:|:--------------:|:---------------:|:------------------:|| FCP | 3,5 | 2 | 2,2 || FMP | 4,6 | 2 | 2,2 || PSI | 6,1 | 4,5 | 4,9 || TTFI | 6,1 | 5,3 | 4,8 || TTCI | 6,1 | 5,3 | 4,8 | There are also some trade-off for but better for interactive time. FCP, FMP (200ms) Either developing the new project or fixing an issue it is always a trade-off. We can’t have perfect scenarios all the time. Sometimes we should sacrifice. So how to manage this situation? Which choice will be better? I submitted to Vue.js org using because I thought they wanna support all browser, so case with won’t work. PR fontfaceobserver font-display Results: If you are working with evergreen browsers than don’t hesitate — use native supported features, use font-display . Thank you for the reading. P.S. I’ve written this article to show how in several steps you can improve speed for your application on mobile devices and slow networks really easy.