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

I've solved all the new features speed improvements using pagespeed module with Redis, on the high 90% in PageSpeed Insights, GTMetrix and all "A" in webpagetest. It's nice to see all these improvements addressed..

Some suggestions

Create different size avatars instead of using a 200x200 image on a 34x34 placeholder, there are CSS's that dynamically resize the originals, at the expense of bandwidth.

Articles images have the same problem, if I choose a 1000x1000 image, on the record list every article will download the ORIGINAL image and resize it with CSS... huge bandwidth usage.

Reduce the DOM tree...it's huge 

Saludos

Share this comment


Link to comment
Share on other sites
20 hours ago, opentype said:

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.

Thanks @opentype

Found it, Record Image Settings under Pages Databases. Yes, a rebuild tool would be very useful.

Share this comment


Link to comment
Share on other sites
40 minutes ago, Ryan H. said:

With the overhauled PageSpeed Insights data and scores based on Lighthouse, where does PWA fit into IPS's roadmap?

We've announced the inclusion of application manifest functionality in 4.4, which lays the groundwork for future enhancements

 

Share this comment


Link to comment
Share on other sites
On 11/17/2018 at 6:20 AM, The Old Man said:
  • All of the separate CSS and JS files should be grouped into one or two files, not like 10-12.

This is absolutely no longer the recommended approach with HTTP/2 becoming mainstream, just FYI. Naturally there's always a balance, but I would recommend reading up some more on best ways to handle CSS/Javascript with HTTP/2 to learn more.

Share this comment


Link to comment
Share on other sites

Any work on changes to the plugin/application system of loading the entire PHP file in, doing a str_replace and EVALing the entire thing as doesn't using EVAL prevent opcache-specific optimizations from functioning? (haven't looked into it so not sure if true)

Share this comment


Link to comment
Share on other sites

This blog entry details (and/or touches on) at a high-level some of the changes made in 4.4 to improve performance. 

There will always be other areas that can be improved. There are always new test suites that can be tested against. Technology is constantly changing, both on the backend and in the user agent. If something was not mentioned in the blog entry, chances are it hasn't been changed. That doesn't mean it isn't something we should look at, it just means we haven't yet due to many reasons (time is one factor, but also sometimes changing an approach, such as how plugins are handled, is not a simple thing to do). I recommend posting suggestions of other areas you would like for us to look at in the appropriate feedback forum, so when we are planning 4.4.1 or 4.5 or 5.0 or any other future version, we can easily reference those ideas. Posting your suggestions here in blog entry comments will, unfortunately, likely result in those ideas being lost and forgotten.

Share this comment


Link to comment
Share on other sites
On 11/19/2018 at 2:19 PM, Adlago said:

Are you planning removal of old property prefixes in 4.4 version?

1229592814_Screenshotat2018-11-19211317.thumb.png.56b52e333afc1f52461ed92c521bbc85.png

There is no actual benefit in doing this.

Those additional prefixes are also there for a reason. They're maintained for backwards compatibility. 

Share this comment


Link to comment
Share on other sites
On 11/19/2018 at 8:01 PM, silenceheaven said:

Any work on changes to the plugin/application system of loading the entire PHP file in, doing a str_replace and EVALing the entire thing as doesn't using EVAL prevent opcache-specific optimizations from functioning? (haven't looked into it so not sure if true)

We are knocking around ideas for 5.0 thanks to PHP's improvements in this area. It's too large a change for 4.4.

Share this comment


Link to comment
Share on other sites
On 11/23/2018 at 9:06 AM, Matt said:

We are knocking around ideas for 5.0 thanks to PHP's improvements in this area. It's too large a change for 4.4.

ETA?
: P

Share this comment


Link to comment
Share on other sites
On ‎11‎/‎21‎/‎2018 at 6:58 PM, Rikki said:

Just to note, we decided to go ahead and support lazy loading for external embeds like YouTube too for 4.4. Most embeds (Facebook, Twitter etc.) already lazy loaded because they routed through a local URL, but external embeds will also lazy load now. You're welcome, @Mr 13 🙂 

I currently use Lazy Load Videos plugin from the market place and works very well, will your solution work in a similar way for imbedded video. ?

Thank you

Share this comment


Link to comment
Share on other sites
5 hours ago, bearback said:

I currently use Lazy Load Videos plugin from the market place and works very well, will your solution work in a similar way for imbedded video. ?

Thank you

Not quite. It looks like that plugin replaces the video with a screenshot until the user clicks it to load the video. Our built-in approach will always load the video, but only once the user has scrolled down far enough to see it.

Share this comment


Link to comment
Share on other sites
On 11/16/2018 at 9:49 PM, Rikki said:

We've actually optimized all images in the suite too

On 11/16/2018 at 8:30 PM, bfarber said:

It's actually less necessary there because we end up with one single image file

Still can't get why should we use something in around 300 KB when it could be implemented in around 1 KB. Mobile data is expensive and slow in most cities of the world, even in america, isn't it?

Edited by Mr 13

Share this comment


Link to comment
Share on other sites

That's not accurate; it's a single image, with a different background color. Your browser doesn't download it for every club. If it's 280KB, your browser will only download 280KB, once.

Share this comment


Link to comment
Share on other sites
1 minute ago, Rikki said:

That's not accurate; it's a single image, with a different background color. Your browser doesn't download it for every club. If it's 280KB, your browser will only download 280KB, once.

Yes, you're right, i've just edited my previous message because discovered it in actual output. So there is the new question now 🙂

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 ×