lesley

I posted the post, I thought with their community it would do well there. I watch our analytics pretty closely as well. I knew something was up when it jumped to 140 users on our site at once.

Yay, If you want to checkout the post, it is here, https://news.ycombinator.com/item?id=15027715 Give us an upvote if you have an account :thumbsup:

They are two different sites.

Sure thing, it is moved.

Ahh, I did not realize. I thought it was part of the plugin you were asking about since I have never used it before. You might try something in the job offers section, I know there are a couple of developers in the community always looking for work.

I am not sure. Have you reached out to the developer, he is a member of the forum. @smartdatasoft

Yeah, it could be something we look into. I have wondered if it is needed because with the optimizations running a site without the cache is fast as well.

@hubbobubbo Correct, we have the same caching feature built into the core. The only thing we do not have yet is a cache warmer like they do. I think the reason for the 1 second wait is because of the location of the Google test machine. Seattle is a long way away from the EU.

Modules like that are great, that is why we added that in the core. Yeah, our page caching is very similar to the module, likely we have a little bit better performance as well. Clearing the caches is the downside of using a full page cache, but it works in the long run if you do not make too many edits in production.

Are you clearing the cache on your site? Is there a server cache that might be affecting the changes?

@DavidP Another thing you have to realize, tools like Pingdom and GT Metrix do not take into account the time it takes to render a page. If you have complicated JS that slows down the rendering of the page you will never see it with those tools, then you will be left wondering about the high bounce rate on your site.

the blocksearch.css should work, are you sure you are targeting the element correctly? You might try #search_query_top { } as the element.

@DavidP I didn't even realize. The demo sites are hosted in Seattle though, https://www.screencast.com/t/7v9qQJnnCfSf so it was geographically closer.

I actually took the time to write a blog post about this if anyone wants to read it, https://thirtybees.com/blog/pagespeed-is-dead/

Honestly the page speed metric is about to be done away with because of the problems in it actually being real world useful, so we don't target it. It also provides false results on load time because of how google does things. If you have site hosted in the US, but a EU visitor runs page speed on the site, it loads the page speed from EU. Which I think we all know will show slower because of data latency. One test I do prefer is pingdom, which shows the total load time of the site. https://tools.pingdom.com/#!/ehSFr2/https://front.thirtybees.com/ Which is well under a second. What Google is actually transitioning to is Lighthouse. If your Chrome has updated already, it is in Chrome 60 now. It doesn't give the blanket recommendations that pagespeed does, it gives a more meaningful metric that shows how the user experience is. That is why Google is migrating away from pagespeed to Lighthouse. See Pagespeed just looks at things with a very broad stroke and does not take into account how the actual user experience is. A good example is the render blocking CSS and JS. It simply defines that metric based off the size of your files, nothing more. CSS loadings in a cascading way. So your first css selectors could paint your page before the file has fully loaded. That would be a meaningful paint. This is when a mobile user clicks a link to your site and can actually see your site on their screen rendered. If you run thirty bees through lighthouse you will see different results. Like this, https://www.screencast.com/t/DD6r7NixEqY If you run the slimmed down 1.7 PrestaShop demo through Lighthouse you should see results like this, https://www.screencast.com/t/cXt6004lg6Qz To be fair, here is a shopify demo as well. https://www.screencast.com/t/ZLlo4YEV5 See now you are not relying on metrics that could have no bearing on the actual user. You are relying on the metric that will decide if users press the back button or not.

It does seem like it. When you disable all third party modules does it help the loading time? You could have a module that is poorly written.

Hmm, it is something that should not be in our version. Our demo sites run on less memory than that.

