Help with CSS and slow site

18 hours ago, Caroline2022 said:

After a redesign last year, the site speed ratings crashed. My question is twofold:

1) How easy is it to just revert to the original site if AJAX screws up the CSS and breaks the site?

2) If we shared the speed test results, would someone be able to tell us what is CSS vs standard squarespace code that's causing the issues?

1. Ajax Page Loading can be enabled and disabled using the toggle in Site Styles. The change is immediate. There are no long term effects. Note that CSS added to the Custom CSS panel is not affected by the Ajax Page Loading setting. It will only affect code that has been added through the Code Injection panel.

2. I do not see any specific issues for this site. It compares well with other Squarespace sites using this template. A blog post page loaded in 2s. Also it's worth noting that your performance results for the sidebar page are only correct if a visitor opened this page directly; they are not representative of someone opening the sidebar as a page component on another page. In those circumstances, Squarespace serves the visitor a much smaller image and this has a much smaller file size.

15 hours ago, jpeter said:

A quick win would be to compress your images using a free service like https://tinyjpg.com and re-upload them on the site. I ran your hero background image on the home page through TinyJPG and it went from 568kb to 270kb, so a 52% savings

Note that when you upload an image to Squarespace, the platform does some resizing which necessitates re-encoding and re-compressing. If you compress an image before uploading it, the mandatory re-compressing will usually result in a larger file size because the algorithm won't know the difference between "actual image content" and "artifacts of the previous compression run".

Was this post helpful? Please give feedback by clicking an icon below  ⬇️

@Caroline2022 

• Running a Google Lighthouse test on your site, looks like your images are the largest assets being loaded, followed by some JS files. A quick win would be to compress your images using a free service like https://tinyjpg.com/ and re-upload them on the site. I ran your hero background image on the home page through TinyJPG and it went from 568kb to 270kb, so a 52% savings. See attached screenshot.
• Squarespace uses Typekit and Google fonts for its font library and I'm not aware of a way of disabling them. If there was a way to disable certain fonts that aren't being used, then that would help in the performance area. People might have better results on non-squarespace sites because they may be able to control the amount of custom fonts loaded on a page. Doesn't look like that's the case with Squarespace. Your site appears to be loading 20 custom fonts. It may be the same font, but different weights.

@jpeter Thanks so much. Curious what you think about this...

In order to have a sidebar on my blog posts, the designer created a separate "sidebar" web page, then created code to pull that in for each post. This means that this "sidebar" page https://carolineadamscoaching.com/sidebar is being pulled by CSS onto 80+ blog posts.

It doesn't show up on the speed reports when you run at the domain level, but when you run the tests on the actual pages, it's abysmal (see below). 

Do you still think it's best to start with the images on main pages? Only 14 are over 150KB.  And the largest is 611. The majority of these 14 are "elements" used in the theme/backgrounds. We've reduced so many already, and it really hasn't increased performance at all.

I guess I wonder how Google prioritizes: is it better to speed up the main pages or focus first on the sidebar that probably slows down every single blog post?

Thanks so much for your insight!

On 6/8/2022 at 10:43 AM, paul2009 said:

1. Ajax Page Loading can be enabled and disabled using the toggle in Site Styles. The change is immediate. There are no long term effects. Note that CSS added to the Custom CSS panel is not affected by the Ajax Page Loading setting. It will only affect code that has been added through the Code Injection panel.

2. I do not see any specific issues for this site. It compares well with other Squarespace sites using this template. A blog post page loaded in 2s. Also it's worth noting that your performance results for the sidebar page are only correct if a visitor opened this page directly; they are not representative of someone opening the sidebar as a page component on another page. In those circumstances, Squarespace serves the visitor a much smaller image and this has a much smaller file size.

Note that when you upload an image to Squarespace, the platform does some resizing which necessitates re-encoding and re-compressing. If you compress an image before uploading it, the mandatory re-compressing will usually result in a larger file size because the algorithm won't know the difference between "actual image content" and "artifacts of the previous compression run".

 

Was this post helpful? Please give feedback by clicking an icon below  ⬇️

@paul2009This is SOOO helpful, and explains a lot about what we were seeing despite reuploading smaller, resized images. Follow-up question re the sidebar: is this design the best practice or best way to do this? My SEO person is concerned that it's pulled into every single blog post (~80+ posts).

20 minutes ago, Caroline2022 said:

Follow-up question re the sidebar: is this design the best practice or best way to do this?

There's nothing technically wrong with pulling in content from other pages. That's how Summary Blocks work. However I would suggest changing the code so that the sidebar content isn't loaded when the user is on a mobile, as it will impact performance for them (on slower networks) and Google don't like slow mobile sites.

On 6/8/2022 at 5:43 PM, paul2009 said:

Note that when you upload an image to Squarespace, the platform does some resizing which necessitates re-encoding and re-compressing. If you compress an image before uploading it, the mandatory re-compressing will usually result in a larger file size because the algorithm won't know the difference between "actual image content" and "artifacts of the previous compression run".

Hi @paul2009 so you don't recommend to use https://tinypng.com/ or something like that? 😯

4 hours ago, florencepicol said:

so you don't recommend to use https://tinypng.com or something like that?

The way the system works right now, it isn't always helpful. In a test, a high-quality 1.2MB image was compressed using TinyPNG and it became 642KB. However, when Squarespace processed it, the file become 953KB - around 50% larger.

Squarespace recommend that you save the images at a high "quality" setting (95+ in most image tools) so that when it gets resized and re-encoded it's not contending with significant previous compression artifacts.