Hey @bmds and @GeeJay,
Apologies for the delayed response. If you celebrated Thanksgiving, I hope you had a nice holiday!
I appreciate you clarifying which tools you use. This information and the concerns you expressed above empower us to make better, more educated decisions going forward.
That said, we won't be implementing all of the changes you request in the immediate future. While we always seek to improve our hosting performance, we also have to weigh adjustments against potential impacts on app performance and the HubSpot user experience — factors those tools don't consider.
Below, I outline various teammates' responses to your main queries:
Why are many scripts hosted on different domains?
We use different domains mainly because in the past when one domain was blocked by a popular ad blocker, it affected all tools. Using different domains reduces the risk of multiple apps being blocked at the same time.
That said, as Jeff Boulter mentioned, we now proxy many scripts through the customer's CMS domain. Assets that have this enabled will appear to come through the same domain. "We do need to move more scripts [onto this model] still, but it's a start."
js.hs-scripts.com/[hub-id].js have a
The script loader's short cache life ensures that if a user adds or removes a tool such as live chat or pop-up forms, the change will propagate immediately.
ETag headers make a lot of sense if the content is large, HubSpot's script loader comes in around 1.1 KB compressed. Adding
If-Modified-Since headers to this asset would prevent this small file from being re-downloaded, but it wouldn't prevent the HTTP request to the server. "Since the bulk of the cost here is the latency of that HTTP request, we didn't think it was worthwhile to apply any other caching tricks."
max-age of the script loader has been raised from
15 seconds in the past because it didn't seem to cause problems for users. We're receptive to experimenting with it again, but it's not high on our priority list at this time.
js.hs-analytics.net/analytics/[epoch_timestamp_in_milliseconds].[hub-id].js have a
300 second (5 minute)
Similar to the script loader, "we chose
5 minutes because it was a reasonable balance between having good cache hit rates and refreshing frequently enough to take into account settings updates. The tracking code is also reasonably small (~25 KB compressed), so we weren't worried about the added latency of re-fetching it."
v2.js, and the other forms scripts have
600 second (10 minute)
"The 10-minute values are a good compromise between cache and speed of deployed updates. If we were to increase that to say, 1 day, a deploy with a bug would take a very long time to be reverted."
js.hsadspixel.net/fb.js have a
600 second (10 minute)
"The reason is similar to the forms-related scripts. We try to keep our backend functionality similar to the functionality of other tools, when possible."
Why do all CDN assets (
main.js, and all image files) have a
1209600 second (14 day)
See Jeff Boulter's post above.
Why aren’t CTA JS files loaded asynchronously?
"We have discussed updating all of our embed codes (forms and CTAs) to be able to load asynchronously recently. The reason we do not do this at the moment is because we can't:
The CTA embed code loads
current.js and then loads the creation script, if
current.js is not loaded when the creation script has fired, we'll get errors for undefined functions.
We have to make some considerable changes to how this loads to allow asynchronous loads, and updating the embed code can always be tricky. However this is something we're currently [discussing]. For the moment, it's roughly roadmapped for [sometime in 2019] as we have some structural changes to the team we're working on first, but this is something we do plan on addressing within the not-to-distant future."
Why don’t CTA image files have any
The GIF files are for tracking, so caching those would affect CTA analytics.
Similar to script loader explanation above, we've opted to prevent the CTA PNG previews from caching to minimize the time it takes for user updates to propagate (despite the slight performance cost).
"We are also investigating changing the way we render CTAs so this may become a non-issue in the future."
All file manager assets have
ETag headers and
max-age values, so what different role do the timestamp parameters play in cache-busting?
"We actually are just finishing up a project to better handle purging our server cache of old files (e.g. when you replace them), so the timestamp parameter is no longer going to be needed to ensure the most up-to-date version of a file gets served."
@GeeJay, I've had account 2499930 ungated for this beta feature! @bmds, if you'd like me to do the same for you, just share your Hub ID below.