I cannot tell if you are trying to be intelligent and unintendedly coming off as insulting or if you are just trying to be long winded and insulting. Let me start with the shell scripts and why they are bad. Installing the software to run a server is only a quarter of the battle. These are not Wordpress sites or static Jekyll sites we are talking about. We are talking about sites that take payments and host personal information for all of your users. Depending on the products that are sold the personal information can be damaging. Needing a shell script to install a simple PHP application and a server means you do not know how to manage a server. This is a bad practice. Environments like this are fine when you are running in your localhost sandbox. But not for applications running on the web. I am not going to teach our users bad practices to save them a few dollars a month. That is a great reason for managed hosting. Updates get pushed to packages that need updates. Not all updates are as easy as apt get update. Some require configuration. Some of the packages we recommend require good configurations or they expose sites to security risks. One I can think of off the top of my head is REDIS. Setup improperly it exposes the whole server, https://www.itnews.com.au/news/insecure-redis-caches-abused-for-linux-server-attacks-435968 It, like other packages needs more than a simple shell script. It needs hardening, updates, security patches, and configuring. Someone that has trouble installing a PHP application that installs like every other PHP application in the world has no business running their own internet facing server. There is a reason there are people that are paid to configure them. I do not see a need to disclose about the terms of our hosting partnerships. It is an industry standard. It would be like every commercial on TV saying they bought the space to either change your mind or sell you a product. Its the status quo, we partner with companies that we earn commissions from to help us grow the software to help merchants be successful. I am missing the point where this is a big deal. If you feel that hosts are a big portion of the monetization strategy you would be wrong. To be totally honest they are one of the smallest means to monetization. Our strategy lies in other places that are more profitable. That is why we help users no matter what host and try to refer users to the best hosts possible. I think you miss the whole idea of freemium. What you claim to be freemium is not freemium. You might read this, https://en.wikipedia.org/wiki/Freemium We aren't going to have tiers of the software. We will have just one version, free. Not limited and you can pay more to get more features, just free. As far as it being a marketing weakness, it is not. We are a company just getting started. To be honest I skimmed the last half of what you wrote, so I am not going to address it point by point, I am just going to blanket address it. We are not going to abandon PHP for another language. It does not work. The other languages do not work in a large scale. Our forum is in node. We now have to maintain several forum modules because in the 4 months that we have taken it up they have become abandoned. We are not going to strap ourselves down with a ton of technical debt. PHP is not the hot, hip, js language of the week. It is the language that powers the web hands down. You might think it is declining, but it is not. I actually should do more delegation, you were right on that. I have a feeling I should rely on you to write a shell script to install thirty bees. I think you would do a good job with it. You seem to be dedicated to task with little or no reward and you like to write. When you finish with it, shoot me an email. Also, if you want to do the screencast and write a blog post you are welcome to as well. We can host the script in our repo and post the post to our blog. If that does not suit you, go to the feature request section, add it in, and lets get to voting on it. We are sorting through them this month to see what is going to make it in the next version.

Something must be misconfigured to use that much memory. Do you have any modules installed? How big is your catalog?

No, something is wrong if it is using that much memory. It should only require about 32mb on that page. In the Advanced Settings -> configuration is it showing 256mb?

It looks like your server is running out of memory. Can you set your php memory limit higher.

Its not that we are trying to create a two sided market. That market creates itself really. I think you are really off base with the software being too difficult to install. Its not. Its as simple as Wordpress, Joomla, PrestaShop, et al. None of which offer shell scripts. To be 100% honest, offering a shell script is a bad way to entice people to use the software. It promotes bad practices. Shell scripts were all the rage until real replacements came out like Docker and Vagrant. I also think you are way off base in the whole sign up with one of our partners We currently have 3 hosting partners. thirty bees is currently available as a free install on over 1000 hosts. It does not look like we are cornering that market and trying to keep people from installing thirty bees if they do not use one of our partners. Actually, that is quite not the case. Our two advertised partners now have custom installers. I made it a point personally before we partnered with anyone for hosting to reach out to Softaculous to be able to be included in their installer. If I were trying to stunt the thirty bees market and push users to our partners, that would have been a monumental bad move this early on. We also believe in FOSS, that is why we have started thirty bees. I am not sure if you have read around our blog or our other postings, but know two things for sure. thirty bees will never sell code we develop, it will always be FOSS. We will never be a SaaS platform. Both we feel are against the very nature of OSS. We don't want to alienate anyone, we never will. Well, almost. There are toxic community members that need to stay toxic and never switch to thirty bees. I am ok with alienating them. I also think you need to look at things from our perspective. What I see is one person in a forum asking for something. I look in my other window and I see bug reports and feature requests. We are a small team currently, a small team trying to keep up. We are starting to get momentum and help from contributors such as @Traumflug @roband7 @Occam and @yaniv14 (and anyone else who I forgot). We have to look at each task we could do and weigh it. Sure we could spend all of our time doing the wrong tasks, where would that put us? No where. Or we could objectively look at the tasks, talk to the community and see the need for the tasks. What part of our mission is, is to be guided by the community. We are not store owners, we are developers. If there is enough need expressed for something it will end up on our roadmap. The more help we get with things, the faster the roadmap is traveled.

Oh, what was wrong with it?

To be honest it is low on our priority list. There are generally two target demographics with software, users and developers. We are targeting both. That is why we have deals with companies to make installations easier for our users. At the same time developers can either download a package or use a CLI installer. The market you are talking about, it does exist, but it exists in such a low number the effort at this point in our development would not make it worth it. If you are wanting to develop such a script we would find a place for it. We could make a blog post on it and get it some exposure.

Great, thanks.