Squarespace Problem Loading Its Own Assets

Several months ago, we decided to move Meeting In The Media from WordPress to Squarespace - and we made the switch! Our new look and branding is just what we'd pictured, and this easy-to-use platform makes creating content fun again.

MeetingInTheMedia_Banner_SQ_ProblemLoadingOwnAssets.png

However, two weeks into the move, we noticed that our Firefox browser would freeze when trying to load the blog. We started to see a small pop-up window labeled 'Unresponsive Script Warning,' which noted some information about 'debugging' the problem, along with an option to 'continue.' We would click 'continue' and the page would load, but this warning message would appear each time we returned to the blog page - this meant any time we were working on draft posts, editing posts, and visiting the live site.

We tried to solve the problem ourselves, first removing custom CSS, then removing custom Header and Footer code injection. We removed our Pinterest and Twitter sidebar apps, tested the site on a Mac and PC, across Firefox, Safari, Google Chrome and Opera - but, still, the problem persisted.

We wrote to Squarespace support staff and, with the in-depth information we provided in our initial message, our problem was immediately elevated to a supervisor.

We were told that Squarespace has trouble loading too much information on one page, such as too many images or multiple blog posts. This means that Squarespace has a problem loading its own assets - image blocks and blog posts, site creation tools or 'assets' created and hosted by Squarespace.com for its essential function as a website builder. It was suggested that we limit the number of blog posts that appear per page, thereby limiting the amount of images per page - and the problem would disappear.

So, we changed the number of blog posts per page, from 10 posts - to 3. The 'Unresponsive Script Warning' disappeared, and all was well - for one month.

In that time, we had decided to create an archive of our blog posts. Using several summary blocks, we created the 'Grid View' page that displays an image with text for each of our blog posts throughout the year. As the summer continued, we added more blog posts, and more summary blocks to our archive 'grid view' page. In late July, we noticed the 'Unresponsive Script Warning' started to appear again - but this time on our 'Grid View' page.

We wrote another ticket to Squarespace support staff, and gave all the relevant information, constantly referencing our previous ticket number and support staff member who had last helped us with this issue. Our ticket remained in the hands of three different, lower-level support staff members who all copied and pasted the same information about 'Footer Code Injections' into response emails. Finally, after re-stating that this problem is not related to code injection, our ticket was escalated to a Squarespace supervisory staff member.

After thoroughly explaining the problem one more time, it was confirmed that Squarespace has a problem loading its own assets. When an internet browser takes too long to load a webpage's content, the browser will pause and tell you that the scripts on the page are 'unresponsive'. The website will either cut-out altogether, such as with Google Chrome, or will give you the option to 'continue' to the page when it finally loads. Note that Squarespace has trouble loading its own assets, and therefore takes too long to load, freezing your browser. The Squarespace supervisor wrote:

"I've been testing this and I can definitely replicate it periodically in Firefox. Normally this message [appears] when the script takes longer than expected to complete loading the content. Most browsers have a threshold for when to throw a warning message if a script takes a long time to complete, and it seems that the threshold for Firefox et al is right around the time it takes for this script to finish, which is why sometimes it finishes in time and sometimes it takes just a little too long, so the warning appears intermittently."

We were also told that increasing the time limit threshold set for Firefox to load a page will help the website load without the 'Unresponsive Script' warning - but this only affects our individual browser, and not that of our users.


We responded by asking if the third-party Pinterest or Twitter applications on our 'Grid View' page sidebar could be to blame for a slow-loading script. The staff member replied:

"After extensive testing I've determined what is triggering this issue. Essentially, there is a point at which the number of Summary Blocks combined with the number of items to display will cause the script to run longer than expected, and in some cases overload the browser. In my personal testing, I couldn't get Safari to throw any errors, but I did see the warning message consistently in Firefox, and Chrome crashed once. Note that we do not officially support Opera so I did not use it to test.

