Wie kan mij helpen met het versnellen van Wordpress websites?
Deze zijn gemaakt met DIVI of Elementor.
Ik ben op de hoogte van Cache plugins maar deze zorgen voor overbodige javascript verklein bestanden en css verklein bestanden.
Via een PB kan ik een website geven zodat je weet wat ik bedoel.

Hoi Jordie

Sites optimaliseren is één van mijn core businesses.
Ik kan dit dus voor je doen, tegen scherpe prijzen.

Ik zal je een pm sturen.

Groeten

@Arjen: Ik wist niet dat jij ook verstand had van page speed;-)

Stiekem wist je dat wel ��

Origineel gepost door Jordie scheepeers

Deze zijn gemaakt met DIVI of Elementor.

Het begint met het dumpen van die pagebuilders, die zijn de oorzaak van de ellende. ;-)

Origineel gepost door Jordie scheepeers

Ik ben op de hoogte van Cache plugins maar deze zorgen voor overbodige javascript verklein bestanden en css verklein bestanden.

Die 'optimalisatie' en 'cache' plugins verkleinen en comprimereren de javascript en stylesheet juist, en voegen al die flarden code ook samen tot één .js en één .css bestand. De Google Pagespeed tool noemt die bestanden vervolgens overbodig maar dat zijn ze zeker niet. Alleen is het effect van die plugins niet altijd ideaal.

Over pagebuilders zeg ik niets meer want ik voel mij al een LP die blijft hangen;-) Gooi op deze hoop Bootstrap en Font Awesome.

Origineel gepost door B. van der Weerd

Die 'optimalisatie' en 'cache' plugins verkleinen en comprimereren de javascript en stylesheet juist, en voegen al die flarden code ook samen tot één .js en één .css bestand. De Google Pagespeed tool noemt die bestanden vervolgens overbodig maar dat zijn ze zeker niet. Alleen is het effect van die plugins niet altijd ideaal.

Sorry, maar het is wel overbodig. Probleem is namelijk dat het gewoon alles samen voegt en niet de overbodig css of js verwijderd. Dit komt vaak door te veel plugins en het thema. Strippen van css en js file is bijna niet te doen maar het is veel beter om alleen te laden wat je nodig hebt. Bijvoorbeeld als je gebruik maakt van contact-form 7 en maar 1 formulier hebt op je contactpagina dan kan je die zooi alleen daar laden en verder niet. En dit kan je per plugin/thema nakijken en bepalen.

De vraag is altijd: hoever wil je gaan en hoeveel ben je bereid hier aan tijd en energie in te steken of hoeveel geld je er voor over hebt. Je kan kiezen tussen die plugins en dan moet je gewoon al die ellende accepteren, maar je kan ook fine-tunen en dat kost tijd maar het resultaat kan super zijn.

Probleem is steeds vaker dat men te hoge kwaliteit afbeeldingen willen gebruiken en dat zijn soms zeer grote bestanden. Ik heb afbeelding van 25mb gezien en vragen dan aan mij waarom de website langzaam is;-) Je bespaart kb's op js en ccs en is dan helemaal voor niets geweest.

Origineel gepost door Cornelis de Leeuw van Weenen

Sorry, maar het is wel overbodig. Probleem is namelijk dat het gewoon alles samen voegt en niet de overbodig css of js verwijderd.

Vandaar dat ik zeg dat het effect van die plugins niet ideaal is. Je kunt inderdaad vaak beter bepalen welke js/CSS op welke pagina's moet worden geladen, daar heb je icm een cache inderdaad vaak net zo veel aan. De 'extra zaken' kun je inderdaad het beste alleen daar laden waar het nodig is al moet je natuurlijk ook voorkomen dat er voor iedere pagina weer een andere CSS moet worden geladen.

Ik heb een thread afgelopen week gestart op Wordpress community forums zelf. Het wordt "asociaal" hoeveel resources het vreet om een kleine of zelfs grotere website te draaien. Nu heb ik een website van een klant met ~ 1500 bezoekers per dag en ruim 150+ artikelen op hun website. Een eigen custom server voor ze, 4 cores en ruim 8GB ram, Litespeed en gebruik van LSPHP 7.4 wat voor 1 website meer dan voldoende zou moeten zijn.

