19 Comments

  1. Ciprian Popescu

    That’s nice.

    I heard that Chrome will introduce native support for lazy loading in the future. There is code in the Chromium codebase to support that.

    This would be a nice feature and it would reduce all JavaScript code required to implement this on the client side.

    Report

  2. Vlad

    Good news but it need a bit of improvement … we need a function to restrict specific images from lazyload… cause thouse img i have on top of the page make my page to jump in weird way which makes my page loading look ugly

    Report

  3. Vishwajeet Kumar

    This is really a great addition to Jetpack features. Lazy load is a great feature to optimize images and increase page load speed. Thanks for sharing these updates.

    Report

  4. Luis

    More bloat for Jetpack. It would be great if they slim down their monstrous plugin.

    Report

  5. David Anderson

    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.

    Report

    • Greg Brown

      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.

      Report

  6. Michele

    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?

    Report

    • Greg Brown

      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.

      Report

  7. Anass Rahou

    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.

    Report

  8. Faizal Amir

    This is great improvement from Jetpack! As i am using Jetpack for a long time but third party script for lazy load, will take a look to use lazy load from Jetpack. Hopefully it will optimize more. Nice job!

    Report

Comments are closed.

%d bloggers like this: