Jump to content

Invision Community Blog


Managing successful online communities

Matt
 

4.4: Turbo charging loading speeds

It might seem a little odd starting a blog on increasing Invision Community's speed with the word "lazy",  but I'll explain why this is a good word for performance shortly.

Earlier this year, Google announced that page speed is a ranking factor.

Simply put, if your site is slow, it will be ranked lower in Google's search results.

It is always a challenge making a large application like Invision Community as efficient as possible per page load. A single Invision Community page can pull in widgets from multiple applications as well as a lot of user-generated content with attachments, movies and images used heavily. 

This is where being lazy helps.

Lazy loading is a method by which attachments, embeds and images are not loaded by default. They are only loaded when the viewer scrolls down enough to make them visible.

This allows the page to load a good deal faster now it doesn't have to load megabytes of images before the page is shown as completely rendered.

I was going to take a fancy video showing it in action, but it's hard to capture as the system loads the media just before you get to it, so it looks fairly seamless, even with sluggish connections.

blank.thumb.jpg.47f7560ceb09fa6206f48eac81151829.jpg

Not the most dynamic image, but this shows the placeholder retains the size of the image

In addition to image attachments, we have also added this lazy loading to maps and Twitter emoji images.

Improving non-image attachments
Once we had implemented the lazy loading framework, an area we wanted to improve was non-image attachments.

We have listened to a lot of the feedback we had on this area, and have now made it very clear when you add an attachment into a post. We've even returned the download count now it's being loaded on demand.

lazy1.thumb.jpg.0a48f6a4a814a93228e3d6bcf20c8a05.jpg

Using attachments when posting

All the letters
When we first implemented the letter avatars in 4.3, we discussed whether to use CSS styling or use an image.

We decided to go with an image as it was more stable over lots of different devices, including email.

We've revisited this in 4.4, and switched the letter avatars to SVG, which are much faster to render now that the browser doesn't have to load the image files.

Other performance improvements
We've taken a pass at most areas with an eye for performance, here is a list of the most significant items we've improved.

  • Several converter background tasks have been improved, so they work on less data
  • Duplicate query for fetching clubs was removed in streams
  • Notifications / follower management has been improved
  • Member searches have been sped up (API, ACP live search, member list in ACP, mentions, etc.).
  • Stream performance has been improved
  • UTF8 conversions have been sped up
  • Elasticsearch has been sped up by using pre-compiled queries and parameterisation, as well as the removal of view filtering (and tracking)
  • HTTP/2 support with prefetch/preload has been added
  • Several PHP-level performance improvements have been made
  • Implemented rel=noopener when links open a new window (which improves browser memory management)
  • Several other performance improvements for conversions were implemented that drastically reduce conversion time
  • IP address lookups now fetch IP address details from us en-masse instead of one request per address
  • Cache/data store management has been streamlined and centralised for efficiency
  • Many background tasks and the profile sync functionality have all been improved for performance
  • Brotli compression is now supported automatically if the server supports it
  • Redis encryption can now be disabled if desired, which improves performance

Phew, as you can see, we've spent a while tinkering under the hood too.

We'd love to hear your thoughts. Let us know below!

This blog is part of our series introducing new features for Invision Community 4.4.


Comments



Recommended Comments

Does lazy loading work on all applications, especially pages like Gallery albums or Our Picks that are rich in content? 

Edited this post to include Our Picks, which I use as my homepage and I have a terrible score in Pagespeed insights.  Number one recommendation is to lazy load offscreen images! 

Edited by Joel R

Share this comment


Link to comment
Share on other sites
Quote

We've revisited this in 4.4, and switched the letter avatars to SVG, which are much faster to render now that the browser doesn't have to load the image files.

This must be done also for profile/clubs default covers:

On 6/12/2018 at 7:47 PM, Mr 13 said:

Exactly the same problem with profile backgrounds. They also can be recreated via CSS with a HUGE saving in size, bandwidth and loading time. For example, default background of user which posted above weights 735 KB. It's more than whole code and other resources of this page altogether. Too big waste of disc space and traffic.

Hope to see this in 4.4. Thanks.

Edited by Mr 13

Share this comment


Link to comment
Share on other sites
3 minutes ago, Mr 13 said:

This must be done also for profile/clubs default covers. Hope to see this in 4.4.