Echter ontkom je niet aan gebruik van vele plugins voor o.a woocommerce wil je dat dingen echt vlekkeloos gaan lopen. Zowel in beheer, als bestelling en als finale pakbon wat uit de website gepoept moet worden na bestelling. Paar dagen terug werd geklaagd over de enorm lange loading times die plaatsvinden in de admin, en jawel, ruim 17 seconden om van pagina naar pagina te hoppen terwijl de load nagenoeg op 1% ligt.

Ik ben ermee aan de slag gegaan, Litespeed settings wat getweaked, onpage optimalisatie maar ook in de backend van wordpress. Als eerst wordt er onnodig veel calls gemaakt, ook door woocommerce om iedere handeling in een database te gooien wat soms op kan lopen tot ruim 15.000 rows. Ook maakt het iedere keer calls zodra je van pagina wisselt om te kijken of er updates zijn. Of een licentie klopt. Of het onnodig inladen van meerdere RSS feeds die op de homepagina van de admin tentoongesteld staan. Niet dat iemand die leest, maar toch. Het kost onnodig veel resources.

Dus, ik heb een handvol code's verzameld en toegepast,

Code:

add_filter( 'site_transient_update_plugins',
    function ( $oUpdatesResult ) {
        if ( ! is_object( $oUpdatesResult ) ) {
            $oUpdatesResult = new stdClass();
        }
        $oUpdatesResult->response = array();
        return $oUpdatesResult;
    },
    PHP_INT_MAX
);


add_filter( 'pre_http_request',
    function ( $bFalse, $aReqParams, $sUrl ) {
        if ( strpos( $sUrl, '//api.wordpress.org/plugins/update-check/1.1/' ) ) {
            $bFalse = null;
        }
        return $bFalse;
    },
    PHP_INT_MAX,
    3
);




add_action('wp_dashboard_setup', 'remove_dashboard_widgets');
function remove_dashboard_widgets () {
remove_meta_box('dashboard_primary', 'dashboard', 'side' ); 
remove_meta_box('dashboard_secondary', 'dashboard', 'side' );
}


add_filter( 'http_request_args', 'wpse_102554_deny_theme_updates', 5, 2 );
function wpse_102554_deny_theme_updates( $r, $url )
{
    if ( 0 !== strpos( $url, 'http://api.wordpress.org/themes/update-check' ) )
        return $r;


    $themes = unserialize( $r['body']['themes'] );
    unset(
        $themes[ get_option( 'template' ) ],
        $themes[ get_option( 'stylesheet' ) ]
    );
    $r['body']['themes'] = serialize( $themes );


    return $r;
}


if ( ! defined( 'ABSPATH' ) ) {
    exit; // Exit if accessed directly.
}




add_filter( 'action_scheduler_retention_period', 'wpb_action_scheduler_purge' );
/**
 * Change Action Scheduler default purge to 1 week
 */
function wpb_action_scheduler_purge() {
 return WEEK_IN_SECONDS;
}

Welk je in de functions.php laadt van je thema, en eureka. De avg laadtijd schiet weer terug naar 2 seconden om van pagina naar pagina te hoppen. Op de frontend is de time to first byte aanzienlijk gestegen. De server is niet meer bezig met onnodige controles iedere keer. Een cron kan best iedere minut uitgevoerd worden en niet per hit per bezoeker. Wordpress wordt feitelijk steeds meer locher, groter, vreet resources en echt 40% van je traffic wordt of is veroorzaakt door controles op updates, bruteforces maar ook onnodige shit die totaal niets van doen hebben met je website.

En je kunt het ook niet straight krijgen met Insights, teminste niet 100%. Vaak zie je dat JS files sitewide worden geladen terwijl bepaalde functionaliteit alleen op 1 afrekenpagina of 1 product pagina in voorkomt. Ook CSS hetzelfde verhaal. Remove unused CSS. Idd. 100KB soms wat een client wel verwerken moet. Maar laat nou net die CSS noodzakelijk ergens op een pagina zijn waardoor je of thema hacks moet gaan toepassen (if is page $paginanaam blabla) om het strak te krijgen. Belangrijk is een server, in mijn ervaring werkt litespeed het beste op allemaal.

Waar ik voorheen amper 200 actieve wordpress sites op 1 machine kon stampen, zijn dat er nu gerust 500 en de troep gaat niet onderuit als het ff druk belast wordt. Optimalisatie heb ik toegepast op 2 websites en beide laten werkelijk een sprong zien in snelheid. Missie geslaagd dus.

Maak altijd eerst een goede backup voor je zelf dingen gaat wijzigen!

