NetCrunch 13 is the latest release of AdRem Software's flagship monitoring software, containing many new features and enhancements. The monitoring solution can monitor various physical, virtual, and network infrastructures. It provides real-time network monitoring, traffic analysis, alerts, and performance reporting.

The post NetCrunch 13: Real-time network monitoring, traffic analysis, alerts, and performance reporting first appeared on 4sysops.

Depuis que Google a publié sa mise à jour Core Web Vitals, WordPress et ses équipes de développement essaie continuellement d’améliorer les métriques Core Web Vitals de ses utilisateurs.

La prochaine mise à jour majeur de WordPress, la version 5.9 pourrait avoir la capacité d’améliorer une des métriques jusqu’à 33%, sans rien faire !

Dans cet article, nous allons voir comment la mise à jour de WordPress 5.9 va automatiquement augmenter votre métrique Largest Contentful Paint !

Comment WordPress améliorera votre Largest Contentful Paint

Si vous avez suivi les dernières améliorations que Google a apporté à son algorithme, vous savez que les Core Web Vitals sont devenus des metrics / métriques importantes et ont un impact sur votre classement et positionnement dans les SERP. Cependant, la plupart des éditeurs de sites web ne savent toujours pas comment améliorer leurs Core Web Vitals.

Si votre site Web est propulsé par WordPress, alors voici une bonne nouvelle : les tests effectués sur WordPress 5.9 ont indiqué que cette version est capable d’améliorer la note Largest Contentful Pain (aka LCP) jusqu’à 33 % !

Le temps qu’il faut pour que l’élément le plus important ou imposant de votre site web ou de votre page web se charge et pour qu’un utilisateur puisse finalement interagir avec lui est appelé le Largest Contentful Paint (LCP).

L’équipe de développeurs WordPress propose de supprimer l’utilisation du lazyloading de la première image ou iframe de la page web.

Les développeurs de WordPress ont testé cette nouvelle « stratégie » sur les 50 thèmes WordPress les plus populaires et ont découvert que son utilisation sur la première image ou sur la première iframe entraînait une amélioration moyenne de 7 % du LCP.

L’équipe de développements a ensuite testé l’amélioration de LCP en ajoutant l’exclusion du lazyloading aux deux premiers éléments. Les gains de performance ont chuté de 2 % en moyenne, ce qui montre clairement que l’exclusion du lazyload à plusieurs éléments n’améliore pas plus le LCP.

Résultats obtenus par le lazyload WordPress

On va parler un peu chiffre et résultats des différents tests réalisés par les équipes de développement de WordPress.

En examinant de plus près les résultats concernant la suppression du lazyload sur la première image de la page, ils constatent que dans 42 % des cas, les modifications entraînent une amélioration médiane du LCP de plus de 10 %, l’amélioration la plus importante étant de 33 %.

Dans 5 % des cas, le LCP médian est environ 10 % moins bon, le maximum étant de 21% moins bon.

Alors que l’amélioration médiane du LCP sur l’ensemble des thèmes n’est que de 7%, il y a des gains notables plus importants pour un nombre considérable de thèmes, alors que les pertes notables sont mineures.

Il est probable que les cas où la métrique s’est dégradée soient liés à des sites possédant déjà des soucis de performances à la base. Si vous en êtes et que vous souhaitez améliorer vos performances WordPress, contactez-moi !

Source

Les performances web et son impact sur le SEO

Avant de commencer, et même si personne n’est capable de déchiffrer totalement les algorithmes mis en place par Google, pour positionner votre site à une place plutôt qu’à une autre, vous devez avoir accès à certaines informations. 

Malgré tout, il est possible d’en savoir un peu plus sur ces fameux critères, grâce à des tests, mais aussi profitant de la communication de Google. La vitesse de chargement d’un site est officiellement devenue un critère. En effet, il est désormais pris en compte et ça pour plusieurs raisons.

Depuis que Google existe, il a toujours clamé haut et fort qu’il voulait donner le résultat le plus pertinent possible. Aujourd’hui, il cherche en plus à offrir une expérience utilisateur la plus agréable possible. Bien entendu, il n’est pas là pour juger si le rouge aurait été plus pertinent que le bleu dans votre logo. En revanche, il sera très attentif à la position d’un bouton, pour que ce dernier soit cliquable. Il va aussi juger du taux de rebond de votre site web. Cela lui permettra de savoir si le site et son contenu sont meilleurs ou moins bons que les concurrents. Vous comprenez alors aisément en quoi le temps de chargement va jouer sur le taux de rebond, et par conséquent, sur la position de votre site web. 

Le temps de chargement va avoir un autre intérêt pour lui et donc pour vous. Google a de plus en plus de sites web à visiter. Il aura donc tendance à préférer les sites qui ne lui font pas perdre trop de temps lors de chaque visite. En optimisant le temps de chargement, vous lui permettrez de crawler plus de pages et par la même occasion, vous lui permettrez de mieux positionner votre site. On parle alors de crawling budget en SEO.

Vous venez de le lire dans le paragraphe précédent, WordPress va travailler activement pour rendre son moteur plus performant et offrir, de ce fait, un temps de chargement plus court. Mais attention, le fait d’utiliser la dernière version de WordPress ne vous garantit pas une plus-value. Il y a d’autres facteurs sur les lesquels vous pouvez avoir une réelle influence :