It's actually less necessary there because we end up with one single image file (which the browser will download once and cache) for all default cover photos, and then we overlay it with a randomized color - thus you don't have 100 image files downloading, just one (and only if it hasn't already been downloaded).

Share this comment


Link to comment
Share on other sites

I've been catching up on all the 4.4 updates and I'm intrigued by some of the new changes coming, however, I did have a question about 4.4 in general.  The first update stated it was set to release by the end of 2018, but I haven't seen mention of it in the others.  Is it still on track or will we see it pushed to 2019?

Edited by Alismora

Share this comment


Link to comment
Share on other sites

I profess this is a layman question, so bear with me. 

All of the pagespeed tools I’ve used 'Barneys Girlfriend' and complain about the load order of JavaScript on my page. Is that a legit issue, or just page speed tools being overly aggressive about things that could improve speed but hurt user experience?

Share this comment


Link to comment
Share on other sites

Lol “Barney’s Girlfriend”? Nice word replacement!

7 minutes ago, Joel R said:

Also, will IPS include a cleanup tool to delete and remake the existing Letter Profile avatars?

Plz plz plz

Share this comment


Link to comment
Share on other sites

@Mr 13 We've actually optimized all images in the suite too; the default coverphoto image is now ~280KB. Also, cover photos across the suite are indeed lazy loaded too.

@Joel R Yes there's a background task that will clean up the existing letter photos.

For developers, I wanted to add that our lazy loading utility is very flexible, so you can actually use it to lazy load whatever you want, and pretty finely control what happens (with preload, load and post-load callbacks). We hook into IntersectionObserver which is a new(ish) API in browsers that make it super efficient to check when an element comes into view. Of course, our regular content controllers already handle lazy loading images and videos in UGC for you, but if your apps have other areas where it'd be useful, you can do that quite easily 🙂 

Share this comment


Link to comment
Share on other sites

Very good news, my site is very heavy in image usage and page loading speed a big issue. 

The bad, it seems this deep code change will affect many plugins I guess and regarding my short experience with IPS updates, there will be some bug fixing necessary and a real stable package available after some point releases.

However, a great step forward. Thanks for your hard work girls and guys. 👍

Share this comment


Link to comment
Share on other sites

Do you think about improving the way the fonts are loaded? It's very unpleasant to watch empty rectangles until ...
Apparently you should also look for a variant of fonts awesome at your choice of administrator, or minified version of the fonts awesome.
This would reduce the size of the downloaded file and accelerate the uploading of fonts awesome.

It would also be a good solution when installing or upgrading, if an administrator chooses which flags to use and this to save a file as a custom_flags.css. This will greatly reduce size the downloaded flag.css file

Share this comment


Link to comment
Share on other sites
1 hour ago, princeton said:

@Matt It would be cool to see 4.4 on here now so we can see/test the improvements.

Curious, why does IPS have their javascript inserted in the <HEAD> when end of </BODY> is much faster?

 

 

This is a theme setting that you can toggle at will without having to make any changes (in the currently released version).

Share this comment


Link to comment
Share on other sites

This is great news! I was just looking for a way to speed up image loading and found this article.  I was also reading up on HTTP/2 so was happy to see this support added.

Not sure if I missed it but would love to see CSS and JS combined into one output file for each.

Maybe test the suite through web.dev to see what else can be optimized? Since google is the big one and released this tool https://web.dev/measure

Share this comment


Link to comment
Share on other sites
9 hours ago, AlexWebsites said:

Maybe test the suite through web.dev to see what else can be optimized? Since google is the big one and released this tool https://web.dev/measure

My site with minimal changes has a performance rating of 29 :dry: Invision was only 41 

Edited by marklcfc

Share this comment


Link to comment
Share on other sites
9 hours ago, AlexWebsites said:

Maybe test the suite through web.dev to see what else can be optimized? Since google is the big one and released this tool https://web.dev/measure

This online tool uses Lighthouse version 4.0 alpha 0, and a version that Lighthouse has already activated for Chrome browser is alpha 1.

There are more issues in the alpha's. It would be good to wait for release before serious tests.

Share this comment


Link to comment
Share on other sites

This is really good news, I'd been hoping to see a performance-based release for some time as traditionally IPS does rate low in Page SpeedGTMetrix/Yslow tests and we've been waiting for some of these overdue improvements for quite some time. So huge thanks! 

Lazyloading should really help with Gallery in particular, I currently get a poor Pagespeed score of F42 on one of my sites.

Please consider adding to your to do list (if not already added):

  • Serve scaled images (current GTMetrix reports a score of F0 with a 1.2MiB 80% possible saving is possible on my Gallery index page)
  • Where static content is uploaded to Amazon S3 and Cloudfront (it should be copied, not moved!), often there is missing header metadata such as cache-control, expires etc. Whilst investigating poor Cloudfront cache hit ratios of just 5%, I noticed this week an IPS uploaded .png image placed in my S3 bucket with a content-type of image/jpeg instead of image/png. 
  • Leverage Browser Caching (you can't do anything about Amazon and Google external resources, but IPS could and should add more to improve caching of its static resources)
  • Specify Image Dimensions - I get awful scores for this both on Gallery and Forums where images are missing width and height attributes. This happens particularly in grid view layout and where you upload an image attachment into forum description fields via AdminCP
  • Remove query strings from urls - Have raised this several times, and keep getting told it's needed to allow cache busting, but the string token could be built into the actual filename/url itself. If CSS for example is later rebuilt, a new url is created and immediately browsers see the updated resource and recache it.
  • All of the separate CSS and JS files should be grouped into one or two files, not like 10-12.
  • Pages article images should have medium sized thumbnails available instead of just tiny thumbnails which look awful stretch to cover on 4K displays. The alternative is full-sized (in my case massive 1920x1080 images) which kill page loading times are are such overkill for article listing previews.

 

 

 

 

Edited by The Old Man

Share this comment


Link to comment
Share on other sites
18 minutes ago, The Old Man said:

.

  • Pages article images should have medium sized thumbnails available instead of just tiny thumbnails which look awful ... 

 

You can set the size of the thumbnail already. I always raise it. The default is way too small.

what is needed is a regenration feature after making changes to the settings.

Share this comment


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

  Ask A Question ×