- Tools you used to build or improve the website - both parts of the infrastructure (django, Hibernate, Spring, Angular, etc)
- Processes or communication styles - "worked as part of an open source community", "work for hire using daily status updates, and weekly meetings", "agile", "waterfall"
- Test tools used - unit test tools, regressive test tools, etc.
If you are using metrics, make sure that you can meaningfully talk about them. "It just happened to work out that way" is a pretty lame follow up answer - if you spend a month improving the performance of a website, you should be able to tell the interviewer:
- what was wrong with it, and what had to change to bring about the improvement
- how did you test it - what were the pluses and minuses to that type of test approach
- what it always true/under what circumstances did it not work
- what did it mean for the business? Did the business see a meaningful gain for your work?
If I see a metric and ask about it, I want the candidate to be able to answer these types of questions. If they can't I'll figure they were just trying to pad the resume. If they can't answer why the change was meaningful, I'll be worried that they can't focus on the most necessary work. If they can't answer how it was fixed and tested, it makes me worry that the work was only happy accident.
For some businesses, some metrics will matter more than others. I worked in the DoD where high quality testing was a huge deal, but usability was not a big deal. In eCommerce, page load times and people who can improve them is a big deal. So some of "what metric?" is also knowing the business and what a given business will care about most. When jumping between businesses, it's good to be able to explain "I did X because Y was critical to that type of business".