Jetpack 5.8 Adds Lazy Loading for Images Module

Jetpack 5.8 is available for download and includes a handful of new features for Professional, Premium, and Personal plan users. In October of last year, Jetpack 5.4 began beta testing a new search module based on Elasticsearch. Jetpack 5.8 concludes the beta and the new search service is available to Professional plan customers.

The new search module replaces the native search functionality in WordPress and Jetpack developers claim sites with a large amount of content, images, or products will see significant speed improvements and more relevant results. Developers can fine-tune the user experience by using custom queries and template tags. Users can sort results by categories, tags, month/year, post type, or any taxonomy.

In addition to the Content Delivery Network, users have another method to optimize their sites with a new module named Lazy Load Images. When activated, Jetpack will display a page’s textual content first. When a user scrolls down the page, Jetpack will request and download images so they appear when that section of the page comes into view. Sites with a large amount of images will benefit most from having this module activated.

Premium plan customers can now perform security scans on their sites at any time, upload an unlimited amount of videos, and access SEO tools that were once restricted to Business plan customers.

Other notable improvements include:

  • Support for timezone and site language settings
  • Improved display of notices
  • The GettyImages shortcode now uses the new format required by GettyImages

To view all of the additions in this release, check out the Jetpack 5.8 changelog.

19

19 responses to “Jetpack 5.8 Adds Lazy Loading for Images Module”

  1. The new search module replaces the native search functionality in WordPress and Jetpack developers claim sites with a large amount of content, images, or products will see significant speed improvements and more relevant results.

    I’m not sure how I feel about this. It’s generally agreed that WP’s built-in search is not good. Is JetPack now the solution for defects in WP core? Is anyone now going to address WP’s search problems, or is that now a fixed problem?

    How much do we want “install JetPack!” to be the solution to “parts of WP core are bad” ? With both core (i.e. WP foundation) and JetPack having the same ultimate leadership this just feels very uncomfortable.

    To make the concern clearer… we know that plugins are for adding features. There’s no problem that JetPack adds features that core does not have. But “more relevant results?” and “speed improvements” ? Those are arguable fixes for core defects., not new features.

    • Hi David,

      I’m one of main developers on the Jetpack Elasticsearch systems. I’ve also worked a bit on search systems on WordPress.org (haven’t really worked on Core yet). With that background I can give you my opinion.

      But “more relevant results?” and “speed improvements” ? Those are arguable fixes for core defects., not new features.

      This is a reasonable question you’re asking and one I’ve asked myself. That said, doing something in Jetpack doesn’t prevent it from happening in Core and maybe helps us learn what Core should do. From what I remember, the last big Core change to search was in 2013 when switching to relevance sorting: https://core.trac.wordpress.org/ticket/7394

      I think one of the problems there was that they couldn’t do as much as they would like because it caused performance problems on a lot of hosts. Jetpack of course gets around the performance part of the problem by offloading queries. The MySQL performance on a lot of hosts is so bad that doing a remote request (potentially across continents!) is significantly faster than querying the local DB.

      On the relevance problem, MySQL has historically not been very good at search. I remember a good analysis a number of years ago (which
      I can’t find right now) comparing MySQL full text search and Lucene search (Elasticsearch is basically a wrapper of Lucene). By just switching over to Lucene (no extra tuning) the accuracy of the first result increased by 4x (precision@1 is the technical measurement).

      Both of these are old-ish, anecdotal data points, and technology has improved, maybe Core could take another crack at it. Gutenberg certainly introduces some challenges for search because blocks are stored in post_content, so may increase the need for making changes. To me it feels like another table would be needed where content gets mirrored and somewhat denormalized. That is what we are doing for Elasticsearch indexing, and maybe that could be a model for Core to use. Maybe MySQL has also improved and needs some new investigation. Any such change would be challenging to support across all hosts though.

      I think search isn’t the only issue though, I think we need to be thinking about democratization of algorithms. Reverse chronological is obviously kinda limiting for engaging an audience. Why are Facebook/Twitter/Google/etc the only websites that can easily deploy an algorithmically organized “newsfeed” as their front page? How do we support algorithms that let small pages reorganize their content based on the user who is visiting? If I go to a site 6 times a day, why would it always show me the same content? If the site wants to, why shouldn’t it try to engage me better than reverse chronological sorting is capable of?

      I have ideas on how to do that with Elasticsearch. I’m not sure how we do it with Core on top of MySQL yet. I definitely think it is something we (Core) should pursue. I also think it will be very hard, and is not nearly as important for Core as the current work on Gutenberg and customization.

  2. I know that native WordPress search got significantly better in 2013, but I’m still using the plugin Relevanssi. With a large content-heavy site, we wanted more control over how results are weighted. For example, to prevent a blog post on a topic from ranking higher than the overview information in a static page. I’m wondering how Jetpack Elasticsearch compares, and if it would be even better for those needs?

    • Hi Michele,

      Sorry for the slow response.

      Jetpack Search does allow full control to override the Elasticsearch query. We do not currently have any UI in the admin to allow adjusting it though. In general I think hand tuning parts of the query is pretty hard to do, and so adding UI for that would not be very beneficial and would be confusing for most users. As we get data from more sites I am also planning to experiment with the defaults to try and improve the default query. So I don’t want to add a lot of UI for something that is likely to change a lot.

      With some coding though you definitely can change the query. The individual field boosting is done here (and can be overridden): https://github.com/Automattic/jetpack/blob/master/modules/search/class.jetpack-search.php#L845

      Additionally there is an open issue to add more filters for controlling the query. Your case of wanting to boost one post type over others is covered in there: https://github.com/Automattic/jetpack/issues/7975

      Improving query customization is definitely something we plan to work on.

  3. The inclusion of the search module based on Elasticsearch is something very revolutionary for Jetpack, and will be one of the most used tools in the range of modules of this plugin.

    However, we think that the internal search engine of WordPress is a tool that needs even more work by the internal development team in a major release, since this will help visitors find more quickly what they are looking for on the website, and therefore more time will spend consuming the content, and this will undoubtedly contribute to the loyalty of visitors.

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.