Tillbaka till Sällskapet
Tips och tricks· 20 augusti 2026 ·Uppdaterad 24 aug 2026 ·7 min läsning

PrestaShops prestanda: cachelagring av en dynamisk butik på rätt sätt

PrestaShop ger dig en seriös butik ur lådan, och en allvarlig mängd arbete per sida för att gå med det. Hur man gör det snabbt utan att bryta de dynamiska bitarna.

Mads Edelskjold
Mads Edelskjold
Grundare, NordicCDN tidigare CTO för datacenter
PrestaShops prestanda: cachelagring av en dynamisk butik på rätt sätt
Den korta versionen

PrestaShop monterar varje sida från PHP, Smarty-mallar och en upptagen databas, varför stora kataloger blir tröga. Cache katalogen - hem, kategorier, produkter - vid kanten, och kringgå cacheminnet när PrestaShop session cookie är närvarande så vagnar, kassan och kundkonton bo live. Se upp för butiker med flera valutor och flerspråkiga butiker, som behöver cachenyckeln för att inkludera dessa dimensioner.

PrestaShop är en riktig e-handelsplattform: multi-store, multi-valuta, multi-språk och ett modulekosystem som gärna låter dig installera trettio saker. Allt som kapacitet har en kostnad, och kostnaden brukar dyka upp när katalogen passerar några hundra produkter och någon frågar varför kategorisidorna tar två sekunder.

Där tiden går

Varje PrestaShop-sida monteras på begäran. PHP-stövlar, Smarty-mallmotorn renderar, moduler kör sina krokar och databasen är frågad - ofta tungt, eftersom skiktad navigering, prisregler, lager och kombinationer alla måste lösas före sidan kan dras.

De specifika saker som tenderar att skada, i ungefär den ordning de visas som en butik växer:

  • Lagad navigering för stora kategorier. Fasetterad filtrering är dyr och frågorna växer med antalet attribut.
  • Produktkombinationer. En produkt med fem storlekar och sex färger är trettio kombinationer att lösa, var och en med sitt eget pris och lager.
  • Särskilda prisregler. Varje pris som visas kan behöva prisregler för katalogen utvärderas mot den aktuella kundgruppen, valutan och landet.
  • Modulkrokar som körs på varje sida. Moduler registrerar krokar som bränner oavsett om sidan använder dem eller inte, och ingen granskar dem.
  • Bildförnyelse. Miniatyrregenerering efter en temaändring är ett välkänt sätt att ockupera en server i timmar.

Inget av detta är en defekt. Det är det som gör PrestaShop kapabel. Det är bara arbete som upprepas för varje besökare, inklusive den tusende besökaren på en produktsida som inte har ändrats sedan mars.

Splitten som gör cachelagring säker

Catalog — same for everyone → cache Cart & checkout — personal → bypass
Cache de delade sidorna, kringgå de personliga. Allt annat är detaljer.
SidaCache?Anmärkning
Hemsida, kategorier, produktsidorJa, jaStörsta delen av din trafik
Lista över CMS-sidor, tillverkare och leverantörerJa, jaSällan förändring
SökresultatVanligtvisKort TTL; normalisera frågeparametern
Resultat för navigering i flera lagerFörsiktigtCacheable, men titta på antalet filterkombinationer
Varukorg och kassaAldrigPersonlig per definition
Mitt konto, orderhistorik, adresserAldrigPersonuppgifter
Allt under admin-mappenAldrigBypass helt och hållet

Att få bypass rätt

Hela tricket är att känna igen när en besökare är "i session" snarare än att bara surfa. PrestaShop sätter en sessionscookie – med namnet PrestaShop- följt av en hash som är unik för din installation – när en kund har en kundvagn eller loggar in. Bypass cachen när den cookien är närvarande, och allt fungerar: anonyma webbläsare får cachade sidor, alla med en vagn får en levande.

Två detaljer som fångar människor:

Undvik inte att använda cookien enbart i någon form. Vissa konfigurationer ställer in en sessionscookie vid första besöket oavsett aktivitet, vilket skulle innebära att ingen någonsin får en cachad sida och ditt träffförhållande sitter nära noll medan du undrar vad som gick fel. Kontrollera om din installation ger anonyma besökare den cookien innan du förlitar dig på dess närvaro.

Avlägsna spårningsparametrarna. PrestaShop-butiker lockar mycket kampanjtrafik, och ?utm_source= varianter fragmenterar din cache dåligt. Ta bort dem från cachenyckeln.

En fälla med flera valutor och flera språk

Den här är specifik för PrestaShop och det är värt mer uppmärksamhet än det brukar få, för att få det fel visar en dansk shopper priser i euro - eller värre, visar en grossist kundgrupp detaljhandelspriser.

PrestaShop lösderaspråk, valuta och kundgrupp per begäran, ofta från cookies. Om din cachenyckel inte innehåller dessa dimensioner fyller den första besökaren som begär en sida cachen med sin version och alla efter det får den.

