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.
Related
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.
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!
We're building a Kentico 8.2 site using ASPX+portal model. Looking at the rendered HTML on my live site I can see a lot of unnecessary Javascript that Kentico has dumped into my page. What's more this is occurring at the top of my page at the top of the form element.
For example, it's rendering the ASP.NET __doPostBack JS function even though I'm not using any controls that require it. Other scripts are being added as WebResource.axd and ScriptResource.axd includes.
At a glance it would seem these scripts constitute the Microsoft AJAX framework used with UpdatePanel etc. My assumption is that they are there to add portal manager functionality when using the page in the Kentico UI. Presumably they are also used with certain built-in web parts.
However, I am only using custom web parts on my live site so all these scripts are doing nothing and are just slowing down my page and causing poor performance testing results.
I've tried hiding the <ajaxToolkit:ToolkitScriptManager /> and <cms:CMSPortalManager /> controls on my master page when rendering the live site, but this causes templates that have a <cms:CMSWebPartZone /> to break.
Does anyone know how to ensure this bloat is removed when not required? Or at the very least cause these scripts to be rendered at the end of the page so they don't interfere with performance too much?
Unfortunately, building sites within Kentico using ASPX and ASPX+Portal Pages will automatically generate additional markup such as __doPostBack, WebResource.axd and ScriptResource.axd.
I wouldn't recommend removing any of the default code in your Masterpage. This will cause things to break (as you've experienced).
However, having this markup in place shouldn't cause a massive issue in page performance. Understandably, this isn't ideal.
What I do to lessen the hit is the following:
Disable the ViewState wherever possible. For example, either at Page Template or Webpart/User control level.
Move the ViewState to the bottom of the page (in Kentico Settings), so the page is less "top heavy".
Ensure you are caching everything you can. For example, site furniture used by your webparts and templates (images/js etc) at IIS level and at Kentico level using their API.
Reading this article from the Kentico documentation provides some more information in greater depth: Optimizing website performance
If you really want "full control" over the HTML rendered, Kentico does allow you to create templates using MVC. But this won't give you the flexibility to modify Page Templates by moving around web parts within the CMS Administration. I presume you have chosen the Portal Page approach for this very reason.
I hope this helps.
In addition to #sbhomra's great answer I have a few questions, suggestions and comments.
How many seconds or milliseconds are you talking about with performance? If you think you'll gain a few milliseconds back, it's not worth your effort to try to rebuild all the functionality. If you're talking a second or two, there about 15 different things you can change within settings and your code to gain it all back. Think about how much code you're going to write, maintain and upgrade just to gain a second or less back?
The WebResource and SciptResource load resources that are compiled into libraries within the website. So if someone created an external library and that library was loading an image that was compiled into it, you'd get that WebResource.axd reference on your site. You'd have to physically remove those libraries from the Kentico instance.
Although I don't recommend it strictly because you lose so much functionality and have so much extra unnecessary code, MVC will give you the control you're looking for.
I want my website to be published as content in an LMS, one of the experts suggested me to use either SCORM and AICC. They suggested that we should make a wrapper around our website and then publish it on the LMS. Now I tried to search and read about SCROM and AICC but was not able to get any idea or how the wrapper has to be built.If someone can guide me with a blog or make steps of how should we achieve this.
Essentially, you have a few e-Learning Content Libraries out around the internet in a free and paid capacity. The primary job is to locate the LMS Runtime API. Your implementation is possible, but it would take some careful packaging and some custom work to get it done.
Every e-learning developer has to commonly build a Shareable Content Object player. This can be done using a IFRAME that loads pages. This allows the main page the LMS launches to load once, and unload once. Another route modern content takes, is to use AJAX to load in snippets of HTML and have a similar paging feel without the overhead of the IFRAME.
The next hurdle is trying to mitigate the cross-domain policy...
As you mentioned you could go AICC mainly because its cross-domain enabled. AICC is a bit more limited in what you can record though. Keep in mind this standard predates XML. So we are in the text with delimiters category of configuration.
SCORM is going to have a cross-domain security (sandbox) error associated with the JavaScript on your website trying to talk to the LMS. There is away around this, by possibly including your base index.html page which can use your JavaScript, CSS, Images on your website. But, if your website changes pages, we are back to my above comment. We need to wrap this in a IFRAME.
In the IFRAME scenario, you'd have to put your e-learning standard library there. And your sub pages in the IFRAME could talk to the parent. This ensures your main page and all sub pages have a line of sight to parent of the frame and can make calls if its present.
All of this really depends on how you built your website. We run content off media servers similarly, and have these same hurdles, but the content is meant to be activities, games, and tests/quizzes. If you adjust your website to try and communicate this way you'll have to pad it for working with and without a LMS and any runtime data.
You can still launch a website as a asset though. Not graded as a option. Some commonly do this as part of a lesson where the student can read something, then take a test on it in a subsequent assignment.
Good Luck,
Mark
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.