Mooie verzameling functies. Wellicht zou je boven iedere functies kunnen zetten wat de code eronder precies doet. Je zet nu bijvoorbeeld de update van plugins en themes uit en is dit niet wat iemand wil of is er niet van de hoogte.


Er zijn cache- en optimalisatieplugins waarmee je heel uitgebreid per pagina/post kunt aangeven welke plugins, etc. er wel/niet geladen moet worden of het uitstellen van laden van javascript tot een gebruiker iets doet.


Ook zou je iets als redis cache, memcache, varnish cache, etc. kunnen gebruiken. Het laden van veel gebruikte data vanuit het geheugen/cache ipv vanaf de hdd.




WP Heartbeat.... Wanneer jij of iemand anders een pagina of post bewerkt, dan wordt er iedere 15 seconden gecontroleerd hoelang je bent ingelogd, autosave, auto revisions, status pagina/post, etc. Ook maken plugins gebruik van de heartbeat door features en berichten in het dashboard te tonen, vaak niet interessant.

Werk je met meerdere mensen aan een website, dan is het handig om te zien of en wat er is gewijzigd, maar werk je alleen dan wordt de CPU onnodig belast en stijgt ook nog eens je Inode gebruik!

Er is een plugin, deze is uitgebreider dan onderstaande code, maar je kunt heel simpel ook zelf de WP Heartbeat uitzetten:

add_action( 'init', 'stop_heartbeat', 1 );
function stop_heartbeat() {
wp_deregister_script('heartbeat');
}

Van beide websites doe ik beheer zelf, dus als er echt ergens een belangrijke update voor released wordt dan krijg ik daar mail elders van. Second: Modsecurity + OWASP ruleset. Ook al is je website super lek, onveilig, zijn er tientallen exploits voor, Modsecurity houdt relatief 99.9% al tegen met name POSTS of XSS exploits tegen.

Bovenstaand doet niets meer dan o.a de default wordpress RSS feed uitschakelen, callbacks zoals plugins of wordpress versie staken maar wp_action_scheduler limiteren tot een week retentie. Normaal loopt dat op tot een maand en een database kan zo explosief groeien in Woocommerce. Snap niet waarom dat met 15k aan records nog moet worden bijgehouden wat een cron log precies gedaan heeft.

Tja en backups hoeft met dit niet. Haal de regels code in functions.php weg en het is weer back to detault. En met Litespeed kan je maar tot een bepaald gedeelte optimaliseren. Onder de motorkap lukt veel niet. Ik heb Redis Objectcache gebruikt; maar daar liepen we tegen de bug aan dat een product van bijv 50 gram, 100 gram, 150 gram niet langer werd weergeven, en de klant ook niet verder kon klikken.

De meeste beveiligingsplugins zijn ook een vreselijke load op de server. Deze moeten de hele tijd alles controleren etc. Dit kan je beter met een simpel scriptje direct tegenhouden. Minder plugins gebruiken maken je website niet alleen sneller maar ook veiliger. Eigen code is altijd veel veiliger dan welke plugin dan ook.

WooCommerce is heel goed sneller te maken. Met niet te veel producten en traffic haal je zelfs 100/100.

Meer onpage werken vindt ik de mooiste oplossing. Zelfs heb ik een onpage custom css gebouwd. Dit doe ik trouwens ook per cpt en archiefpagina's zijn ook gescheiden. Lijkt veel extra werk maar valt reuze mee.

Als ik de code goed begrijp probeer je voornamelijk WordPress te versnellen door de plugin en thema updates uit te schakelen of op per week te zetten. Hier is een simpele plugin voor die je kan gebruiken om eerst te testen waar je het meest op wint en daarna harde code gebruiken.
Als je minder plugins hebt dan hoef je ook niet zo vaak te kijken of er updates zijn dus dit ligt ook duidelijk aan de hoeveel plugins je hebt. Hard coded is daarom altijd beter.

Je moet ook zorgen dat vooral die transients worden uitgeschakeld, deze vullen je database veel te veel en dat is iets dat je altijd moet voorkomen.

Je kan heel makkelijk alles fine-tunen. Scripts en stylesheets alleen laden op pagina's waar ze nodig zijn. Deze verplaatsen naar de footer en dergelijke. Dit is allemaal niet zo heel bijzonder maar is wel wat werk en zeker als je veel plguins hebt. Oeps begin ik weer over plugins.

