So far this is working quite well for me. I’ve used SASS to have some mixins and get my life easier

@mixin grid { display: -ms-grid; display: grid; } @mixin grid-template-columns($value) { -ms-grid-columns: $value; grid-template-columns: $value; } @mixin grid-template-rows($value) { -ms-grid-rows: $value; grid-template-rows: $value; } @mixin grid-column($value, $span: null) { -ms-grid-column: $value; @if ($span) { -ms-grid-column-span: $span; grid-column: #{$value} / span #{$span}; } @else { grid-column: $value; } } @mixin grid-row($value, $span: null) { -ms-grid-row: $value; @if ($span) { -ms-grid-row-span: $span; grid-row: #{$value} / span #{$span}; } @else { grid-row: $value; }

} /**** in the elements ****/ .container {

@include grid-template-columns(1fr 1fr 1fr);

}

I’m currently using it in my wife’s blog, if you want to check this in your device, here is the link: https://mariaquerviajar.com (Portuguese content).

Removing Javascript responsible for the layout is not only good because we’re reducing the codebase, but also because we’re executing less Javascript. Masonry and Equalizer have listeners on the window resize event. Other libs are even worse and have listeners on the window scroll. By removing such code we’re also making the interaction and flow more fluid.

Progressive Web Apps

Progressive Web Apps is a term used to define applications served through the web that leverage technologies brought by new browsers without loosing support for the old ones.

It’s progressive because you can progressively add new features without breaking the experience on browsers that don’t support it. It’s web because it’s served through the internet via a link, like any website. It’s app because it behaves like an app on browsers and operating systems that support it.

If you have watched more than 2 talks about PWAs you probably have seen the definition “the best of the web combined with the best of apps”, but indeed it’s a very good definition. To start with PWA the first thing you’ll need is HTTPS. This is a blocker and should be prioritized even if you’re not planning on transform you website into a PWA.

Enabling HTTPS brings several benefits beyond security, such as PWA (of course) and new browser APIs. It’s nice that those browser APIs (mentioning a few later on) are only allowed under HTTPS, because they are powerful and need to work in a more secure environment.

PWA is a set of technologies, you can choose what to implement and when. There are some talks that share some strategies like From Website to Progressive Web App (GDD Europe ’17) or Fast By Default: Modern Loading Best Practices (Chrome Dev Summit 2017).

If you want to learn more about PWA, there’s a free introduction course on Udacity but the feature I want to mention in this post is Service Worker. Service Worker is basically a programmable network API that gives you power to control the requests on your app. It runs on background and is the bridge between the browser and the network.

With Service Worker you not only have a much better cache strategy, but also a much more reliable experience, that improves both the perceived performance and the actual performance.

The time has come to put FIRE on your old code

Having so many new things makes us feel like we need to put FIRE on our codebase and start everything from the scratch, doesn’t it? Well, there’s no need for that, we can progressively enhance our app like everything on the web. But the intention on using the word FIRE (and in upper case) is that PWAs use this other acronym to dictate how the experience should be:

Fast: Here comes all the performance techniques to mitigate the friction between network and your app

Integrated: By adding a Web App Manifest you can have your web app behaving like an installed app.

Reliable: By exploring all the power of Service Worker, managing cache, slow connections and network errors.

Engaging: By having push notifications you can lead the user back to your app.

HTTPS

By enabling HTTPS you’re not only providing a more secure experience, but you can also enable several APIs that are in the browser, starting by PWA, and to name a few others:

Conclusion

I hope that this post has extended your vision on web performance beyond the well known barrier app vs network, and that this help you to rethink or improve your app architecture. Here’s this post checklist:

Do all the homework to improve your Front-end performance;

Clear the Critical Path;

Write Less Javascript: By removing dead code, replacing libraries with native JS functionality, splitting your app.min.js and delivering only what that specific page needs;

Write less CSS: by refactoring old code with new CSS features and replacing frameworks by native CSS;

Use Service Workers: to manage your cache better, to have a fallback when network is off or bad. Leverage PWA to improve your user experience;

Split your codebase. It’s easier to read, to reason about, to maintain, and less likely to introduce bugs.

It’s a daily progress. You could do like I said earlier and put fire on everything and start over, but it’s more likely to have an upgrade strategy in your team and technical improvements daily efforts.

It’s also good to have everyone in your team aligned with best practices and new technologies so they can implement them in a daily work, while developing any feature or solving any bug in your application.

Improving performance is a Journey. Lots of small changes can lead to Big gains. Addy Osmani.

References and useful links

For Fun