Veel SEO-professionals baseren hun SEO-inspanningen op “best practices”. Maar het optimaliseren van op JavaScript gebaseerde bedrijfswebsites voor snelheid vereist meer dan ‘best practices’. Hier leest u waarom standaardoplossingen niet altijd werken voor bedrijfswebsites en wat u in plaats daarvan kunt doen.
Sitesnelheid verbeteren: Overstappen naar server-side rendering is niet altijd de juiste oplossing
Stel je voor dat je naar de CEO (of een andere leidinggevende) gaat en te horen krijgt: “We moeten onze website veranderen in Server Side Rendering (SSR). Ze vragen je: “Waarom?” en het enige antwoord dat u ze kunt geven is “Omdat het een best practice is om de snelheid van de site te verbeteren”. De kans is groot dat je gewoon de kamer uit wordt gelachen. De zakelijke implicaties en kosten die gepaard gaan met SSR-migratie zijn de hoge inspanning en lage impact niet waard. Tenzij de site van een bedrijf vanaf de grond af is opgebouwd om server-side te worden bediend, of de site al wordt gemigreerd, is er zelden een reden om over te stappen op SSR. Overweeg enkele gemakkelijke en harde kosten:
- Alle systemen en API’s beoordelen om compatibiliteit te bevestigen, die waarschijnlijk niet allemaal zijn gedocumenteerd (waarschijnlijk honderden, zo niet duizenden).
- Duizenden manuren voor sitebrede updates, kwaliteitsborging en toegankelijkheidsbeoordelingen.
- Bestaande werknemers trainen in het nieuwe systeem (tientallen, zo niet honderden mensen in de hele organisatie).
- Het inhuren of ontslaan van ontwikkelaars en ingenieurs die niet bereid zijn of niet voldoen aan de specificaties van het nieuwe systeem.
- Meer geld uitgegeven aan serverkosten.
In plaats van zo’n tijdrovend en arbeidsintensief proces te doorlopen, zijn er andere, succesvollere manieren om de snelheid van de websites van uw bedrijf te verhogen. In een eerdere functie bij het bedrijf besprak ik dit scenario voor de lol met een van onze senior systeemingenieurs. We schatten dat deze onderneming anderhalf jaar zal duren, een toegewijde agile-stam (meestal ongeveer 70 mensen) en minstens $ 2 miljoen. USD (AUD). En dat was waarschijnlijk een conservatieve schatting. Dus wat doen we om vooruitgang te boeken?
Leer je andere teams kennen en help ze
Op bedrijfsniveau moet SEO een kameleon zijn, omdat u op andere teams vertrouwt om prioriteiten te stellen en uw werk voor u te doen. Er is een goede reden waarom je geen koninkrijkssleutels hebt om wijzigingen aan de site aan te brengen. SEO is dus niet zomaar SEO. SEO is “het zal de snelheid van onze website verbeteren/ons helpen voldoen aan de toegankelijkheidseisen enz.”. SEO is alles Maar SEO. Tom Critchlow zei dit in zijn SEO MBA-cursus en in mijn podcast Engage: On Enterprise SEO. Dat vat het leven als zakelijke SEO zo ongeveer samen. U moet veel tijd besteden aan luisteren en aandacht besteden aan wat andere mensen doen en hen vervolgens laten zien hoe wat ze doen de zichtbaarheid van de site heeft verbeterd. Creëer pleitbezorgers en deze mensen zullen bij je blijven terugkomen met een constant verslag van wat ze doen en veranderen op de site. Dat is de helft van de strijd. De tweede helft omvat het werken met ontwikkelaars, ontwerpers en analisten om dingen voor elkaar te krijgen. Het gaat meestal een stuk vlotter als je begrijpt dat mensen mensen zijn met hun eigen gedachten, gevoelens en doelen. Een nieuwsgierig persoon zijn die wil helpen hun leven gemakkelijker te maken, is een veel aantrekkelijker dan werken met een stier in een porseleinkast die om de paar weken in hun leven komt en compromisloze eisen stelt.
Werken met ontwikkelaars en fabrikanten
Voor veel bedrijven is de snelheid van websites tegenwoordig een bekende factor die conversieratio’s helpt (of belemmert). Veel interne ontwikkelingsteams gebruiken waarschijnlijk sitesnelheid als KPI. Doe mee. Jullie mikken allebei op hetzelfde, en je ontwikkelaars zullen de codebase beter kennen dan jij. En als je het goed doet, kun je er allebei met een bonus vandoor gaan. Enkele veelvoorkomende opties voor sitesnelheid waarmee ontwikkelaars u kunnen helpen, zijn:
Code maat/gewicht
Als uw teams technische schuldsprints of -distributies hebben, kan het helpen om de impact van hun herontwerp te begrijpen als u weet wanneer ze dit werk meestal doen. Denk erover na voor hen en erken hun harde werk.
Afbeeldingen laden en Common Layout Offset (CLS)
CLS kan een grote factor zijn in laadtijden voor op JS gebaseerde websites van grote ondernemingen. Afhankelijk van hoe dit is geïmplementeerd, kan het gebruik van een placeholder JS-bibliotheek om de positie van afbeeldingen effectief te “vasthouden” de waargenomen laadtijd van de pagina verkorten, omdat de pagina niet scrolt wanneer afbeeldingen worden geladen.
Controle omleiding
Het was niet iets waarop ik kon vertrouwen omdat ons omleidingsbeheer erg gefragmenteerd was. Als uw systeem echter wat meer gecentraliseerd is, kunnen het beheren van omleidingen, het verwijderen van de-hops, het consolideren van regels tot een regelmatig voorkomen en het verbeteren van technische schulden helpen. Sommige serverimplementaties vereisen dat elke omleidingsregel wordt gelezen voordat de pagina wordt geladen, wat de initiële laadtijd kan verlengen (meer dan milliseconden).
Deze is wat genuanceerder, maar ik heb vaak gezien dat JS-ontwikkelaars standaard ahref-links als knoppen opnemen. Het is meestal omdat ze weinig tijd hebben en het is de standaardinstelling van het systeem waaraan ze werken. Toen ik controleerde op nieuwe paginasjablonen, markeerde ik dit vaak om naar bij te werken . Ontvang de dagelijkse nieuwsbriefzoekopdracht die marketeers vertrouwen. Aan het verwerken … Even wachten, a.u.b. INSCHRIJVEN Zie voorwaarden. functie getCookie(cname) { let name = cname + “=”; laat decodedCookie = decodeURIComponent(document.cookie); laat ca = gedecodeerdCookie.split(‘;’); voor(laat i = 0; i[i]; terwijl (c.charAt(0) == ‘ ‘) { c = c.substring(1); } if (c.indexOf(naam) == 0) { return c.substring(naam.lengte, c.lengte); } } opbrengst “”; } document.getElementById(‘munchkinCookieInline’).waarde = getCookie(‘_mkto_trk’);
Werken met ontwerpers
Een van de grootste problemen met de sitesnelheid voor zakelijke websites is de grootte en het gewicht van afbeeldingen. Interne normen kunnen na verloop van tijd verkeerd worden vertaald of verloren gaan, vooral wanneer teams flexibel en enigszins gedecentraliseerd zijn. Toen ik bij het bedrijf begon, herinner ik me dat ik afbeeldingen zag op enkele voorbeeldproductpagina’s van 10 MB. Het schokte me. Geen enkele afbeelding op internet mag 10 MB zijn. Punt. Dus ik had een paar subtiele gesprekken met onze ontwerpers en werkte ongeveer 8 maanden met hen samen om de grootte van onze afbeelding te verkleinen. 100 KB was niet de heuvel waar ik op wilde sterven, dus als ik een ontwerper 100 KB voor een kopbanner of frame vertelde en ze kregen 300 KB, dan is dat nog steeds een verbetering. Zakelijke SEO’s streven vaak naar incrementele winst.
Werken met analisten
Analisten komen in het gesprek omdat ze waarschijnlijk uw tagsystemen en alle tags van derden op uw site zullen beheren. Ze zijn een startpunt voor gesprekken met tag-eigenaren over de vraag of die specifieke tag relevant is of dat er een alternatief is. Omdat, jongen, scripts van derden een enorme opgeblazen website kunnen veroorzaken. Dus terwijl je het hebt over meer dan 250 advertentiescripts op een site en als we ze allemaal nodig hebben, kun je misschien kortetermijncompromissen vinden, zoals:
- Activeer HotJar, Fullstory of een ander trackingscript voor gebruikerservaring alleen op pagina’s die actief worden weergegeven of gevolgd.
- Installaties controleren op duplicaten (dit gebeurt vaker dan u denkt).
- Bekijk welke chatbot- of klantenservicetags kunnen worden geactiveerd bij het klikken in plaats van bij het laden van een pagina.
Samenwerken met het QA-team
Dit partnerschap kan je geheime wapen zijn. SEO in het algemeen, maar ook SEO in JavaScript, heeft veel binaire ja/nee-vereisten of best practices, zoals:
- De metadata van de paginabron en de door de klant geleverde pagina moeten hetzelfde zijn
- Canonical moet aanwezig zijn op de pagina aan de clientzijde
- Links moeten worden opgemaakt als niet hoe
- Vooraf geladen lettertypen
- Word vroeg lid van geweldige bronnen
Maak goede afspraken met uw QA-team en werk met hen samen (inclusief training) om ze op te nemen in uw algemene, dagelijkse QA-proces. Je hebt overal ogen en een potentieel enorm netwerk van microadvocaten. Hoewel er veel andere teams zijn waarmee u zou kunnen werken om de SEO van uw website te verbeteren, zijn zij waarschijnlijk degenen waarmee u het meest zult werken als het gaat om de technische kant van de implementatie.
Je beveelt andere teams waarmee je samenwerkt aan
Weet je nog wat ik eerder zei over hoe het werken met mensen gebeurt als je je herinnert dat ze mensen zijn? Je wilt het waarmaken. Er zijn twee echt krachtige manieren om dit op bedrijfsniveau te doen.
Respecteer hun tijd
Laten we zeggen dat je een groot idee hebt zoals “we zouden moeten overstappen op server-side rendering”. In dit geval, in plaats van naar de PO te gaan en te zeggen: “Hé, kunnen we dit allemaal doen?”, werk je samen met hen om een proof of concept op te bouwen waarvan ze hebben gevalideerd dat het zich in het “lichtgewicht”-segment bevindt, en kijk de gevolgen. . Als het niet werkt, hebben ze eigenlijk geen 20 sprints verspild om dit enorme project te voltooien. Als het werkt, heb je een businesscase voor het financiële team om de rest van het project te financieren en te prioriteren dat op de hele site moet worden geïmplementeerd en om een toegewijde stam te krijgen, $ 2 miljoen. Anderhalf jaar USD. .
Verhoog hun inspanningen
Iets waar SEO’s erg goed in zijn, is communicatie en het delen van succes. Het is misschien een beetje makkelijker als je, in plaats van te zeggen: “Hé, kijk eens naar dit coole ding dat ik heb gedaan”, het verwoordt als: “Kijk naar dit coole ding dat een ander team waar ik nauw mee samenwerk deed, en hier is hoe het enorm onze website-ervaring verbeterd. Jij, de SEO, staat niet meer in de schijnwerpers. Het team dat het echte werk deed.
Samenwerking, belangenbehartiging en incrementele overwinningen
Het is je misschien opgevallen dat ik in dit artikel niet echt te veel heb gesproken over de nuances van JavaScript en sitesnelheid. Dat komt omdat bedrijven meer kans hebben om echt slimme mensen met je samen te werken waar je terecht kunt in de vorm van een probleem en een oplossing. Zij kunnen je daarbij beter helpen dan een artikel in een SEO-magazine. Als het gaat om dingen gedaan krijgen op ondernemingsniveau, gaat het minder om het ‘wat’ en meer om het ‘hoe’. Gebruik deze richtlijnen dus om te leren hoe u de snelheid van uw op JavaScript gebaseerde website kunt verbeteren, en “wat” zal veel soepeler verlopen. Het bericht Zakelijke SEO: waarom het toepassen van ‘best practices’ geen kwaad kan en wat u in plaats daarvan kunt doen verscheen eerst op Search Engine Land.