Hi everyone,
Quick question. I know it’s kind of been asked and answered before but 
I’m still new to BSS and have played around with quite a bit of custom code, coz I’ve used the JS libraries like GSAP.
I’m assuming that any code I write is shipped along with the default BS code. Does this make a site really large and slow?
I think I read here that we can’t get rid of BS default code, because it’s linked to the CDN
Is there no way around it, you have to ship a site with redundant/unused code?
You don’t have to use a CDN for the Bootstrap files. There are option for this in File > Settings > Export. Further, you can create your own optimized versions of Bootstrap’s CSS and JS by following their guidelines here…
In my experience, on 4G/broadband connections, the difference in load time between sites that use the standard Bootstrap files vs optimized files is negligible. I have no problem getting Lighthouse speed scores of 95 or better using the standard bootstrap CSS/JS downloaded from my server.
Of course any custom code you add is going to add to the time it takes to download the site, but the code would have to be pretty large to create a noticeable slowdown. You can use Chrome dev tools to view the actual time it takes for the page assets to download from the server, and see which things are causing the greatest slowdowns. In my experience, the HTML/CSS/JS is rarely the cause of large slowdowns. Usually, images are the big offenders. I constantly see people use images with massive native resolutions that are 5 times larger than what’s being displayed on the site.
In general, I’ve found that websites built with Bootstrap Studio are typically quite fast compared to websites built with say, Wordpress or Wix, which are often horrendously slow.
1 Like
Much appreciated That’s a good point about images. I think I’ve been guilty of that; not really optimizing my images for the web. It’s the web and not print LOL
I feel some developers get unnecessarily concerned with optimizing their sites for speed. Yes, Google does like quick loading websites, and they do give some preference in the SERPs to the quicker of two sites, but you should also take into account a website’s target audience and their location (will the website even be visited by people who don’t have broadband connections?) Devs should weigh the costs in development time vs the benefits to be gained from going to excruciating lengths to squeeze the last bit of speed out of a site.
Also, what matters greatly today may be irrelevant in a few years. Actually, it probably will be.
For example, say you’re building a website for a photographer. They may want to deliver a very high resolution image for the minority of people who have 4k desktop monitors, but you certainly don’t want to waste a visitors mobile phone data, or make them wait seconds, to download a 4000 pixel wide image for a 400 pixel wide screen. So you deliver multiple images for different screens.
That’s today.
5G service is growing quickly, and unlimited mobile data plans are common. By 2030, 5G will be ubiquitous and 6G will be rolling out. It’s likely that unlimited data will be the norm. Remember how ten years ago you used to have to pay extra when you used up all your available minutes for talking, or your allotment of text messages. Now, unlimited talk and text is the norm.
At this time, there’s still a noticeable savings in time and speed to be had by creating and loading different resolution images for different devices/screen sizes. But by the end of the decade, it probably won’t matter because they’ll be no perceptible difference between the time it takes to download a 4000 pixel image and a 400 pixel image.
It kind of reminds me of the ruckus 5 or 6 years ago when Google released its AMP (Accelerated Mobile Pages) project and developers were all arguing about how it was going to be crucial to use AMP if you wanted your site to rank well on mobile search. But not long after AMP was released, there were considerable improvements in mobile optimization such that now you can achieve practically the same speed with a non-AMP site as one that uses AMP, without sacrificing features.
4 Likes