A Look Behind the Scenes at Code.gov
One of our priorities here at Code.gov in our commitment to you is in improving website performance. There’s a lot we’ve done to improve performance this year, and we are presently considering what needs to be done in the future. We invite you to take a look at what’s under the hood here at Code.gov, and get a sneak peek at what we are planning for tomorrow’s version of our site.
What We’ve Done
Our strategy over the course of this year has been to take pragmatic steps across the full stack to decrease the load time and memory consumption of Code.gov. Here’s some specifics:
1) Integrated API. The change that we’ve made that has had the greatest success decreasing our load time has been to create and integrate a backend API. This decreased our load time by 61.48% on a Slow 3G Connection and 25.46% on a Fast 3G Connection. Before that upgrade, users would have to load all the indexed repositories as a part of loading our site. After the upgrade, users don’t have to load all the data when they search for something. For example, if someone searches for water, they only load the repositories related to water.
2) Created Custom Font Files. We also stitched together code-gov-font, our own font using an open-source CLI. Our goal is that users should only load the icons that are actually used on the site. The work is not complete here though. We still import some icon libraries, so we invite help in cutting out only the parts of the code we need and packaging that up with code-gov-font.
3) Modularizing Style Sheets. We extracted most of our SCSS files and put them in a separate Style Guide repo called code-gov-style. There are several advantages to separating the styling from the frontend framework. Firstly, we identified common repetitive styling among components and consolidated this, following the “Don’t Repeat Yourself” principle. This made it so users won’t load the same styling rules multiple times. Secondly, organizing this code in a separate repo allows us to test and develop individual CSS components without having to test the application as a whole. This has greatly sped up development and freed up more time to focus on performance. Thirdly, separating the styling into its own package has given us greater framework independence. Our styling is no longer baked into our framework, which means greater flexibility and less cost when re-architecting.
4) Favor CSS over JavaScript. When deciding how a new widget will be displayed, the first thing that we do is try to implement the styling in CSS. For example, we created a popover that uses CSS rules for detecting when a user hovers over it and displaying the popover. You can view that here: https://github.com/GSA/code-gov-style/blob/master/_sass/_popover.scss.
5) Favor Custom Utility Functions. We often recreate small simple utility functions, rather than adding large utility libraries as dependencies. Although this takes more developer time, it means that users load less JavaScript when visiting Code.gov. We’ve used a package to identify what libraries are taking up a lot of space in our bundle and prioritize this work. For example, we needed just a couple lines of code to recreate a function that gets the unique values from an array: https://github.com/GSA/code-gov-web/blob/master/src/app/utils/uniq.ts As packages make it easier to import just the parts that we need, we’d welcome help finding ways to import functionality without increasing our bundle size by too much.
Where We Go From Here
Now that you know what we have been working on, here are some things that we are considering for the future. We continue to work on making Code.gov easier and more efficient in its performance.
1) Improve Packaging. We’re currently exploring how we can package our code better for production. We currently do not use Ahead of Time Compilation and Code Splitting, two procedures that could greatly improve the user experience. (Pull requests welcome!)
2) Continue Trimming. We will continue trimming down on the excess styling and font information that isn’t being used by our site. Most of that work will be done in https://github.com/GSA/code-gov-style.
3) Exploring New Technologies. Because we’ve avoided a monolithic approach, separating our back-end and front-end, as well as the styling from the framework logic, we’re flexible. We are not bound to specific technologies and can consider alternative and more performant ways of doing things. In other words, we can upgrade one piece of the application at a time.
4) Increase API Usage. Currently, we do some data filtering on the front-end. We are looking at adding more filtering capabilities to the backend, so filtering of search results doesn’t happen on the user’s device. (Did we mention that pull requests are welcome?)
5) Engaging the Community. We don’t just stay in Washington. We also come to you. We have participated all across the country in meetups, conferences, and hackathons, and we’re just getting started. We have many more events along the East Coast lined up through the end of the year and are looking ahead to 2019 to visit both coasts again. We have many more events lined up this year. If you’d like us to participate in an event, let us know by reaching out to us on Twitter or LinkedIn and we’ll try our best to attend.
An Invitation to Contribute
We welcome participation and contribution. As Code.gov is your code, we welcome your advice, contributions to this discussion, and especially your pull requests. If you see any problems with what we do, then take action by opening up a GitHub Issue at https://github.com/GSA/code-gov; or better yet, submit a pull request! This is your opportunity to make an impression and, in taking action, make a difference. We look forward to working with you.
Thank you and #CodeOn
