And now, the warnings have graduated to appear in Page Speed Insights.
It stands to reason that projects, especially those created using a sophisticated framework, would only ever make use of a tiny percent of the code available to it, largely through numerous library dependencies. That’s why there’s an optimization process known as “tree shaking” for bundling only what’s actively being used by a given project as much as possible. Tree shaking doesn’t always work well with older libraries due to the moving goalposts of keeping up with modern syntax and coding patterns.
Frameworks make life easier for developers by removing the complexity of making your library choices, configuring bundlers, and writing scripts to automate optimization processes for production. With a “quick start” recipe found in most documentation, developers can get up and running prewritten command line interpreter scripts that come as part of most packaged frameworks. An example of this is the Create React App which scaffolds up blank React application code ready for you to develop further into a web application.
$ npx create-react-app my-app
When you choose to use a framework you accept, perhaps without knowing all the details, the difficult decisions of architecture, configuration, and library dependencies of that framework. Here is the guide for optimizing React for production from the makers of the popular frontend library currently used by many projects and frameworks such as NextJS.
A notable library, MomentJS (with 12 million downloads per week as of September 2020), is the first one Lighthouse points out as having a few better options. Google’s logic here is irrefutable and rather well known. In response, Moment’s own homepage and documentation now mirrors the advice provided in Lighthouse’s reporting. Moment is feature frozen, with only stability updates planned.
Other libraries that Google has under the microscope are Lodash and possibly Underscore. There have been legitimate negative feelings expressed about this throughout the developer community, with more than one developer calling it “toxic” or “harmful” to the open-source community. The complaints have to do with Google “shaming” libraries without giving enough context and promoting alternatives that can harm the discovery of smaller and lesser-known library alternatives.
While all that is true, it’s also true that you have to break eggs in order to make an omelet. Progress often will hurt some folks. Google relies on a third-party reference (BundlePhobia) for collecting alternate library lists. They further vet choices based on a “high bar for equivalency” and “ease of migration” as determined by the Lighthouse team.
Lesser-known library authors can get in the mix by submitting their library to the service. Additionally, a developer commented that since Google is now officially recommending libraries, they should help finance open-source by donating to the project and a team member on Twitter has agreed to begin doing this starting in 2021.
This is a really great idea. Fully agree these teams need support. Chrome currently has a yearly web performance and frameworks fund for sponsoring work like this. We’ve been working with OpenCollective to expand on this for 2021 and will have more funding to announce soon.
What this means for TechSEOs
It’s true that TechSEO practitioners do not have to be developers in order to be excellent at their job. It’s also true that the more familiar you are with the struggle developers undergo, perhaps by learning a little about coding and at least understanding the details of Google’s Lighthouse as much as possible, the better you will be able to communicate problems and practical solutions to developers.
It has to do with how much that library has been integrated into the codebase. Code patterns may have to be completely rewritten throughout an application. The bigger and more interconnected the application codebase is, the harder it will be to accomplish the replacement. It isn’t always as simple as saying “Just use one of the alternate libraries that Google is telling you to use instead.”
One of the daunting thoughts that can occur when learning one has to replace Moment comes from the fact that Objects in the library are written to be mutable (changeable). Keeping this pattern is seen as necessary for backward compatibility and this really complicates replacing Moment with another library. Whole blocks of code may need to be written in order for your application to accommodate the fact that variable values assigned using Moment somewhere in a call chain can’t be counted on as immutable values inside your application codebase.
A modern pattern which relies on immutable Objects from a newer library is more stable. To get there can require a lot of rewriting every instance where Moment gets used.
SEO for Developers
If you made it this far and wish to know more about coding in order to provide a better service to your clients, then you’re in luck. This year, we’re going to be producing the SEO for Developers Workshop as an optional add-on to the SMX conference series. The information presented will be targeted at guiding your journey from wherever you are as a TechSEO practitioner, to wherever our collective paths lead us into coding. Given how fast things are progressing the sky’s the limit!
- ^ Google Lighthouse (developers.google.com)
- ^ @ChromeDevTools (twitter.com)
- ^ pic.twitter.com/VFe8TFV9Y5 (t.co)
- ^ September 12, 2020 (twitter.com)
- ^ Create React App (reactjs.org)
- ^ optimizing React for production (reactjs.org)
- ^ MomentJS (momentjs.com)
- ^ feature frozen (momentjs.com)
- ^ Lodash (lodash.com)
- ^ Underscore (underscorejs.org)
- ^ BundlePhobia (bundlephobia.com)
- ^ September 12, 2020 (twitter.com)
- ^ SMX conference series (marketinglandevents.com)
- ^ SEO for Developers series on Search Engine Land (searchengineland.com)
Powered by WPeMatico