• Choisir l’hébergement : c’est sûrement le critère qui est le plus souvent négligé par souci d’économie. Pourtant, cela permet d’offrir à vos utilisateurs et au moteur, la meilleure expérience possible. 
• Utiliser la mise en cache : pour faire simple, cela permet d’utiliser le cache du navigateur, afin de charger des fichiers directement sur l’ordinateur, plutôt que de demander l’information au serveur. WordPress regorge de solutions payantes ou gratuites, pour optimiser et travailler cette mise en cache de fichier.
• Minimiser les différents scripts : les deux plus connus sont les fichiers CSS et les JavaScript. Il est possible de minifier le code, en supprimant les caractères inutiles. Attention toutefois à ne pas trop optimiser, ni à trop supprimer, sans quoi le site risque de ne plus fonctionner.
• Corriger les problèmes URL de votre site : quoi de plus désagréable pour un internaute d’arriver sur une page qui ne fonctionne pas ou mal ? Il vous permettra ainsi d’optimiser le fameux budget crawl alloué à votre site web.

Comme vous pouvez le lire, la web performance demande de vraies compétences et un réel savoir-faire. Il est important de confier cette tâche à de vrais spécialistes, sans quoi vous risquez d’obtenir l’inverse du résultat escompté. Il est également important de rappeler qu’optimiser son temps de chargement ne doit pas être une fin en soi, car ce critère fait partie de centaines d’autres. Il est important d’avoir une stratégie SEO plus globale.

L’article WordPress 5.9 améliorera vos Core Web Vitals ! est apparu en premier sur Constantin Boulanger.

Last week I spent almost 2 days fixing a complex Nintex/SharePoint 2013 issue with one of our customers. The customer was not very big in terms of headcount, but they were using Nintex workflow to automate all sorts of processes(one of the biggest I have worked with).
There were Workflow timer jobs stucking/failing, workflows exiting with errors for no obvious reason and more. The issue was resolved with a couple of fixes and at least the workflows were executed when they should and were ending as they were designed to.
Some of the issues and improvement points I flagged were: not properly scaled Nintex deployment, incorrect service topology, outdated product versions and poor workflow design.
Now, the fourth (poor workflow design) was partially dictated by the inadequate scale of the deployment. They were using a lot Pause and Commit pending changes actions. Many of the workflows were designed to have two minute pause after the first couple of actions.
As maybe you know the pause action actually pauses the workflow instance for the defined period of time, but the workflow will not resume immediately, it will be resumed when the "Workflow" Timer Job is executed. The default schedule of this job is every 5 minutes. This means that you cannot pause a workflow for less than 5 minutes or pause it for exactly the time you have set. You can change the schedule of the Workflow timer job to workaround the first limitation, but this can put additional load on your system.
This is why I demonstrated an alternative of the Pause action that do not pause the workflow instance, but just waits a certain amount of time before continuing the execution. I have not seen this approach in other sources and this is why I decided to share and explain it in this post.
There is another alternative to pause a workflow for less than 5 minutes. It is described in this article.
As you can see this alternative requires "NTX PowerShell Action". This is great, but this action is open source, it is deployed with Farm solution and although developed and published by Nintex Employee this addon is not backed and supported by Nintex. The PowerShell action is fantastic, but in my opinion it is not worth to deploy it just to use it as Pause alternative. Also you cannot use it in Office 365(SharePoint Online).
The PowerShell example works by executing the powershell code that will just wait a certain amount of time, then it will continue the execution. Obviously to pause a workflow we need to do some sort of waiting. There is no out of the box action that just waits, as we know Pause action is not doing anything, but actually idling the instance execution at certain point and waits for the timer job to resume it after the time is elapsed. With the powershell example we use the powershell (.Net) framework to achieve wating without doing anything for certain time. The same thing can be achieved with T-SQL statement execution and in Nintex Workflow both On-Prem. and Office 365 we have "Execute SQL" action.
If we want to put a wait in our SQL query for two minutes we can use the code below:

---

---

I am not a SQL guy and was surprised to find out that this statement works outside of the SQL Management tools.
Below is the designer look of my demo workflow in SharePoint 2013. This should also work for SharePoint/Nintex 2010.


As you can see it is pretty simple just for PoC. Below is the configuration of the "Execute SQL" action.

I am using a connection string that is using "SQL" as server, this is alias to the SQL instance that hosts my SharePoint, I am using SSPI security with Windows credential that are actually my farm account saved as global constant.
Below are the details from the execution. You can see that Execute SQL actions took exactly 2 minutes to complete.

Unfortunately you cannot use this approach on-premise  for pauses longer than 5 minutes without doing a loop and in this loop execute multiple times delays that are less than 5 minutes. If you do set delay more than 5 minutes the workflow will fail with error "Error performing database operation. Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding." even if you set connection timeout in the connection string to be more than the 5 minute delay. I will do some more tests/research and might report this as bug.

As described in the MSDN documentation of the WAITFOR statement, it should work against Azure SQL Database. In Nintex workflow for Office 365 we also have Execute SQL action. I actually tested this and noticed two things, the connection timeout you specified in the connection string will be set to 365 if the number is bigger than that, also if you set a delay longer than 4 minutes you will get some unexpected http errors during the execution, the workflow manager will do a couple of retries and then it will fail. I think that both are issues with the Workflow Manager in SharePoint Online.
This is not so important because the Pause action in the SharePoint 2013 workflows (Workflow Manager) are not depending on SharePoint timer jobs and you will not get the same pause issues as in on-premise 2010 framework, but it is still an option. See example configuration of the action below.



My final words are that this might be extremely useful if you need to put some short pauses(not more than 5 min.) in your on-premise workflows. I hope you find this useful!