Fixen är antingen att inkludera relevanta cookies i cachenyckeln - så att varje valuta och språk får sin egen cachade kopia - eller att använda olika webbadresser per språk och valuta, vilket är bättre för SEO ändå. Multi-shop installationer behöver butiksdimensionen i nyckeln också.

Testa detta medvetet innan du går live. Öppna butiken i en webbläsare, byt valuta och öppna den sedan i ett nytt inkognitofönster och kontrollera vilken valuta du får. Det tar nittio sekunder och det fångar det enskilt mest skadliga cachefelet som en PrestaShop kan göra.

Rengöring när saker förändras

En cachad katalog måste ogiltigförklaras när katalogen ändras. Prisuppdateringar, lagerändringar och nya produkter behöver alla de drabbade sidorna rensas, eller shoppare ser gårdagens priser - vilket är ett kundserviceproblem och, beroende på var du handlar, eventuellt ett lagligt.

Praktiskt tillvägagångssätt: Rensa den specifika produktwebbadressen och dess kategorisidor om produktbesparing, rensa i stort sett efter en bulkimport och håll produktsidan TTLs blygsam - en timme snarare än en dag - så allt som en utrensning missar Rättar sig snabbt. Om du visar antalet levande lager ska du antingen utesluta det fragmentet från sidan eller acceptera att lagervisningen släpar efter din TTL.

Och bilderna

En PrestaShop-butik lever och dör på produktfotografering, och bildvikt är vanligtvis den största enskilda komponenten i sidstorlek. Konvertera till WebP eller AVIF och ändra storlek på kanten rutinmässigt gör mer för upplevd hastighet än någon backend tuning och till skillnad från regenerera miniatyrbilder i admin panelen, behöver det inte en timmes servertid och en bön.

Vanliga frågor

Varför är min PrestaShop-webbplats långsam?

Eftersom varje sida är sammansatt på begäran från PHP, Smarty-mallar och databasfrågor, och det arbetet upprepas för varje besökare. Belastningen växer med katalogen: navigering i flera lager, produktkombinationer, specifika prisregler och modulkrokar – alla lägger till frågor per sida. Genom att cachelagra de sidor som är identiska för alla kunder tas repetitionen bort istället för att optimera den.

Kan jag använda fullständig cachelagring med PrestaShop?

För katalogen. Hemsida, kategori, produkt och CMS-sidor är identiska för anonyma besökare och kan cachas vid kanten. Varukorg, kassa, kundkonto sidor och admin området måste alltid kringgå cache, som hanteras genom att upptäcka PrestaShop session cookie och servering dessa besökare en levande sida.

Vilken PrestaShop-cookie ska utlösa en cache-bypass?

Sessionscookien PrestaShop, med namnet PrestaShop – följt av en hash som är unik för din installation. Dess närvaro indikerar att besökaren har en kundvagn eller är inloggad, och cachen bör förbigås för dessa förfrågningar. Kontrollera först om din installation problem som cookie till anonyma besökare på första sidan laddas, eftersom om det gör det, kringgå sin närvaro ensam skulle förhindra någon sida från att någonsin cachas.

Hur cachar jag en PrestaShop-butik i flera valutor?

Inkludera valuta och språk i cachenyckeln, antingen genom att lägga till relevanta cookies till nyckeln så att varje kombination cachas separat, eller genom att använda olika webbadresser per språk och valuta, vilket är att föredra för SEO. Utan detta fyller den första besökaren som begär en sida cachen med sin valuta och varje efterföljande besökare får den. Installationer med flera butiker måste också innehålla butiksdimensionen.

Hur förhindrar jag att kunder ser föråldrade priser från cachen?

Rensa de berörda produkt- och kategoriwebbadresserna när en produkt sparas, rensa i stort sett efter bulkimport och behåll produktsidans TTL till cirka en timme så att allt som en utrensning missar självkorrigerar snabbt. Om du visar livelagernivåer kan du antingen utesluta det fragmentet från den cachade sidan eller acceptera att det kommer att släpas efter längden på TTL:n.

Sammanfattningen är att PrestaShop är tung av goda skäl och cacheable för bättre. Cachekatalogen, förbigå sessionscookien, få valuta och språk i cachenyckeln innan du går live och optimera fotograferingen. Du behåller varje del av plattformens kapacitet och förlorar den del där det får folk att vänta.

#prestashop #e-handel #caching #prestation
Omsätt det i praktiken

Se hur NordicCDN gör detta för din webbplats:

Mads Edelskjold
Skrivet av
Mads Edelskjold Grundare, NordicCDN ex-datacenter CTO

Mads har arbetat inom IT – mestadels som värd – sedan han var 16. Han tog tidigt del i ett SaaS-företag och hjälpte till att växa fram till förvärvet av Visma, har byggt och drivit datacenternätverk och fungerat som CTO för ett danskt datacenter. Han startade NordicCDN för att göra snabb och säker infrastruktur enkel att använda.

Gör din webbplats laddad direkt

Starta gratis på två minuter – inget kort krävs.

Starta gratis