I have seen many popular websites. Their page speed even not more than 90. My website page speed is more than 80. My question is when actually we should worry about the speed. Because For some days i am trying to speed up my page. But I don't know what is happening. Sometimes it's more than 90 then again it down less than 90.
My website is built on WordPress. I use All the plugin one by one. Such as smush, auto optimize, and others.
It is best if you (or your WordPress developer) can integrate certain features directly into your website, so that you can get rid of plugins that might slow down your website. If you didn’t know, plugins are notorious for injecting all manner of CSS and JavaScript code at the top of your pages. This can negatively affect your page load speed.
Related
I'm a front end engineer working in e-commerce and marketing, and one of my routine tasks is finding out why client's websites are so slow. Most of them are on different CMS, most Wordpress, and a constant problem I come across is page builders ship with a ton of code that slightly bog the site down. These fall under 'render-blocking resources', see the below
screenshot of the issue.
This file is entirely minified and the website isn't even large (It's still in staging, in fact.) Is it possible to get an outstanding Lighthouse score when your site is build on a CMS and uses a small number of plugins/apps (in the case of Shopify?) The majority of the clients whose sites I gauge are on a CMS and get a bad score because of how much data that browsers have to request when loading 200,000 apps and plugins. I'm exaggerating of course, but even when a client has a small site, but was built with a page builder and has a few popular plugins like Gravity Forms, their sites still suffer a little.
In theory, yes, you can have a page builder that doesn't impact the score, in practice, all of the page builders that I have personally worked with are bad for Lighthouse/PSI scores.
The main reason is that pagespeed hasn't been a conscious priority untill google started encouraging more awareness of a site's percieved performance. So the teams that built pagebuilders didn't take that into account, and it's probably not an easy task to change their codebase so that page builders are more performant.
There would be a few rules for page builders to follow to be performant.
No redundant asset code, I noticed a few page builders that load all
the code they might need for any section that a user might add, even
if the section is not being used.All the asset code being loaded should only be loaded if they are needed.
Properly sized images. I noticed Shogun page builder for shopify to
be really bad at this, as the images are automatically oversized.
Automatically lazyload images. I noticed pagefly has lazyloading, but
it has to be enabled individually for each template.
No elements created with javascript. To reduce CLS and improve LCP,
HTML elements should not be created entirely using javascript.
If page builders followed the above rules, and you replaced the original css and js of the page, since they would be redundant, you could have a page builder that resulted in very performant pages.
I haven't found a page builder that met these standards though, maybe as page speed becomes more important, more teams will be more consicous of performance in their page builders.
We have a Squarespace site (nataal.com) that has been steadily growing over the past 4 years. It now has in the region of 670 pages and is getting quite unwieldy, particularly when trying to scroll through the various page and link menus. Squarespace says 1000 max according to documentation, but < 400 recommended. Creating a user index for the pages is also a problem, ours now runs to about 50 pages in its own right (12 entries per page including thumbnails and captions). That's the way the creative people want it and who am I to argue!
Has anybody had experience, good or bad, of migrating such a site to a better platform? I have some exposure to Drupal and I think it would have worked well had it been used from the start. I have also heard good things about Wagtail, but I've never seen it in operation. Or is there some other platform I should consider?
So, what I'm looking for is a CMS platform that can
Easily handle more pages than Squarespace
Migrate from Squarespace keeping most if not all the structure of each page.
Automate the construction of page indexes.
Fairly east to tweak the layout of any given page to suite the topic.
Both Wagtail CMS and Drupal can support thousands of pages quite easily. In my opinion, Wagtail is MUCH easier to work with than Drupal - and a lot of websites that end up migrating to Wagtail have historically been from WordPress and Drupal (not all, but many!).
I can only give you info on ways to help guide your decision because ultimately the CMS you pick is your decision.
Drupal is a PHP based CMS that typically uses Apache and MySQL. A few pros to using this is the popularity in the tech stack and easy deployment. But the down side is the code gets messy, unruly, and eventually very difficult to maintain due to the structure of PHP as a language (not in all cases, but in most cases this ends up happening).
Wagtail is a Python based CMS that sits on top of a different database called Postgres but it can be swapped out for just about any other database you prefer (Postgres is well known as the "enterprise version" of open source databases). Wagtail also sits on a massively popular framework called Django which has SO MANY great features (too many to list here), but amongst those great features is security. With a Django/Wagtail site you'll have to do more developer work. There isn't really a "plugin" system like in WordPress, but that also means extending the longevity if your codebase and it's easier to maintain your code as it grows (due to the nature of Python, Django and then Wagtail).
I think the biggest downside to migrating such a large site is going to be moving all of your content over. In Wagtail you can structure all your page slugs to be the exact same as your squarespace site which is nice. But there's not an "easy" solution to migrating that much data from Squarespace to another CMS. (But please do make the migration, even if it's painful to do because it'll only get more painful as time goes on and your site gets bigger).
Regardless of which CMS you end up choosing, any dynamic website can create index pages for you very quickly and easily.
With all that said, should you choose to take the Wagtail route, I have a full series that can take you from "zero to hero" on YouTube at wagtail.io/course. We also have a great community where you can get support on the Wagtail Slack as well.
Good luck with the migration!
Wagtail can certainly support those requirements.
If you're in Oxfordshire, UK, you should come and see Torchbox (the creators of Wagtail) to talk about it!
Also you can change your Squarespace account to developer, the downside is that you can't get back to the normal one, but you can change it to developer mode and work it with Angular. I made this www.rudagt.squarespace.com and I will do this, cause the huge amounto of content, but, I have clients so for them SQspace is better interfaz than much others.
Good luck!
I would like to find out the sections of my WordPress theme which are slowing the websites down, is there a plugin which can give me a show me each action preformed and the speed.
I wouldnt use a plugin to find out where your site is being slowed down. I would run and SEO analysis on it (you can find them on a lot of seo companies sites - or just look it up) That will tell you if you are using irrelevant JS. If you are you can minimize it. Look for a JS minimister plugin that works well for your theme. Most plugins will be CSS and JS. Alternatively you could write a function so code doesn't execute on load.
I know the question sounds a little weird, but, please, read along. I have a store based on wordpress, woocommerce and wpml - currently in two languages but with plans to add another 3. The theme is quite huge with a lot of custom integration like Infusionsoft, Xero and more. About 50 plugins, 1100 product and 1700 posts. The number of posts and products will most likely double in the near future once we add another 3 languages. The overall setup is already kind of slow although we have enough server resources: 12 cores and 31 GB of ram. On top of this, I'm looking to integrate some sort of multi store and multi domain functionality. The multi store functionality will also require to be multilingual (wpml). There are two solutions to create the multi store functionality and none of them seems to be ideal and easily replicable without hacking more into woocommerce and wordpress.
1. Another install of wp, woocommerce, wpml and then using the woocommerce API to transfer the orders, stock, etc. back to the main site.
2. Wordpress multisite - from what i read is quite buggy with woocommerce and wpml.
As a developer myself, I feel this is a overkill for the wp, woocommerce and wpml. Especially if we take into consideration that Opencart or Prestashop comes with this functionality by default - without any kind of complications. But maybe, just maybe I am missing something really clever. Did anyone faced a similar setup ? What are your thoughts about developing such a complex setup in Wordpress and Woocommerce? Do you guys think it's imminent to move to another solution like Opencart, Prestashop or Magento ?
I would really appreciate your feedback about this!
Cheers
What i would do here is investigate why the website is slow first before adding hardware to the issue. Wordpress is a great base to start with but the same as all db driven websites needs optimization as the website grows.
There are many techniques for the below so ill just point to ideas and you can re-search them yourself and decide whether they suit your website.
Test here:
http://www.webpagetest.org/
To test your server code:
Use something like microtime to measure processes especially wp queries. http://php.net/manual/en/function.microtime.php
Where possible use caching (server caching) - possibly use varnish to cache product pages and serve static pages in place of dynamically created pages.
For expensive queries like post-archives use wp-transients or your own object caching.
To test browser code:
This is probably where you will see the greatest timesavings if you have 50 plugins. Unfortunately dev's love to hook js files, css files to the footer/header. This can be a significant load time. Investigate what you can remove from your templates (un-used js scripts, css files, etc) and de-queue them. For more savings see if you can isolate the css / js actually needed for the page out of the files present - combine into 1 file of each. Most of the time you will need the header/ sidebar css and some text styles but you are loading an entire themes stylesheet.
Pretty essential:
investigate your browser caching strategy.
https://developers.google.com/speed/docs/insights/LeverageBrowserCaching
Fun project:
Did you know you can load images/js/css to the cache using js? Pre-loading!
Maybe look at post-archives that require a lot of images and see if you can preload the "above the fold" content - your user will get a pretty quick browser load time and by the time they navigate below the fold the next batch of images should be cached (if you are combining with lazy load techniques)
This might save you the need to use extra servers but if you have to look at sharding rather than using a api to transfer data using php (i presume woo commerce api uses?)
My company's website runs through a PyroCMS install that was very expensive to build, but downright impossible to maintain. Also, it was built on a platform that did not use tags so the SEO of our blog is very poor.
I have built a replica of the blog on Wordpress and will be iframe-ing it into the Pyro install on the blog page. They are both hosted on the same server and the wordpress install is within the Pyro install.
My question is this: What do I need to do in order to enhance the SEO with the iFrame? Is there a better way to do this that I didn't think of? Basically, there are some good articles being written andI'd like the niche-ness of the topics to get move up on page rank.
Thoughts? Thanks.
~joe
It seems like you've got quite a bit on your plate with this website.
I recently (less then a month ago) signed up a client who's site is built on an equally difficult and very ancient platform. What we did is set up the blog as a page extension www.url.com/blog. The blog was on the WordPress platform and had all of our plugins added in as well (I can send you to a list of these if you would like). Doing it this way has multiple benefits of which the main are:
The blogs PR values is associated to the main index's authority.
Your index gets credit for all of the content being written on the blog.
The clients site I was telling you about, is already on page 2 for a few of their keywords (even though the site itself is no good). Obviously I would like to state that it isn't due to the blog that they are ranking, but it is a key feature as Google wants to see your site growing in pages with relevant, unique, shareable content.
Don't forget about social media and backlinks! Let me know if you have any other questions and please stay away from iFrames for many, many reasons...
Using iFrames will hinder your SEO efforts. Same goes for duplicate content (though dupe content may not apply in this case; I'd need more info). If I were you, I would not pursue this strategy.
I've seen iframed content get indexed as if it was really part of the page it was in, but yuor creating a massive battle for yourself.
One of the biggest issues of using iframes is that every page of your blog will look like it is on the same URL. Have a go. Move around the blog and check the address bar. No change.
This means people cannot bookmark, link to or return to a specific page on your blog. A really bad user experience as well as crippling your ability to acquire natural links to your blog pages.
There are further issues but that should be enough to mean do not use an iframe for a blog.
Answer: to enhance SEO for the iframe, don't use it.
Why do you feel you need an iframe in the first place. Is it to wrap the websites design around the blog. If that's the case, update the blogs template so it naturally looks like the rest of your website.
If it's because you don't like the domain the blog is on. Move it.