Doe mij een lol een gooi de pagebuilder er eens uit en test het dan eens en kijk wat het verschil is. Dit kan je met alle plugins doen.

Ik wou dat er een plugin was dat men geen plugins meer zou gebruiken;-)

Transients vang ik af door een retentie van uiterlijk 3 dagen te hanteren. Zo groeit die database ook niet uit de klauwen. Als iemand dan iets verkeers doet lijkt het me dat er een backup nog is (of eerdere revisie) van max 3 dagen.

Woocommerce voert steeds cronjobs uit, en het houdt een log bij met wat het exact heeft gedaan. 99.99999999999% van de tijd zijn het positieve finished crons, waarom in godsnaam daar dan 15k aan rows van bewaren.

Of winkelmandjes van gasten etc. Je kunt een database gewoon laten chrashen als je tienduizenden bezoekers allemaal iets in kart laat steken. Ook hier een retentie op. Voor een shop met 150+ producten en een asociaal grote database van 850MB vindt ik het wel welletjes.

Er zijn nog meer tweaks, ongetwijfeld maar dan ga je hakken in core functies zowat en een thema is best groot. Het kan soms ook misgaan als je niet oplet, en functionaliteit zoals Ajax en toestanden ineens niet meer werkt.

Blijkbaar is bij W6.0 toch rekening gehouden met performance en is er veel uit gesloopt. Nog steeds vindt ik dat gutenberg een stille dood sterven mag. Ik disable het standaard. Ook de hele CSS wordt meegestuurd naar de frontend waar een bezoeker niets aan heeft.

In mijn Wordpress afkeer ben ik vast niet alleen.

Mij interesseert het niet hoe Gutenberg sterft. Beste meneer is al dood dus ze kunnen die zooi er bij begraven;-)

Revisies kan je ook zetten op maximaal 2 bijvoorbeeld. Op die manier kan je heel veel besparen. In 3 dagen kan je heel veel revisies genereren namelijk.

Die zooi van WooCommerce kan je makkelijk verwijderen maar voor de verkoop kan het soms een voordeel zijn om zaken te bewaren. Denk bijvoorbeeld aan iemand die vandaag enkele zaken in de winkelmand gooit maar niet afrekent. Over twee dagen komt deze terug en vindt een winkelmandje met enkele producten en kan ze misschien gaan afrekenen. Dat is oke maar bewaar dat dan in een cookie in de browser van die klant.

Mijn truc is regelmatig de database opschonen. Bij website waar jij het over hebt met zo veel zooi zou ik daar misschien een cronjob op zetten om het dagelijks op het stilste moment van de dag te doen.

Probleem bij veel plugins en thema is dat ze voor het grote publiek zijn en hierdoor hebben ze een hoop zooi dat veel mensen niet gebruiken maar ze zitten er wel in. Grootste probleem vind ik de plugin pooiers die voor het meest belachelijke een plugin nodig hebben terwijl je met een klein beetje code dit zo in je thema gooit. Maar dan roepen ze dat het functies zijn voor plugins. Onzin. Beter direct in het thema en alleen daar waar je het nodig hebt.

En dan zijn er die roepen dat ze niet kunnen zonder Font Awesome. Laden gerust 200kb of zelfs veel meer voor niet meer dan 10 icoontjes. Dat is vragen om ellende. Zelfde verhaal met bootstrap, die strip je makkelijk tot 10kb als je wilt. Daar kan je veel mee winnen. Jquery begin ook steeds meer te weren en laad ik alleen voor WooCommerce maar zou mooi zijn als zij meer pure JavaScript zouden gebruiken.

Origineel gepost door S. van Laere

In mijn Wordpress afkeer ben ik vast niet alleen.

Nee maar wel eenzaam;-) Ik doe ook Joomla en custom php maar probeer dat maar eens aan te bieden voor een betere prijs dan de meeste kunnen bouwen voor veel minder maar met WordPress.
Perfect is het niet maar ik heb zeker geen afkeer voor WordPress. Wat zou jij dan voorstellen?

Vergelijk de performance maar eens met een kale PHP 7.4 / apache installatie vs litespeed.



En het voordeel met litespeed is dat je server ook niet in elkaar stort als het ff druk is of er een bruteforce aanval plaatsvind. Belachelijk genoeg dat je voor een redelijke site al gauw aan een eigen server moet gaan denken. Zet je zoiets op op basis van PHP / HTML dan kan je er het honderdvoudige aan performance c.q bezoekers mee bedienen.