Jump to content

Rethinking Kilobytes

| GreenSock

Rethinking Kilobytes

Conventional wisdom says that kilobytes have a direct impact on load times and consequently user experience. Too many developers, however, myopically focus on a simplistic (and rather dated) "aggregate total file size" mentality and completely miss the broader goal of improving user experience. This article aims to challenge the old paradigm and explain why "spending" kilobytes on a library like GSAP can be a very smart move.

Kilobyte cost factors

When you're assessing kilobyte cost in a modern, nuanced way consider these factors:

  1. Performance yield

    Would you spend an extra 200ms of load time to get super-smooth animations at runtime?  Are users more sensitive to janky animations the whole time they're interacting with your site...or a fraction of a second on initial load? Of course there are reasonable limits either way (waiting an extra 30 seconds for a huge file to load would be intolerable even if it made things run buttery smooth), but in most cases we're only talking about fractions of a second difference. GSAP contains "extra" code that automatically GPU-accelerates transforms, applies lag smoothing, avoids layout thrashing, caches important values for super-fast lookups, etc. - would removing those features for the sake of a few milliseconds on initial load (and zero savings once it's cached) be a step forward or backward?

  2. Caching

    When does a 23kb file act like a 0kb file? When it's cached! This is particularly relevant for engaging, animated sites because there are common tasks and code that can be encapsulated and shared. GSAP is a perfect example of a shared resource. An end user only loads it once and then it's completely "free" thereafter...for all pages pointing at that file...on all sites*!

    Unique assets vs shared resources

    *Some browsers may implement domain-specific caching.

  3. CDN

    files loaded from a CDN (Content Delivery Network) are typically "faster" because they're geographically distributed and automatically loaded from the closest server. Plus CDNs have inherent redundancies leading to better reliability.

  4. Custom code reduction (kb savings)

    Loading a library like GSAP may allow you to only write 1kb of custom animation code instead of 5kb of CSS animation code, for example. Plus it has quite a few utility methods that you can tap into for added savings. This can significantly reduce the amount of custom code that must be loaded as your visitors go page-to-page

Non-kilobyte costs

If you avoid a tried-and-true library like GSAP, it may feel like you're reducing your costs but don't forget:

  • Development time

    You could use a minimalistic library or write your own, but how much more time will that take to implement? How much custom code will it require? How many workarounds will be required to get similar functionality? How many headaches will you run into with cross-browser quirks and inconsistencies that GSAP already solved? GSAP's API has been crafted over a decade to facilitate easy experimentation with minimal code. And when it comes to animation, experimentation is key. Most developers are working against deadlines and it's priceless to have a robust, vetted toolset to rely on.

  • Swagger & confidence

    Perhaps your project only has basic animation needs so you choose a basic animation library or write your own custom code for all the animations...but what happens when the client requests something more advanced? Uh oh. Will you port everything to GSAP then? What if you've got hundreds of animations that now need to be dynamically time-scaled or linked to scroll position with smooth scrubbing? How about advanced morphing, motion paths, and responsive animations? If you just use GSAP from the start, you have almost zero risk of running into an "oh no!" moment like that. You can code with confidence that you'll be able to animate pretty much anything with minimal code. What is that kind of developer swagger worth?

  • Documentation, support & training

    What if you run into trouble? Is excellent documentation available? Is there a community eager to help? Are there training resources for new hires down the road? What's the real long-term impact of your choice?

  • Maintenance

    The web is littered with abandoned open source projects. What's the track record of the one you're considering? How long has it been actively developed? Or if you're writing all your own animation code from scratch, is it truly maintainable? What's the long-term cost? Are you documenting how everything works? What happens when browsers introduce bugs or new features that impact animations?

Other factors to consider

  • Bandwidth is only increasing

    The impact of a 24kb library is decreasing all the time. It's less than a single image these days. On average, in fact, images account for over 864kb on every web page! And again, GSAP is a one-time load in most cases. It's often cached in which case it costs nothing.

  • GSAP doesn't count against file size budgets on every major ad network

    They have virtually all recognized GSAP as an industry standard and exempted it from file size calculations. That directly benefits you if your animations are GSAP-based. Google, Sizmek, Advertising.com, Flashtalking, AdWords, Flite, Cofactor, etc. - they're all on board with GSAP.


The old mindset focused on the aggregate total file size for each page making it's easy to miscalculate the cost of using a library like GSAP (or any other shared resource). Doing so also pushes developers toward minimalistic less-capable solutions that may end up being far more expensive long-term. We'd encourage a more wholistic, nuanced approach that looks at the overall costs and benefits. Remember the end goals - outstanding user experience, minimal development costs, and long-term viability.

  • Like 14

Get an all-access pass to premium plugins, offers, and more!

Join the Club

We love seeing what you build with GSAP. Don't forget to let us know when you launch something cool.

- Team GreenSock

User Feedback

Recommended Comments

Brilliant post! This should be laminated and brought to any meeting with player-hating back-end and perf 🐓 blockers. You're still one of my heroes for now the second decade 😍

When you say "They have virtually all recognized GSAP as an industry standard", could you possibly publish this proof to give those of us in OP's position another arrow in our quivers?


  • Like 1
Link to comment
Share on other sites

I second every thing you say and would love to point out some other points:

I started wed-dev in 1995 when we really had to count each byte by hand, and I stayed old-school in that regard since then.
Nevertheless I find it somewhat laughable when I hear people arguing about half a kilobyte when we talk JavaScript or CSS Files, while they deliver images upwards of 3MB.

Using image src-sets and carefully compressed images for several screen-sizes and resolutions will often gain you hundreds of kilobytes, going for webp if target permits it might add to this. Wise choices in pre- or lazy loading could use the thoughts wasted on the choice of minifier.

Minifying most of the time isn't worth it in my experience, as all servers send gziped anyhow - I even had situations where not minified files performed better, as gzip was struggling with minified ones. (exotic I admit)
Tree shaking is another thing that in most cases isn't necessary if you carefully consider what you really need upfront and if you refrain from using complex libraries for just one simple functionality. (Don't get me started on that one. Yet.)


Also oftentimes I find it preferable to load a little extra with the front-fage or any other landing page, (like style instructions for following pages inside one slightly larger CSS of an icon-font) as the user usually has to wait for that shiny impressiv frontpage anyhow.  As he has to load everything site related from scratch - a few milliseconds more or less don't make a difference. Once the user moves on our site, she gets a better and more snappy experience with all that is already cached. 


First and foremost the whole fetichism about every single kilobyte in tools like GSAP in my opinion stems from people loading half a million useless and sometimes conflicting libraries under the pretense of 'not reinventing the wheel' while they are actually to lazy (?) to write a little code on their own and learn the basic concepts.
To compensate for their overuse of tools the use more tools to tree shake minify and whatnot them. Ending up with complex websites, complex workflows, thus forever forced to care more for their tools instead of their product.
*old man stops ranting*

That said GSAP is probably the only library I'll use without a second though - it is worth every kilobyte in gold and double that.

  • Like 2
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now