Regarding Pinterest, I also noticed that sometimes the warning message appears/the script stops when connecting to a third party (sometimes Pinterest, sometimes TypeKit sometimes Google Fonts) but when I debugged the script, it didn't seem like these connections were causing the problem, it was just that that it is what was happening while the script was paused (also, the script paused on different line each time, so it wasn't likely to be an issue with the code itself.)

I've forwarded this information to our development team so they are aware...so that you can deal with this right away, I've tested and confirmed a couple of different options you can implement to prevent it for now."

He gave several options for slow script workarounds with Squarespace for our grid view archive page:

Option 1: Remove some of the existing Summary Blocks on the page. When I removed the block for January, I could no longer see the script warning in Firefox either logged in or logged out...

Option 2: Reduce the number of Summary Blocks by increasing the number of tags that each block displays. For example, I used only 3 Summary Blocks instead of 8; the first shows August - June, the second May - March and the third February and January.

Option 3: Use the same number of Summary Blocks, but decrease the number of items displayed in each. On this test page I set each Summary Block to display only 3 items. If you use this option, you'd probably want to add a "view more" link or button by each Summary Block pointing to a dedicated page for that month with another Summary Block on it that displays the rest of the entries for that month.

We went with 'Option #2', as the goal of our 'Grid view' page is to act as an archive, which means we want a complete list of our posts to be available. We recently created an 'archive' page separate from the 'Grid View' page, and minimized the amount of summary blocks on the main page.


Options #1 and #3 defeat the purpose of having an archive altogether, and we didn't want to go with the page-within-a-page scenario, either - the less clicks, the better. Learn how you can create a summary block archive, using multiple #tags per summary block!

"The performance and limitations of the browser are going to vary from user to user based on their settings, system specifications, other programs that are running, how many tabs are open, etc. so it's not always possible to say definitively that what works for you will work for someone else. However, it looks like your homepage is currently right about the limit where the issues start happening (I say this because it's intermittent, and seems to work better for us than for you) so reducing the content on the page even slightly should allow it to work smoothly for most users."

On August 31st, 2015 we received another follow-up email from the support staff member:

I heard back from our design and development team, and they've let me know that this is related to the way that the scripts that load images on our pages load. At this point, they don't think that they'll be able to prevent it, although we will continue to track instances where it occurs so they may look into it more in future. For now, they've suggested that the best course is to limit the total number of images and blocks on the page so that they script to load the images will not need to run as long in order to prevent these errors."

While you can change your Firefox browser settings so your personal browser doesn't see the 'Unresponsive Script Warning,' this problem lies with Squarespace.

Plainly, Squarespace websites have a problem loading their own assets. If there are "too many" summary blocks, images or blog posts per page, website creation blocks and assets created by Squarespace as a website builder, then Squarespace has a problem.


We responded by asking when this might be fixed - or at the least, further investigated:

"Thanks for the follow-up. As the purpose of Squarespace is a website builder, I have content I would like to share and wanted to use your website to do so. It seems that Squarespace has trouble loading its own assets, which should not be an issue for a website builder - as that's its primary function.

Will the staff be looking into this before the end of 2015, or does 'may look into it more in future' mean that maybe they will look into it, maybe they won't, and who knows when?"

We received a response from a different staff member:

"Thanks for reaching out.
I really apologize for the inconvenience.
I definitely understand where you are coming from here and how frustrating this can be for you, but at this point we donʻt have a timeframe for this.

Our engineers will be looking into this, but it's hard to say how long these cases can take.

Please let me know if there is anything else we can do for you in the meantime."

As of September 20th, 2015, this problem remains at large, and it's anybody's guess as to when it will be fixed, if at all. We will update this information if further updates are made.


However, we will say that Squarespace has responsive customer service, and they will always try to solve your problems. Having created over 10 other websites hosted on Squarespace without error, we would still recommend their services. This seems like a strange, rare error, but we wanted to make note of this for others who may experience this.


www.MeetingInTheMedia.com